OOP vs procedural programming - page 24
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
1. There is a criterion. The main criterion is speed of operation.
Code visibility is the wrong criterion.
Everybody switch urgently to asambler..... but fast.... it's true what's fast is the proper organization of the whole project or the speed of individual functions
Everyone move urgently to asambler..... but fast.... but what is fast is the proper organisation of the whole project or the speed of individual functions.
Everyone move urgently to asambler..... but fast.... really what is fast is the proper organisation of the whole project or the speed of individual functions
No, keep coding through the ***.
Well, I disagree.
Code clarity is a very important thing, because clear code is much easier to maintain and modify.
That's right - I wrote a naked function, and then I actually "obfuscated" it, made it non-visible and incomprehensible. This was a forced decision. In this case, it was more important to me to make the entire class transparent. I have sacrificed the clarity of one quite trivial function. Of course, I could have put the body of this function in .mq5 file, but I believe that the interfaces should not be divided into two files and should be completely described in the header file .mqh.
Speed is also something to keep in mind, but I don't think we should strive for "speed at any cost". There has to be a reasonable sufficiency.
Probably the same point 3 for you too
I've been programming for a long time. Since the release of MT3.
Since then I feel more comfortable writing in procedural style on mql4. I do not have EAs on 1001 lines. Moreover, I have only some functions stored in libraries.
And in MQL5 I use the standard library. It is a convenient thing.
But performance optimization should be done to avoid calling more and more heavy functions. Recently, I have been modifying one EA from Mql4 to MQL5. I have used library presented here. It took me half a day to figure out all functions and it worked, but the optimization was very slow. I have cut indicator to 2 bars and everything started to fly.
The conclusion is simple. Everyone can write in any style. MQL is not really a language that requires code optimization in order to gain a couple of milliseconds through procedural programming. Logical tasks are more important. The way they are implemented has practically no effect on the speed.
...
The conclusion is simple. Everyone can write in any style. MQL is not really a language, which requires optimization of code, so that it can gain a couple of milliseconds by using procedural programming. Logical tasks are more important. The way they are implemented has practically no effect on the speed.
So softly unobtrusively let down that it is procedural programming that provides high performance. For three days now I've been showing you a problem which can be solved only by OOP without unnecessary brakes.
OOP allows us to screen sets of variables from the rest of the code, which allows us to avoid passing parameters to methods when performing calculations inside a class, and this is a significant factor for speed. Even if you do it in procedural style, you will have to create a huge number of global variables, and as a result the readability of the code is impossibly low.
It was so gently let down that it is procedural programming that provides high performance. For three days I have been showing here a problem that only OOP can solve without unnecessary brakes.
OOP allows us to screen sets of variables from the rest of the code, which allows us to avoid passing parameters to methods when performing calculations inside a class, and this is a significant factor for speed. Even if you do so in a procedural style, you will have to create a huge number of global variables, and as a result the readability of the code is impossibly low.
The gain of procedural style is negligible, because the code is started with every tick in Expert Advisors. And there can be hundreds or even tens of milliseconds between ticks. I never bothered with indicators. I have not found any real profit of indicators.
I think it would be more convenient to write large projects using OOP. I myself prefer to use structures, if I have to save something.
In this case, the access to data is more clearly arranged and the pull-down menu is very convenient to use. If you replace structures with arrays, confusion often arises and the number of arrays grows.
In my previous post I was putting the emphasis specifically on calling heavy functions. For example, some sort of loop loops which don't need to be called on every tick. And you don't have to do it on each new bar either.
That's where the real performance gain can be increased.
Yeah. It's a funny debate: excavator vs shovel.
I guess if you want to plant a tree, a shovel is better. But if you want to dig a hole, the backhoe is probably better.
Yeah. It's a funny debate: Excavator vs shovel.
I guess if you want to plant a tree, a shovel is better. But if you want to dig a hole, the backhoe is probably better.
Yeah. It's a funny debate: excavator vs shovel.
I guess if you want to plant a tree, a shovel is better. But if you want to dig a hole, the backhoe is probably better.