Asynchronous and multi-threaded programming in MQL - page 21
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
Here is an example of writing linear asynchronous code in one thread for illustrative purposes.
CTask *task2 = obj2.CALLBACK_FUNC(DeleteOrdersLimits(Magic)); //Выполняется асинхронно в пуле потоковthis will not work:
but when using multithreaded applications, controlling these threads is a developer's headache, didn't check the readiness of the calculation - got a bug, which will appear at some unknown time
OK, I had a desire to write in a topic with such a beautiful name - I wrote, so I wrote... remembered Don Quixote and his eternal struggle with windmills ))))
a good team of professionals, I think there is still something to talk about
....
Why, hypothetically, would I need your GUI, etc., if it can be written in Sharp or Python in two strokes? The user does not care what it is written in, he needs the functionality, not the specifics of implementation. I.e. a programmer doesn't need such products, but a user doesn't care at all, he cares about the price, and it is obviously cheaper and more functional in Sharp.
1. Where will you find buyers of your Sharp programs?
2) How will you prove safety of your programs?
3. You, as an experienced programmer, suggest that you should not use an application language in TC development, because I haven't understood why for years.
4. If you propose to make a hybrid program - use Sharp's GUI, and write the logic in MCL, - try to link Sharp's tables to the Expert Advisor. It's been half a year, and the article showing how to do it hasn't been published yet. I suspect there are very serious problems there. And the GUI at the button level - you can do it with an in-house library.
In short, your suggestion to keep the ICL is like suggesting to do I don't know what and go there, I don't know where, because they seem to be good food there....
it will not work:
It works in C and C++ in one of the libraries ))
How is mql different from C++ ?
If the developers were willing, they could implement this functionality in mql very realistically.
After all, the idea itself is worthwhile - all the more so because these technologies are well known.
And most likely the work on the agents is implemented in a similar way, in a pool of threads.
1. Where are you going to find buyers of your Sharp programs?
2) And how will you prove the safety of these programs?
3. You, as an experienced programmer, propose to refuse using an application language in TC development, because... I haven't understood why for years.
4. If you propose to make a hybrid program - use Sharp's GUI, and write the logic in MCL, - try to link Sharp's tables to the Expert Advisor. It's been half a year, and the article showing how to do it hasn't been published yet. I suspect there are very serious problems there. And the GUI at the button level, you can do with the internal library.
In short, your suggestion to leave MKL is like suggesting to do this, I don't know what and go there, I don't know where, because they seem to be feeding well there....
1. Look for customers on the side. The Market is not the only place to find them.
The Market is not a business. For MKs it's part of business).
2., 3. и 4. To me, MKL (or any other language of any terminal) is nothing more than the interface language between the terminal and the TS. The TC should not depend on the terminal, and should be able to connect to any terminal via an appropriate interface.
I have this concept from the beginning. All this is quite realizable, I don't see any problems. Here is, say, what the MCL does with the DLL.
There is no import of libraries into MKL. In the database we see the history of TF 1m and the glass. All of this is filled in real-time as the play progresses.1. Look for buyers on the outside. The Market is not a business.
The Market is not a business. Here, for MKs, it's part of the business.)
2., 3. и 4. To me, MKL (or any other language of any terminal) is nothing more than the interface language between the terminal and the TS. The TC should not depend on the terminal, and should be able to connect to any terminal via an appropriate interface.
I have this concept from the beginning. It's all quite feasible, I don't see a problem.
1 and 2 are unanswered. Searching in an unclear place and unclear how to convince that the program is safe? And a 10-page manual to start it, how to connect TC written in an unapplied language to all sorts of platforms? ))
Multi-platform TC - do you want to bet? - Study to become a programmer and you'll see how!
You know, you make me laugh every time. Seriously. A programmer-practitioner who calls not to use an application language to solve highly specialized problems, but to solve those problems in UNIVERSAL languages, for the sake of UNIVERSALITY! Practicality and expediency simply springs from every phrase.
....
There is no import of libraries into MKL. In the database we see the history of TF 1m and the glass. All of this is filled in real-time as the play progresses.No. You are just transferring data from the platform once a minute. You show live interaction and filling the table with data more often than once per second. And the data has to be transferred in two directions. From MKL to sharp and back again.
You know, you make me laugh every time. Seriously. A programmer-practitioner who calls not to use an application language to solve highly specialized problems, but to solve these problems by UNIVERSAL methods and for the sake of UNIVERSALITY! Practicality and expediency just springs from every phrase.
To be honest, I have fun reading your posts too. About business, in particular.
I'm not calling anyone to anything and I'm not selling anything. If you want to use threads - use C++/C# and no problem. Or you can moan forever that there are no threads in MKL.
No. You're just transferring data from the platform once a minute. You show live interaction and filling the table with data more often than once per second. And the data has to be transferred in two directions. From MKL to sharp and back again.
Once a minute. Expert in technology.)) You have an event -OnTick, you call the DLL function on it and pass the current data about the candle. That's all.)
OK, forget it.
...
If you want to use threads, use C++/C# and no problem.