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
Yes, these units have both. But trust me - they are compressed to the max and versatile, because they solve a wide range of problems.
If there aren't many options, you can get by with ifs and swipes.
Why hasn't anyone decided to argue about "procedural programming with function pointers vs. procedural programming without function pointers"?
If there aren't many options, you can get by with ifs and swipes.
Реter Konow:
1. Дело в работе которую нужно провести чтобы сжать в коде решения огромного количества задач.
2. The point is to universalise the code, in which any additional syntax techniques and shells are simply destructive. It's hard work, but it gets rid of everything superfluous and allows you to evolve all the time reaching new heights.
1. Why do the work when you can make it easy and simple? Why make it difficult when you can make it easy?
2. If you use OOP, universalization is not destructive, but becomes a natural possibility not burdening anything.
1. Why do the work when it can be done easily and easily? Why do something that can be done easily when it is difficult?
2. If you use OOP, then universalisation is not ruinous, but becomes a natural possibility not burdening anything.
We can go on with this argument for a long time. Using the example of a 100-trailing task, I showed my attitude to this solution method. I believe that stupid tasks should not be solved but fixed. If OOP helps those who are weaker in setting tasks correctly and solving them effectively - let it continue helping them. But for people who optimize tasks before they start solving them, OOP may simply not be needed.
We could go on and on with this argument. Using the example of a 100-trailing task, I showed my attitude to this solution method. I believe that stupid tasks should not be solved but fixed. If OOP helps those, who are weaker in raising and solving tasks correctly, let it help them. But for people who optimize tasks before they start solving them, OOP may simply not be needed.
You haven't coded much (probably), OOP is like a breath of air.
Most people code not for interest or self-development, it's their job, and it's the result that counts.
It is not near as convenient, but in terms of speed capabilities, you can get by with pointers alone.
And convenience is a relative concept.
Dmitry, of course using OOP reduces performance a bit. But it is fractions of a percent.
But how OOP increases a programmer's performance!
Here's a small example from one of my projects, it is cutted for perception, but actually there are a lot of other things taken into account.
For example, let's take .NET, as all the API's consist of classes.
I like the .NET paradigm very much. By the way, there is a great terminal cAlgo, you can write directly in Visual Studio in C#
Dimitri, of course using OOP reduces performance a bit. But it's fractions of a percent.
If the number of variants is small, it will slow it down, but if there are too many variants, it will be an advantage.
What's most important, the number of variants in OOP doesn't affect the performance. And in procedural programming, there is a ceiling over your head.
Well, you've made a mess of it...
It's clear that any task can be solved both in OOP-style, with allocation of interfaces, building inheritance hierarchy, declaration of virtual functions, and in pure procedural style - you can even stick everything in one huge function.
The question is in the convenience and efficiency of support.
In MT - the most OOP-appropriate place is the order system. Personally, I have virtual interfaces for "position" and "position components". "Position" is a set of orders in MT4 or a set of positions in MT5. "Position component" is an individual order or an individual MT5 position (hedge or netting).
Here's the actual interface file(Retag Konow, you can appreciate the number of comments compared to the amount of code, and I periodically add them there when I encounter that I don't remember some subtleties. For example, I regularly forget which real objects constitute a "position component". I just don't need to remember it - the Expert Advisor works with components according to the interface, and what's behind that interface in reality doesn't matter. But, I have to return to it during modification - that's why I need the first comment in this file very often):
The file for the trade component interface is as follows (I've already given it above, but I'll repeat it:
According to these interfaces - I have both MT4 and MT5 order system implemented for both real and historical orders.
The Expert Advisor requesting a position receives this interface and does not have to take into account the difference between MT4 and MT5 orders. And if a new order type is added or the order of working with them is changed - nothing will change for the Expert Advisor, only the new order type class will be added, and it will also support this interface.
The system made a lot of sense when hedged accounts were introduced. The experts have not changed at all.
Reg Konow, how do you deal with the difference in order types in MT4 and MT5 ?
If a new account type is introduced (in addition to hedge and netting) - what changes will need to be made, and in the same place ?
My opinion is that if you remember all your code to a letter, and you can easily tell why this or that line in your code was written a year ago - then it's true, all these OOP-enhancers are just unnecessary gestures.
OOP is necessary exactly when you do not remember everything when modifying the code - OOP allows to isolate blocks from each other, limit the set of entities available at any given moment to a particular place in the program.
Well, you've made a mess of it...
1. It's clear that any task can be solved both in OOP-style, with allocation of interfaces, building inheritance hierarchy, declaration of virtual functions, and in pure procedural style - we can even put everything into one huge function.
The question is in the convenience and efficiency of support.
2. In MT - the most OOP-appropriate place is the order system. Personally, I have virtual interfaces "positions" and "position components". "Position" is a set of orders in MT4 or a set of positions in MT5. "Position component" is an individual order or an individual MT5 position (hedged or netting).
3. Here's the actual interface file(Retag Konow, you can appreciate the number of comments compared to the amount of code, and I periodically add them there when I encounter that I don't remember some subtleties. For example, I regularly forget which real objects constitute a "position component". I just don't need to remember it - the Expert Advisor works with components according to the interface, and what's behind that interface in reality doesn't matter. But, I have to return to it during modification - that's why I need the first comment in this file very often):
The file for the trade component interface is as follows (I've already given it above, but I'll repeat it:
According to these interfaces - I have both MT4 and MT5 order system implemented for both real and historical orders.
The Expert Advisor requesting a position receives this interface and does not have to take into account the difference between MT4 and MT5 orders. And if a new order type is added or the order of working with them is changed - nothing will change for the Expert Advisor, only a new order type will be added, and it will also support this interface.
The system proved to be very reasonable, when hedging accounts were introduced. The experts have not changed at all from that.
4. Reg Konow, how do you deal with the difference in order types in MT4 and MT5 ?
If a new account type is introduced (in addition to hedge and netting) - what changes will need to be made, and in the same place ?
I think that if you remember all your code to a letter, and you can easily tell why this or that line was written in your code a year ago - then all these OOP-enhancers are just unnecessary gestures.
OOP is necessary precisely when you do not remember everything when modifying code - OOP allows you to isolate blocks from each other to limit the set of entities available at any given moment to a particular place in the program.
1. 1. I absolutely agree. The only difference is in the effectiveness of solving tasks in one way or another.
2. I have not really worked with the order system and cannot see any technical problems in its construction. Perhaps there are, but we need a concrete task and then it will become clear how effectively I can solve it without the OOP.
3. From my point of view, the given code sample is simply awful from the readability point of view. No wonder so many comments are required and why you forget its content. Sorry, but that's my subjective first impression. It's just creepy.
Here is an example of readability of my code - the function that defines colour of a control's item:
As you can see, comments are almost unnecessary here. All my code is written in this style. So I know it perfectly well and remember it no matter what size it is.
In my opinion, there is some defect in your problem solving system. The problem itself should be crystal clear and precise, and hence its solution too. If the solution is cloudy and defined by the words "The system proved to be very reasonable" (how can it be reasonable in 270 Kb of code?!), it means that the author has a rough understanding of how his system works. And it's terrible syntax contrivances and superfluous entities in the solution which prevent him from understanding it to the end.
For a solution to be effective, unnecessary entities must be cut off, and the problem must be seen perfectly clearly.