OOP vs procedural programming - page 38
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
MyOnInit() looks about the same - a dozen lines...
So?
Wow!
I was wondering: is there any other way in modern programming to mess up a problem at the level of a kernel?
And the fact that this is the whole program... there is nothing else :-)
Of course not.
Everything else in ashes + R (he doesn't count)
Debugging is all about debugging the logic: the intersection of two mashas is there, but the signal is not. There are problems in understanding the values of variables from the terminal. The main thing here is not to change the account type and preferably not to change the broker.
I don't know about all those passions that they write here above.
Of course not.
Everything else in ashes + R (he doesn't count)
Debugging is all about debugging the logic: the intersection of two mashas is there, but the signal is not. There are problems in understanding the values of variables from the terminal. The main thing here is not to change the account type and preferably not to change the broker.
I am not aware of any of the passions described above.
Just frankly, do you have a real account at all? The passions are just from encounters with the real world and the bruises of exploitation/maintenance...and for a tester, it doesn't matter what to write on or how to write...
OOP is a method to separate, wrap and hide parts of a mechanism. Whether this is necessary or not, is up to the developer to decide. It has nothing to do with increasing the efficiency of the mechanism at all. It structures the way of thinking, yes. It is unknown whether it structures it correctly or not. Whether it is necessary depends on the person. imho.
There is always a problem when writing functions:
1. you write a function
2. you write another function and see that it is very similar, but different from the first.
There is always a dilemma: should you lump it into one or keep two? You get more versatile but more complicated code. You get simple code but a bunch of functions. That's how it is with this OOP.
If you manage to allocate a small number of classes that are well structured and clear,
if you write a lot of Expert Advisors
if you often modify them for some reason
THEN
OOP is useful.
If not, then there is no need to fill your head with information, which has nothing to do with trading, and it would be better to spend time on R.
Good luck to you all!
Only frankly - at least one real account? The passions are just from collisions with the real world and the bruises of operation/ maintenance... and for the tester, it doesn't matter what and how to write on...
Since 2008, including PAMM.
There are no problems with maintenance.
But with exploitation...
Spread is increased up to 20, then the margin is multiplied, then the gap, then the light is turned off.... then my wife wipes dust on the touch buttons... I've had enough of it. That's why this branch is like being in China.
There is always a problem when writing functions:
1. you write a function
2. you write another function and see that it is very similar but different from the first.
There is always a dilemma: should you lump it into one or keep two? You get more versatile but more complicated code. You get simple code but a bunch of functions. That's how it is with this OOP.
If you manage to allocate a small number of classes that are well structured and clear,
if you write a lot of Expert Advisors
if you often modify them for some reason
THEN
OOP is useful.
I personally strive for universality in solutions. This requires to "splice" similar functions into one block without increasing code size. It increases efficiency of the mechanism and there is no need in overloading and division. Just use your brain a bit and that's all).
That is, there were two functions of 20 lines each. Both of them perform similar actions or solve similar tasks. My aim is to make one function of no more than 20 lines of code that performs the work of both functions. This is how blocks appear.
PS.
There used to be a rubric for pearls.
This is in it.
A program manual is not documentation.
A manual is a description of the functionality of a program (what the program can do). It is necessary for the user.
Documentation is a description of the structure of the program (how the program is built). It is necessary for the programmer.
There is no conflict of terms.
...
If you don't have that, then there's no point clogging your head with information that has nothing to do with trading at all, and it's better to spend your time on R
Good luck to you all!
Demonstrate in trading the effectiveness of R-- you've spent enough time on it. Take part in contests - 1.September; 2.quarterly
https://www.mql5.com/ru/forum/212596
1. How much has the profitability of your EAs increased by using OOPs?
2. By how much has your EA's MTBF decreased?
2. What a bummer))))) the MTBF of a computer program... clinic!