Asynchronous and multi-threaded programming in MQL - page 12
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
(Dumbest talk, sorry. ))
excuse me who? people I don't know? ))) - this is a forum - wiki to the rescue... it's a platform where everyone expresses/defends their opinions, no more and no less - and in the course of communication, technical aspects and/or the exchange of experiences are clarified, as applied to this resource!
ZS:
in your opinion, OK, you're a developer of "the right graphical feature" - yes it's necessary!
- But you have to be able to create either a familiar to other programmers functionality (unfortunately, everyone learns from the same literature and subsequently use the functionality offered by the IT giants - i.e. the familiar, understandable and accessible functionality)
- or should you provide some powerful analytical package, wrapped in a graphical interface, that allows you to study/model data - are you capable? - Can you compete with e.g. the R package?
;)
To search, to develop a TS (some don't even need a TS, George for example doesn't care what TS is), MT4 is enough. What are we talking about then? Everyone has his own needs. One lives well in a monastery, and the other wants to go all over the world. In short, this conversation is about nothing. It's like me asking an artist why he should paint a picture if he can just take a stupid picture of nature. It's a stupid conversation, sorry. ))
To the same view, alas, came to me, talking here with the local "experts" ((
If the developers will create the EventLoop for asynchronous code writing, respect and admiration, as they say.
And the terminal will be a leader in its product segment, making everyone in every sense of the word, all the other world terminal developers.
They know exactly where there are problems, which require asynchronous execution, but for some reason the same indicators are still executed in one thread.
And there is an assumption by other users, that for this reason they do not implement tick-table charts - they allegedly fear that users will attach a lot of indicators to a tick-table chart.
And this is just the visible part, so listening to local experts is not always useful, alas, they are just stuck in a single thread when the world has long been multi-threaded already.
excuse me who? people I don't know? ))) - this is a forum - wiki to the rescue... it's a platform where everyone expresses/defends their opinions, no more and no less - and in the course of communication, technical aspects and/or the exchange of experiences are clarified, as applied to this resource!
ZS:
in your opinion, OK, you're a developer of "the right graphical feature" - yes it's necessary!
- But you have to be able to create either a familiar to other programmers functionality (unfortunately, everyone learns from the same literature and subsequently use the functionality offered by the IT giants - i.e. the familiar, understandable and accessible functionality)
- or should you provide some powerful analytical package, wrapped in a graphical interface, that allows you to study/model data - are you capable? - Can you compete with e.g. the R package?
;)
I have come to the same opinion, alas, after talking to the local "experts" here ((.
If the developers will make EventLoop for asynchronous code writing, then kudos and respect as they say.
And the terminal will be the leader in its product segment, making everyone in every sense of the word, all the other world terminal developments.
They know exactly where there are problems requiring asynchronous execution, but for some reason the same indicators are still executed in a single thread.
And there is an assumption from other users, that for this reason they don't implement tick-charts - they are afraid of negative consequences, when users attach a bunch of indicators to the tick-chart.
And this is just the visible part, so listening to local experts is not always useful, alas, they are just stuck in a single thread when the world has long been multi-threaded already.
Trying to understand your logic. I mean, if I'm not able to compete with the R-package, then I don't need multithreading? What's the connection here. Are you trying to prove that if you don't need it, no one else should? I repeat: everybody has different tasks. I have mine, you have yours.
The logic is simple - the end user, if you have a demand for at least 1-2 users per month, my respect - you have found your niche!
The logic is simple - the end user, if you have a demand for at least 1-2 users per month, my respect - you have found your niche!
To the same opinion alas came to me, and I've communicated here with the local "experts" ((
If the developers will do EventLoop for asynchronous code writing, respect as they say.
And the terminal will be the leader in its product segment, making everyone, in every sense of the word, all the other world terminal developments.
They know exactly where there are problems requiring asynchronous execution, but for some reason the same indicators are still executed in a single thread.
And there is an assumption from other users, that for this reason they don't implement tick-charts - they are afraid of negative consequences, when users attach a bunch of indicators to the tick-chart.
And this is just the visible part, so listening to local experts is not always useful, alas, they are just stuck in a single thread when the world has long been multi-threaded already.
"experts"? - You have nothing to talk about, shove your imho... This is a big MQL community with professionals in different fields, unfortunately, you haven't shown any of your knowledge that would be useful to the community, you can accuse me of anything you want - "you're the expert! "
Developers will do? - You can't explain even WHY it's needed, can you? )))
what is the purpose of MetaQoutes? - the goal, as any IT company to make a profit! i don't know why, MetaQoutes is very serious about promoting its services, a lot of work is done to popularize algorithmic trading, to give analytical material, to create an online community... this kind of charity only a few IT companies do, usually the IT giants
so, the company spends its resources on something which in the future (not sure) will make a profit.... and then, lo and behold... a user comes along who needs to adapt the concept of retarded Python or Java to MQl.... Don't you think it's funny? - how old are you? ))))
We'll know soon enough. We don't know yet.
I respect you, persistence is often the only way to find your niche in this life! Good luck in this hard work!
...
If they add multithreading, will it make you feel worse? They've already added a lot of things to MQL, and it's a really useful thing. But its usefulness can be understood only by a person, who writes very complex, cumbersome programs in MQL. If you do not understand what the multi-threading is for, it means that you don't write such programs. When you do, you will understand. It's very simple. ))
...
I respect that persistence is often the only way to find your niche in life! Good luck with that hard work!
Thank you. Same to you!
I have come to the same opinion, alas, after talking to the local "experts" here ((
If the developers will make EventLoop for asynchronous code writing, then kudos and respect as they say.
And the terminal will be the leader in its product segment, making everyone, in every sense of the word, all the other world terminal developments.
They know exactly where there are problems requiring asynchronous execution, but for some reason the same indicators are still executed in a single thread.
And there is an assumption from other users, that for this reason they don't implement tick-charts - they are afraid of negative consequences, when users attach a bunch of indicators to the tick-chart.
And this is just the visible part, so listening to local experts is not always useful, alas, they are just stuck in a single thread when the world has long been multi-threaded already.
You demand asynchronous query execution, but cite multithreading as an example... I encouraged you to figure it out, but you never did.
I gave you a solution to your exact problem here: https://www.mql5.com/ru/forum/318593/page4#comment_12568119
But I'm sure you haven't even studied the subject.
Seems to me, if you're given an asynchronous queue, you'll still ask for multithreading... At least try to understand OVERLAPPED and events for a start, aren't you asking WinAPI into your code).
If you introduce multithreading into the terminal, it will bury itself from woeful programmers, faster than the speed of light.
Programmers are looking for solutions to problems, not asking the framework to change to suit their ignorance.