Asynchronous and multi-threaded programming in MQL - page 16
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
I already wrote you, you are trying to build a NS, don't you need asynchrony in this case?
But you are building NS on simple activation functions, so you have not encountered a lack of concurrency.
But when you start to build global models of NS, then you will understand the beauty of asynchrony.
bad example - not needed!
@Roffild already wrote in the thread"In today's world, a programmer must know several languages in order to choose the right tool for a particular task. "
this is true!
In MQL there is no choice of packages for MQL - only AlgLib - I want to consider an example, found on the hubra, I take and connect C# or Python to MQL - that's all, I do what I want to do, not porting code to MQL
These days programming languages are interesting not for their features but for ready-made frameworks! - If in MQL there will be new MQL packages, then there will be other tasks and problems!
ZS: once again on my fingers, you are clinging to "the idea of fx" which grew out of cross-platform languages Python and Java, the sacrifice for portability and flexibility of the language was the loss of performance, now these languages have been overgrown with different ways to increase performance, but in C-like languages developers always achieve maximum performance and there is no need (in most cases) to divide the task into separate threads (client - server tasks do not count, there the problem is the data exchange rate and this is another specifics)
bad example - not needed!
@Roffild already wrote in the thread"In today's world, a programmer must know several languages in order to choose the right tool for a particular task. "
this is true!
In MQL there is no choice of packages for MQL - only AlgLib - I want to consider an example, found on Habra, I take and connect C# or Python to MQL - that's all, I do what I want to do, not porting code to MQL
These days programming languages are interesting not for their features but for ready-made frameworks! - If in MQL there will be new MQL packages, then there will be other tasks and problems!
ZS: once again on your fingers, you are clinging to "the idea of fx" which grew out of the cross-platform languages Python and Java, the sacrifice for portability and flexibility of the language was the loss of performance, now these languages have become surrounded by various ways of increasing performance, but in C-like languages developers always achieve maximum performance and there is no need (in most cases) to divide the task into separate threads (client - server tasks do not count, there the problem is the data exchange speed and this is another specificity)
You constantly ignore the following things:
1. The distribution of programs that use external connections can not be done through the Market.
2. Programs that use external connections require the user to be a "professor" to connect everything properly. The instructions for using such a program is a mess.
3. Programs using external connections are suitable only for personal use, which greatly limits the sense of their creation.
4. Programmes for personal use are of lower quality than those for sale, because you can do anything for yourself... and you CANNOT be the same expert in several languages at once. Some languages you will know from fifth to tenth language and it will affect the quality of the product.
5. There are many tasks requiring asynchronous and multi-threading. MQL-programs have not yet reached these tasks, but it doesn't mean that they should not strive for them.
...
What achieves asynchrony in a single stream.
No, well, asynchrony without multithreading is really some kind of nonsense, you need at least one additional thread. I think your EventLoop can be done via loadable indicators. Communication between expert indicators via sockets, for example. A task was created, the indicator was hooked up, the task was sent, the indicator reported the execution, we request the task status from the Expert Advisor, delete the indicator. Through crutches, but multithreading nevertheless.
Yes, that article is very good, for a single solution, to think about it, maybe you can squeeze something else out of this approach.
I have decided on the direction of my problem, thanks to Andrey for the tip.
The fact that you have read one article is good.
Not threads, namely the non-blocking calls via colback functions, controlled by EventLoop.
This achieves asynchrony in one thread.
How did you manage not to find it in the documentation?
Why don't you read it?
You constantly ignore the following things:
You and I have different tasks, you do not take into account that there are 2 big steps in writing software: software development and implementation itself.
Software development requires ready-made solutions - it takes time; if during development it turns out that the software will not perform its tasks as planned, it goes in the trash. And the implementation itself is a mechanical work for the capabilities of a particular platform.
5. There are many tasks which require asynchrony and multithreading. MQL programs have not yet reached these tasks, but this does not mean that they should not strive for them.
Ok, now let's go with you:
Answer the question why does thetrading terminal need it?
The fact that you have read one article is good.
How did you manage not to find it in the documentation?
Why don't you read it?
Imagine not finding it.
Searching for callback and eventloop doesn't find anything like that in the documentation.
If you don't mind, please give me a link without any sarcasm.
1. You and I have different tasks; you do not take into account that there are two big stages in writing software: software development and implementation.
Software development requires ready-made solutions - this takes time; if during development it turns out that the software will not perform its tasks as planned, it goes to waste. And the implementation itself is a mechanical work for the capabilities of a particular platform.
OK, now let's go with you:
2. Answer the question, why does thetrading terminal need it?
1. All I do is development. Hardly 6 years of continuous development I don't understand what it is. )) I think that ready-made external solutions, torn from the context of other programs or abstracted from some other programs, poorly integrate into the structure of a highly specialized code and can get very messy. The labor input in this case is higher than in developing your own solution and the final quality of the code is lower. Not to mention the development potential. These are the realities of development. But, this is irrelevant to our question. In fact, what does this have to do with it?
2. You are asking the wrong question. The main question is "Why does the end user need it?". Because the user is always short of the features on offer. Therefore, they have to be added so that they don't lose interest. If we run out of possibilities and cannot add new ones due to technical limitations, the user will quit. Opportunities are needed to keep users on the terminal and software distribution is necessary for this purpose. Therefore, programs that cannot be distributed are meaningless to the community, no matter what languages they use.
In fact, you look only at your own needs and do not take into account the needs of other users. You do not and do not want to do business in this community, and you only broadcast the motivation to make money in the market. And you can make money in the market without any software at all.
bad example - not needed!
@Roffild already wrote in the thread"In today's world, a programmer must know several languages in order to choose the right tool for a particular task. "
this is true!
In MQL there is no choice of packages for MQL - only AlgLib - I want to consider an example, found on Habra, I take and connect C# or Python to MQL - that's all, I do what I want to do, not porting code to MQL
These days programming languages are interesting not for their features but for ready-made frameworks! - If in MQL there will be new MQL packages, then there will be other tasks and problems!
ZS: once again on your fingers, you're clinging to the "fix idea" that grew out of the cross-platform languages Python and Java, the sacrifice for portability and flexibility of the language was the loss of performance, now these languages have become surrounded by different ways of increasing performance, but in C-like languages developers always achieve maximum performance and there is no need (in most cases) to divide the task into separate threads (client - server tasks are not included, there the problem is the data exchange speed and this is another specificity)
Igor, you sometimes contradict yourself.
Last time you wrote that mql calculation speed is comparable to C++ speed
OK, this is indeed true and many people know it.
But then you give an example of connecting third party frameworks to port calculations, as you put it on lagging languages.
And you advocate for third party package connectivity. So you're sacrificing speed for an off-the-shelf framework?
And thus, as Peter wrote, you completely lose portability of your program.
Not a good solution. For personal use, yes, but not for mass use.
Imagine not finding it.
Search for callback and eventloop does not find anything like this in the documentation.
If you do not mind, give me a link without unnecessary sarcasm.
You don't have to do a search, you have to read everything. I'm sure there are many surprises in there for you.
There won't be any links.
I've helped people here more than once who've at least tried to do something for themselves.
And what have you done?
You just sit there and watch your mouth on the forum?
Well, I'm helping you with that.