Interesting topic for many: what's new in MetaTrader 4 and MQL4 - big changes on the way - page 9
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
Now that we've touched the market, I'd like to hear opinions on one subject...
According to the philosophy of MQL5, indicators should count and EAs should trade.
But Market sells ready-made solutions, as they say, all in one.
How about improving the compiler so that indicators are stored in EAs as resources?
Otherwise, we have to transfer the code of the indicator to the Expert Advisor where it has no proper environment. Again, the scheme "indicator from indicator" makes it a whole epopee to transfer the code to the Expert Advisor.
I agree,
I think it would be useful to add a tab for the Market now - FILES, where you can put sets, instructions, etc,
I think it would be useful to add a tab - FILES where you can store sets, instructions and so on.
Can we refine the compiler to store indicators in EAs as resources?
Otherwise we have to move the code of an indicator to an Expert Advisor, where it has no proper environment. Again, the scheme "indicator from indicator" makes it a whole epic to move the code to the Expert Advisor.
See MetaTrader 5 Client Terminal build 730 on November 24th 2012
8. MQL5: Added support for storing indicators in EX5 resources. At the same time, indicators in resources will not be able to work with their own resources.
See news release MetaTrader 5 Client Terminal build 730 dated 24 November 2012
This is exactly what I do. And I have already written classes which can pass to the Expert Advisor custom history (instead of the real history from the server). But the Expert Advisor should not use functions of the terminal directly to fully implement my idea. Say, the same OrderSend(). It should work only through a "wrapper", the role of which can be wonderfully performed by the Standard Library. We write derived classes, tuck them into the Expert Advisor, and voila - it now works on historical data. If the Expert Advisor uses the functions of the terminal directly, it will not be able to use the history.
Well, perhaps it is due to my long work with the MFC library which I was very pleased with and with which I find a lot of parallels. I am sure that the developers of the Standard Library are also quite well acquainted with MFC.
The main advantage of the Standard Library is the good support of OOP ideology, which allows to pass the Expert Advisor a custom history so that it will work properly without any modifications.
Can I ask what do you dislike about the Standard Library (well, besides the obvious disadvantage - "lazy to learn")?
That's just no such disadvantage, I know SB very well, and this knowledge gives me an understanding of how cumbersome and inefficient everything is.
Instead of sending an order, you start a grandfather for a grandfather and grandfather for a turnip.
But the main disadvantage (according to Trade) is that there is absolutely no control of execution. They just send an order to server and let the grass grow. But they wrapped Send in 10 ways, like for all occasions, but cases turned out to be 100.
As for ideology: inheritance for more than 2 generations is a mistake, further on both understanding and flexibility are lost.
Most classes (you're right) were not invented, they were just re-invented from MFC, but that's not a disadvantage, why reinvent the wheel.
But I think the main drawback is that they cannot rely on it.)
I wrote both with and without SB. Without it you get faster and more transparent. It's too versatile, so it's sluggish on bends.
In Delphi, for example, there is the concept of a project, which implies joint compilation. And the division of programs into 3 types is a bit dubious in general, because the compiler, in theory, can determine itself what the program does, but since it goes so far that indicators only trade by force, and for EA you need to implement code inside, then we can only hope that the developers' heart will ever melt and they will allow to make projects).
seconded,
I think it would be useful to add a FILES tab for the marketplace to store sets, instructions and so on, for example,
although the Discussion tab allows for that, but it's still not the same.
See MetaTrader 5 Client Terminal build 730 dated 24 November 2012
Great, how did I miss this, aaah it's the pre-holiday builds.
Does the crossing in your post mean that they already can?
That's exactly the disadvantage, I know SB very well, and this knowledge gives me an understanding of how cumbersome and inefficient everything is.
Thank you for your comprehensive answer. I have no categorical objections to any of your statements. Just... some observations...
Instead of sending an order, grandfather for grandfather, grandfather for turnip.
But that's what gives the system flexibility, and that's what allows us to send custom history and server emulation to the EA. If orders were sent directly through OrderSend() - we would have to write this "Grandma's for Grandpa, Grandpa for Grandpa" ourselves... It's not clear what's better...
But the main disadvantage (according to Trade) is that there is absolutely no enforcement control. If you "bump" an order to a server and don't give a damn. But they wrapped Send in 10 ways, like for all occasions, but it turned out to be 100.
I'm not experienced enough here - I may only theorize. I analyze return codes myself, but I have very little experience. I agree that there is not enough control of execution in SB itself.
As for ideology: I consider inheritance for more than 2 generations a mistake, further you lose both understanding and flexibility.
Yes, indeed, too deep inheritance is very detrimental to understanding. But about flexibility - I find it hard to agree. I have a bunch of cases of 4-5 generation inheritance, and it doesn't seem to cause any problems. But, I can agree that this is the case for me, for others this depth of inheritance may be a major hindrance.
But the main disadvantage I think that it is not possible to rely on it, you write something on it and it will be reworked :)
Yes, I completely agree with that.
I wrote both with and without SB. I wrote with SB but without it I got faster and more transparent. It's too versatile, so it's clumsy on bends.
I liked SB for its ability to create a TC template, and subsequently connect only object classes describing inputs, maintenance and outputs to it. I'm afraid that without SB such an ideology would lead to the creation of the same, only Own SB.
About "faster and more transparent" - it seems to me that such ideology is good when we have any TS treated as a whole. However, it seems to me that this is a serious error of algotrading. TS should be viewed only as a set of "cubes" - a set of input generators, determinant of input TP-SL, determinant of input lot, trailing controller and so on... This ideology allows to get hundreds of different TS variants very quickly, where we have only a few "faster and more transparent".
For example, having written five different TS without a template - to write the sixth one we will need to do it all over again, even using parts of these five systems. Having written the template - we will input these five systems into it only in parts, and as a result we will have up to five input generators, input filters, TP-SL determinants and so on. Combining them we easily get a hundred TS, from which we can choose the most stable and profitable ones.
Therefore, in my opinion, the sluggishness of SB is really a "stick with two ends", and its application or non-application should be decided in each case individually.
Super, how did I miss that, ahhhhh are the pre-New Year builds.
Does the crossing out in your post mean they already can?
Great, how did I miss that, ahhh it's the pre-New Year's builds.
It's been discussed here: https://www.mql5.com/ru/forum/3409#comment_408123