Asynchronous and multi-threaded programming in MQL - page 5
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
The main problem is not in the "...still have to learn".
The main problem is that the more all these caveats, the greater the danger of getting tricky errors, which are not easy to calculate.
And all this is an additional headache for developers.
Plus - it's good to assess whether many people really need this multithreading?
The main problem is not "...yet to be learned".
The main problem is that the more all these gimmicks, the greater the danger of getting tricky errors, which are very hard to calculate.
All this is an additional headache for developers.
Plus it's good to know if many developers really need multithreading.
Well, a sow and a horse, then, and off you go... towards the morning dawn...
Too bad mql has no such feature,
Themanagement will suggest to develop a standard mql function for asynchronous programming,
since there are problems with threads and above all security.
For asynchronous mode I think there are no security obstacles.
I was at my mother-in-law's house yesterday, they are renovating the walls, are you doing the same? - Open the windows, ventilate the rooms!
Nothing is in the way! The task was to use pure WinAPI. Without any home-made dll !
The topic was created to discuss multithreaded mql programming issues. You have some kind of negative spirit today, what kind of flooding in the topic, that I created myself?
Why WinAPI? Let me tell you a secret, CLR is also "pure Windows", native support for .NET libraries with "smart" function import was added a year ago, you know WinAPI, but you can't create a thread in .NET? )))))
Please refrain from such comments.
Well then, a plough and a horse, and onward... towards the morning dawn...
Dimitri, have you tried growing and harvesting with a plough and a horse?
There are just as many subtleties and opportunities for mistakes. But it costs a lot more if the crop dies and you go hungry...
There are problems everywhere, and you have to measure the benefit against the effort involved. In particular, with this multithreading. I don't see where it is so directly necessary.
I did not just suggest that the author should write his first program in pure WinAPIhttps://www.mql5.com/ru/forum/318593/page2#comment_12565043.
there is a lot of information about this topic on the net - first write using ready header files (windows.h and so on), then remove these header files and get closer to the cherished pure WinAPI = a big piece of code that can register process and window, that can receive events and handle them.... and it will be just a trivial window that can't do anything useful, but will understand how much work you need to do using WinAPI
I tried it about 15 years ago (I don't remember exactly, I remember that there was a dial-up connection) and this way any "I'm a software engineer at my mum's" should pass through to get rid of questions and desire to give advice to system programmers - compiler developers
"having gone this way", it will be clear at once a colossal work of hundreds of system programmers who write compilers and libraries for them, it will be clear why the speed has been given a convenient user functionality, so that any application programmer can read the help and "in 2 clicks" get the desired result
SZZ: in general, the lack of experience, knowledge and skills caused another cognitive distortion ))))
The main problem is not "...yet to be learned".
The main problem is that the more all these gimmicks, the greater the danger of getting tricky errors, which are very hard to calculate.
All this is an additional headache for the developers.
Plus - it's good to evaluate - how many really need this very multithreading?
Dimitri, have you tried growing and harvesting crops with a plough and a horse?
There are just as many subtleties and opportunities for mistakes. But it costs a lot more if the crop dies and you go hungry...
There are problems everywhere, and one must balance the benefit obtained and the effort expended. In particular, with this multithreading. I do not see where it is so directly necessary.
What's a plough and a horse? The usual shovel.
If we are to be serious and mature, the first task, which would be useful to move to separate thread for asynchronous work is WebRequest, but generally it's Ok, you can live with that too.
The second task is training neural networks, auto-optimization built into Expert Advisor. If it were possible to easily create threads from Expert Advisor, this topic would get a big boost of life.
If we are serious and mature, the first task that would be useful to put in a separate thread for asynchronous work is WebRequest, but in general it will do, and we can live with it.
The second task is training neural networks, auto-optimization built into Expert Advisor. If it were possible to easily create threads from an Expert Advisor, this subject would get a nice shot of life.
Within MQL only, both tasks are solved by automatically launching the Expert Advisor.
I did not just suggest that the author should write his first program in pure WinAPIhttps://www.mql5.com/ru/forum/318593/page2#comment_12565043.
there is a lot of information about this topic on the net - first write using ready header files (windows.h and so on), then remove these header files and get closer to the cherished pure WinAPI = a big piece of code that can register process and window, that can receive events and handle them.... and it will be just a trivial window that can't do anything useful, but will understand how much work you need to do using WinAPI
I tried it about 15 years ago (I don't remember exactly, I remember that there was a dial-up connection) and this way any "I'm a software engineer at my mum's" should pass through to get rid of questions and desire to give advice to system programmers - compiler developers
"having gone this way", it will be clear at once a colossal work of hundreds of system programmers who write compilers and libraries for them, it will be clear why the speed has been given a convenient user functionality, so that any application programmer can read the help and "in 2 clicks" get the desired result
SZZ: in general, the lack of experience, knowledge and skills caused another cognitive distortion ))))
Igor, not everyone like you has a degree in programming. Where did your teachers teach you! That is why qualifications are out of the question.
For this reason the idea of pure WinAPI is blurred, I assumed that it will be simpler, than you've described.
I used to be a total stranger to programming, and it was only thanks to mql that I started to learn C/C++ without teachers and tips!
But, as you can see, I've reached asynchronous needs on my own. Yes, I may not know something, but I am learning everything I need to.
Yes, I'm not familiar with .NET technology and don't want to, I'm sick of C#, everyone has their own portability of languages.
Where did you see me giving advice to developers? A suggestion was made to add to mql a set of standard functions to work with asynchronous code.
This is a sensible proposal, I don't know why you reacted so negatively to it... Or maybe your way of talking is always like this?
If you don't need such functionality, other users do. It's like with OOP, not everyone uses it, but it's there. Asynchrony seems to be present in many languages now, but not in mql.
How is mql worse than other languages, that it is deprived of asynchronous methods? The question about threads is closed, while asynchrony is implemented out of the box.
Igor, not everyone like you has a degree in programming. Where did your teachers teach you! That's why the qualification is out of the question.
For this reason the idea of pure WinAPI is blurred, I assumed that it will be simpler, than you've described.
I was not at all familiar with programming before, and only thanks to mql I started to learn C/C++ without teachers and hints!
But, as you can see, I've reached asynchronous needs on my own. Yes, I may not know something, but I am learning everything I need to.
Yes, I'm not familiar with .NET technology, and I don't want to, I'm sick of C#, everyone has their own portability of languages.
Where did you see me giving advice to developers? A proposal has been made to add to mql a set of standard functions to work with asynchronous code.
This is a sensible proposal, I don't know why you reacted so negatively to it... Or maybe your way of talking is always like this?
If you don't need this functionality, other users do. I think all languages now have asynchrony, but mql doesn't.
How is mql worse than other languages, that it is deprived of asynchronous methods? Well, the question about threads is closed, but the asynchrony is feasible.
In MQL5 there is asynchrony, for example,OrderSendAsync.
As for interaction with the network or file system - use WinAPI, I wrote the solution above. I think everything is there for that. You can read about how to use these methods on Microsoft site. What else remains undisclosed?)