Time to convert libraries to MQL5 - page 6
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Actually, there is nothing wrong with direct access to data.
We need to separate the areas where "overdoing it is better than underdoing it" is really applicable and useful.
In my opinion, the principle "Safety Comes First" should only be applicable to the Market and Cloud. The buyer is paying for a product that is naturally secured and therefore closed, and there is no way to check the security of the product. Therefore, the market must give the buyer a 100% guarantee of the security of all products. And in the case of the cloud, all cloud computers must be 100% protected against malware.
And in all other cases, not concerning the distribution of software products through the market and their purchase through this service, as well as using the cloud, the entire responsibility for the use of unproven dll is on the user.
With this approach, many of the current problems with degraded performance and functionality of the MQL5 language due to "Safety first" can be avoided.
Therefore, the market is obliged to give the customer a 100% guarantee of the safety of all products.
How do you envisage it? You, as a seller, are renting a marketplace from MK and demanding that the landlord be 100% responsible for the safety of your product. This is absurd.
The market already gives a guarantee of product security, because it forbids the use of external dlls by the products. And the MQL5 programs themselves work in the terminal's secure internal sandbox.
You didn't know about this?
I assume that you will have to change a lot of things.
And you just try it.
The reasonable DLLs are originally written for integration with other systems and therefore have simple external interfaces in the form of raw functions. Their header files are simple.
Actually, there is nothing wrong with direct access to data. After all, MetaTrader itself is probably written in C/C++, and nothing. Furthermore, linkers usually even allow assembly inserts, and that's OK too. Remember that MetaTrader running under Windows directly or indirectly uses a lot of system dlls, and there's nothing wrong with it either.
I don't think we should deprive the user of his right to choose. I'd really like the option where I could take, for example, ALGLIB-dll and its native header file(s) and use a reliable library without touching it with my "evil hands", but simply telling the MQL compiler that this is a C++ header file, not the MQL one.
Take the library and use exported functions from headers with minor (if necessary) modifications.
To think that you can take any *.H file from an insecure C/C++ language and use it in another (even safer) language is a complete misunderstanding of languages. You can dream, but you can't demand.
The ALGLIB library is already being ported to MQL5 and will be available in the source code.
The question may arise - what if this library is malicious and dangerous? But I have decided to use it myself.
Ask this question a few million times to understand the number of MetaTrader end-users, and assess the quality of thinking and responsibility of those millions of respondents.
This is why we take care of the original security of the environment.
In other words - MQL can be as safe as you want, but if I dared to use something external, then it is my own personal problem.
To think that one can take any *.H file from an unsafe C/C++ language and use it in another (and even safer) language is a complete misunderstanding of languages. It is possible to dream, but it is impossible to demand.
The ALGLIB library has already been ported to MQL5 and will be available in the source code.
Perhaps I expressed my opinion in vain (by the way I didn't demand anything). And about the lack of understanding of languages, you're absolutely right. The more I read and understand, the less I understand. I don't understand why if you rewrite ALGLIB for mql5, and then compile it with external compiler(visualc) into DLL, then the library will be more secure from this than in case of direct compilation of the original source code of the library to DLL at once?
Well, okay. Let it be so.
It doesn't get to me why if you rewrite ALGLIB to mql5 and then compile with an external compiler(visualc) to a DLL,
We have done a huge amount of work on fine-tuning the MQL5 compiler to make it easier to convert existing libraries written in other languages.
And the development of MQL5 language continues. New features are expected to appear soon, including a powerful code profiler.
We now have two tasks to accomplish:
1) to select useful third-party libraries for conversion
2) to gather volunteers to implement conversion projects (we will fund it).
We would like to start with a list of potential projects. Help with links and short descriptions, please.
Since ALGLIB is already being ported apparently the main question on the topic is"what other Open Source library would users like to see?"
Since ALGLIB is already being ported apparently the main question of the topic is "what other open-source libraries would users like to see?"
Yes, I made that clear in my first post:
We are now faced with two challenges:
1) to choose useful open-source libraries for conversion
You have got it a little wrong. The rewrite in MQL5 was designed to include all necessary mathematical packages directly in MQL5 source code instead of using DLL.
Sorry, really confused with the promised ability to compile C/C++ code into a dll directly from the metaeditor.
But for me it's still not clear, why to port it, when it (library) is already ready to use as a DLL? It turns out - I bought a book in a shop and before reading it, first transcribed it into a notebook.
I must have got something wrong again. I won't write any more.