Talking about the PLO in the lounge - page 7
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
ZS: by the way, I didn't see a single wish for coverage of any topic in the whole thread, as usual, the usual wrangling.
Judging by the choice of the initial example, there are reasonable doubts about the quality of coverage
Can we be more specific about who they are and what they haven't learned? Moderators have not learned how to clean or something else )
ZS: by the way, in the whole thread did not see a single wish to cover any topic, as always, the usual wrangling. So I decided to record videos on YouTube from scratch on how OOP works, at least it will be of some use. Anyway, in a while the branch will end up in the branch_sucker.
Let me be more precise: they haven't learned how to use OOP.
Alexey, I think you are well aware of yourself that you cannot simply learn OOP. There is a formal knowledge of OOP: inheritance, encapsulation, polymorphism - all these mantras are often repeated, but there is more harm than good from someone memorizing them and violently and inappropriately applying, such as an Expert class to inherit from an MM module (hello to SB developers:).
As for MQL - it is a very weak language in terms of OOP: type control is completely absent (at least they implemented safe casting), reflection is in its infancy and very limited, there are no interfaces at all. The question arises: what kind of OOP can be taught in MQL? What to say, if developers themselves are making such a mess in the Standard Library that sometimes it's just scary.
To be more precise: we have not learned OOP.
Alexey, I think you are well aware of the fact that you cannot just learn OOP. There is a formal knowledge of OOP: inheritance, encapsulation, polymorphism - all these mantras are often repeated, but there is more harm than good from someone memorizing them and violently and inappropriately applying, such as an Expert class to inherit from an MM module (hi to SB developers:).
As for MQL - it is a very weak language in terms of OOP: type control is completely absent (at least they implemented safe casting), reflection is in its infancy and very limited, there are no interfaces at all. The question arises: what kind of OOP can be taught in MQL? What to say, if developers themselves mold such a hump in the Standard Library that sometimes it's just scary.
Yes, it's weak, but projects of medium severity can still be done. SB has been done by different people with different levels of training. And it lacks the essentials, I still use your CDictionary, and it's the mast due thing.
So, what now, lie down and die? )) You may go into dll after all.
You may learn OOP, I think. I learned it myself. And so did others.
And you can still learn OOP, I think. I learned it myself. And so have others.
So you have to learn from the right examples. But there are none in SB. Take CObject for example - it doesn't provide type control, it doesn't provide interface-level work with objects, but it contains meaningless methods like Save() and Load() which are never redefined in practice. The m_prev and m_next pointers are used in a single CList class, but are present as ballast for all its descendant classes. The most useful is the Comparer() method. It is actually overridden most often. But in a good way Comparer() is an interface, it should not be defined in the CObject, but as a separate class.
Apparently static and const (this is not OOP) are not needed.
As for OOP, it is very interesting how the next function, which has wide practical application (not abstract at all), would look like in procedural style?
Obviously, any OOP can be rewritten in procedural style. But I'm interested in practice. So I took the above tiny code, where OOP is also used to a minimum.
So how much nicer/more convenient/more readable/more correct is procedural style compared to OOP in this example? Well, not to talk for a few pages, but just to compare short source code procedural vs OOP. I ask OOP opponents to show a masterclass. This is not the dreaded MT5, but good old MT4.
How do you learn to program in the same way? :) it looks very nice.
Or maybe you need to change your mindset.
for example, i didn't know that structures can be used almost the same way as classes, with a constructor
for example, I didn't know that structures can be used almost the same way as classes, with a constructor
what moulds can you learn to program in exactly the same way? :) it looks very nice
or maybe you need to change your mindset as well.
for example, i didn't know that structures can be used almost like classes, with a constructor
And may I ask: what genius do you see in fxsaber's code? Maybe it's the side effects of IsChange that captivated you, or the idea that the system state must be duplicated at the user level?
May I ask: what genius do you see in fxsaber's codes? Maybe it's the side effects of IsChange that fascinate you, or the idea that system state should be duplicated at user level?
Probably because I hardly understand this code :)
Sorry, I'm an amateur programmer... I'm only familiar with OOP at a basic level
In C++, class and structure are the same, just some defaults are different.
That's cool, I didn't know that... I guess I just need to learn the pros better.
So you have to learn from the right examples. And there are none in SB. Take CObject for example - it doesn't provide type control, it doesn't provide interface-level work with objects, but it contains meaningless methods like Save() and Load(), which are never redefined in practice. The m_prev and m_next pointers are used in a single CList class, but are present as ballast for all its descendant classes. The most useful is the Comparer() method. It is actually overridden most often. But in a good way Comparer() is an interface, it should not be defined in the CObject, but as a separate class.