Adviser's project - page 6
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
In the civilised world, lists are implemented through...
Why don't you write a civilized library in MQL, and then we'll talk. We've been hearing these cries for years, and when you get down to it, you start outright bodlocoding.
MQ really made a mistake with references in CObject. They should not be there. And these references are used in very specific containers like CList. But where there are no errors? Civilized languages, you say? Read Richter's critique what he thinks about Object C# and what methods it should not contain. So because Richter is right, we should refuse to use C#? Nonsense. So stop piling on here and go to your procedural jungle at last.
Well, yes, you can't put constant objects in a list.
However, I constantly use CObject functionality, and none of the critics did not offer anything even similar to the Standard Library objects arrays and lists.
"The way things should be done" is everyone's yelling. But to suggest something, all of a sudden, there is nothing.
Even those participants who actually offer different software solutions - do not offer a replacement for the CObject - more often do not use it at all, less often use its functionality, not paying attention to "implementation through one place". And this means that the implementation is quite good.
If it was bad, a replacement would have been suggested long ago.
Usually the native CObject is used when everything else is also based on the standard library. In particular those who actively share their sources, tend to unify, reduce self-written code and reduce number of their own libraries to make life easier for external users. But everyone decides for himself, whether he is coding for himself or for the convenience of others.
However, I suppose many people use their own solutions (like me), they just don't see the need to offer them to others. But in general I think it would be better if there was some standard based on some well-known libraries, such as MFC. That's why I don't really understand MQ, why they had to re-invent their own wheel (besides very controversial) instead of porting a ready-made solution. However the same can be said about the MQL language itself )))
But in principle, I'm not enforced to refuse from CObject, I just made my critical remark in response to the phrase, that someone should use CMyCobject when there's a very cool CObject from MQ :)
Write a civilized library in MQL, and then we'll talk. You've been yelling for years, but when you get down to it, you start outright bodlocoding.
Well, I have my own libraries. So what did you want to talk about?
I really messed up with references in CObject MQ. They must not be there. And these references are used in very specific containers like CList. But where there are no errors? Civilized languages, you say? Read Richter's critique what he thinks about Object C# and what methods it should not contain. So because Richter is right, we should refuse to use C#? Nonsense. So stop piling on here and go to your procedural jungle at last.
Don't be arrogant and rude, I'm not talking to you personally.
About "messed up with the links" - well, yes, funny, after I've already painted everything about it. Although earlier you've literally dribbled on CObject, that it's so great, and that even the pointers aren't initialized there by default (at least you should have studied the source code of your language first). Anyway, I do not see any sense to cast aspersions on you here anymore.
But I agree, it is not always necessary to use OOP.
Say, I have CDataProvider:pulic CDataProviderI class - data provider, which provides Expert Advisor with timeseries, indicators, terminal and environment data. In an Expert Advisor, there can be many TSs - each of them would receive pointers to timeseries and indicators from the data provider (each TS would not need to create timeseries - data provider would provide pointers to the necessary timeseries if they already exist, and would only create timeseries, which have not been created yet).
When you need to get an indicator from the data provider - fill the indicator description structure, and then request an indicator from the provider, pointing to this structure.
Accordingly, each indicator inside the data provider should be able to identify its structure (the data provider "knows" only the abstract base class of the structure) and according to it create the ready indicator object, which will be created by data provider.
But, it would be unreasonable to start such a project just for the purpose of checking a new idea of an indicator. As a result, for such new indicators everything is "by hand", without any OOP. However, if I see that an indicator is useful for Expert Advisors - it is written "properly" - with full OOP support, and creation inside a data provider.
When I tested all indicators in MT4 about 15 years ago for suitability to trade in reverse order mode, I found only 1 that allows to make profit on the daily. most indicators are based on built in indicators, that's why trading results are low almost for all of them. I think the first task of any trader is to study the market for prediction accuracy or profitability of a pattern.
with respect.
The main thing is that they can not confuse you with the direction in which you go and see the realization of their ideas. The aim of this whole circus, to confuse and direct in the wrong direction, away from profit.
Well you've answered your own question why you should use CObject, rather than self-written bicycle. This is necessary to make life easier not only for others but primarily for yourself, because the words "unification", "reduce self-written code", "reduce the number of your own libraries" - this is what every developer should strive for. This is the programmer's holy grail.
Of course, the standard library is obsolete. The language now allows you to do generics, and interfaces are coming. But the old library works and it is a good unification, and as they say the best is the enemy of the good. Since there is no such thing as the perfect and the best you have to use the good.
About "messed up with the links" - well, yeah, it's funny, after I've already written all about it. Although earlier you've literally "crapped" on CObject stating that it's so great, and that even the pointers aren't initialized there by default (you should at least study the source language to begin with). In general, I do not see the point of casting aspersions on you.
No one will grovel before you here. Believe me, the "hidden" knowledge that you "revealed" to us all here has long been known to many. I will not even argue about link initialization. You know that you're formally right, so you try to rub my nose in the same thing: read the math, learn what NULL, etc., etc. But you don't have to teach me. You're cool. You got it all. So why are you throwing beads at us? Go to your library. See if it gets 0.5% faster.
Fractals and pinbars indicators are also often used. It's a wonderful solution for many trading systems that use the same indicators in their trading. but they are not suitable for tests, that's why they do it out of necessity.
15 years ago I was testing all indicators in MT4 for suitability to trade in reverse position mode and found only one that turned out to be profitable on a daily basis.
No, you just have to get the essence of the indicator right. An indicator is not a ready-made Grail, but just a convenient expression of some peculiarities of price movements. Therefore, we should not treat them as "the final signal source", but just as a "signal feature" and use them as a complex. And in this case - many indicators start to be needed in most tests. In particular, ATR, for example, I'm already thinking about standardizing it in an Expert Advisor's template because I use it virtually everywhere. MA MAs are also quite often required indicators. Fractals, pinbar indicators...
...
But, I agree, it is far from always necessary to use OOP.
Say, I have a class CDataProvider:pulic CDataProviderI - a data provider, which provides expert with timeseries, indicators, terminal and environment data. In an Expert Advisor, there can be many TSs - each of them would receive pointers to timeseries and indicators from the data provider (each TS would not need to create timeseries - the data provider would provide pointers to the necessary timeseries if they already exist, and would only create timeseries, which have not been created yet).
When you need to get an indicator from the data provider - fill the indicator description structure, and then request an indicator from the provider, pointing to this structure.
Accordingly, each indicator inside the data provider should be able to identify its structure (the data provider "knows" only the abstract base class of the structure) and according to it create the ready indicator object, which will be created by data provider.
But, it would be unreasonable to start such a project just for the purpose of checking a new idea of an indicator. As a result, for such new indicators everything is "by hand", without any OOP. However, if I see that an indicator is useful for Expert Advisors, it is written "properly" - with full OOP support and creation inside a dataprovider.
P.S.
By the way, in the case of indicators and data provider we see the advantage of virtualization inheritance. We have the basic interface of indicator parameters CIndicatorParametersI; the descendant of this interface is the real parameters of the necessary indicator. When requesting the indicator, we declare these parameters and pass to the data provider a pointer to the abstract interface. Thus the data provider itself doesn't even know what indicator is requested - it is defined in one function, in which the indicator is created according to the new type. And what exactly parameters were passed - only this created indicator knows, it extracts the required parameters from the passed object.
The trick is that almost everywhere inside the dataprovider there is a simple basic class of parameters (or indicators) - only the simplest and most common functions of basic interfaces are available to the dataprovider. This simplifies the code modification (when it is needed), and does not create the temptation to "tamper" with the code of indicators from the data provider. If you want to change an indicator, it is done only inside the indicator, the data provider is only a storage of indicators, the maximum it can do is to create a new indicator.
I think you are making it too complicated. The date-provider is MetaTrader itself. I.e. the date-provider is not really needed, it needs only a convenient interface for working with data. For example, in my Libera, you just need to write the opening price of the last bar:
The WS object is always there and it is always at hand and working. How it does it is hidden behind the scenes. That's all access to data:)
s.o.p. OOP should reduce the complexity of use of the system, not increase it. If you admit that you have to build a garden for a simple check, it means that you have something wrong with your architecture with provider. That is, you have programmed something that you don't always want to use.No, you just have to get the essence of the indicator right. An indicator is not a ready-made Grail, but just a convenient expression of some peculiarities of price movements. Therefore, we should not treat them as "the final signal source", but just as a "signal feature" and use them as a complex. And in this case - many indicators start to be needed in most tests. In particular, ATR, for example, I'm already thinking about standardizing it in an Expert Advisor's template because I use it virtually everywhere. MA MAs are also quite often required indicators. Fractals, pinbar indicators...
i meant working in the "always in market" mode based on the reversal indicator's signal, and again, 15 years ago, now my vision of the market has slightly changed.
with respect.
I think you're making it more complicated than it needs to be. The data provider is MetaTrader itself. That is, you don't really need a date-provider, you just need a user-friendly interface for working with data. For example, in my Libera, you just need to write the opening price of the last bar:
The WS object is always there and it is always at hand and working. How it does it is hidden behind the scenes. That's all access to the data:)
s.w. OOP should reduce the complexity of using the system, not increase it. And if you yourself admit that you have to build a garden for a simple check, it means that there's something wrong with your ISP architecture. That is, you have programmed something that you do not always want to use.Your (let's be "you") entry "WS.Open[0];" differs very little from my entry "m_tcMainContainer.Open(0)"
I suspect there must be some preliminary action in the initialization for the WS object.
In my case we should call bool _LoadMainTimeseriesToLocalContainer(uint uiNeedBuffer) function.
In each part of an Expert Advisor (in the generator of inputs, in controllers of trailing and exit, i.e. in objects that can perform trade actions) I have the "Timeseries Container" object - in fact, it is a pointer to OHLCSTVtVr timeseries with additional service options.
There can be many different containers of different symbols and different timeframes in an Expert Advisor. The ideology of the data provider allows not to duplicate them. Since in reality - all timeseries are stored in it, and containers - just point to the necessary ones.
I don't see much difference - as I understand it, WS (WareStore, probably ?) is still the same my dataprovider. It's just that my dataprovider also concentrates the rest of the data - indicators, symbols (CSymbolInfo objects), terminal (CTerminalInfo object), which also has a collection of charts. In each refresh, the timeseries is updated (as needed) - here the ideology is close to that of the Standard Library.
If we consider MT4-5 itself as data provider, and our class is used only for providing access - then it turns out that according to your reference to Open price we must call CopyOpen() function for one value - this seems unreasonable to me.
Giving full global access to all variables at any place of the program I also think it is extremely unreasonable, on the contrary, I try to have access only to those structures and data, which are needed for this action in each place of the program. Everything else must be inaccessible. The ideology of the data provider allows me to control this access.
i don't consider it as an indicator, it shows the average volatility of the market over a certain period of time, it is not suitable as an entry signal (it can be applied as a filter, nothing more).
i meant working in the "always in market" mode based on the reversal indicator's signal, and again, 15 years ago, now my vision of the market has slightly changed.
Respectfully.
What do you mean by "ATR does not count as an indicator" ???
And how is it "not suitable as an entry signal??? And I am a fool, I use "volatility breakdown" entry using only this indicator...?
I so suspect that you have your own, particular understanding of the essence of indicators... To me, an indicator is an object that can produce some variable value, depending on time. In fact, even an ordinary candlestick chart of price is also an indicator. But for you it is something else... Consequently, our understanding is different.