What OOP code can do that procedural code can't ? - page 2
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
Programming GUIs was what I did most all my time as a programmer. Its not possible to code a complete GUI which needs to communicate in several directions by if then else. You would need that much statements that the code would become unreadable and in the end much too slow which would result in not reaching the goal. Fact.
I will not build a GUI in procedural language to prove you are wrong. But I could without any doubt.
By the way it's also easy to code unreadable and much slower code in OOP, and as you know the Metaquotes Standard Library is a good proof of this.
...
Due to the circumstance that a CPU does not know anything about OOP, you can - of course - code everything without by just using pointers and complex arrays. But that is absurd. I could also hire 10000 people that draw my screen content on film in kinda realtime and beam it sequentially by a light projector on the wall. Is this also reaching the goal?
Do you agree that Windows operating system is offering a good GUI ? As far as I know it's written in C. Procedural language not OOP.
You are wrong Dirk if you think a complex program could only be build with OOP. You should rather explain why it's better to code it with OOP.
Uh come on ;) Not really ;) If something native could do the job somehow weird, then its pointers, but there are restrictions in MQL. If then else ... the code would become absurd.
I strongly doubt that OOP is a shorter way of coding.
Do you agree that Windows operating system is offering a good GUI ? As far as I know it's written in C. Procedural language not OOP.
You are wrong Dirk if you think a complex program could only be build with OOP. You should rather explain why it's better to code it with OOP.
I coded GUIs in Assembler, entirely. But in Assembler I can work with pointers, in C i can work with pointers and of course the basic of Windows is not OOP, but we talk about MQL which does not support void pointers the native way and because of that, you will not be able to code complex GUIs with just if then else, at least not with a result that can be used without big lack of performance.
And this answer includes already the question, why it is better with OOP - whereby "better" is still the wrong adjecitve. The OOP method implements usage of such pointers but without forcing you to deal with those. Internally, OOP is realized with multi dimensional arrays for function and variable pointers. Trying to code stuff like that is quite the same as re-inventing a wheel which never will roll that smooth as the one you have already in front of you.
I coded GUIs in Assembler, entirely. But in Assembler I can work with pointers, in C i can work with pointers and of course the basic of Windows is not OOP, but we talk about MQL which does not support void pointers the native way and because of that, you will not be able to code complex GUIs with just if then else, at least not with a result that can be used without big lack of performance.
And this answer includes already the question, why it is better with OOP - whereby "better" is still the wrong adjecitve. The OOP method implements usage of such pointers but without forcing you to deal with those. Internally, OOP is realized with multi dimensional arrays for function and variable pointers. Trying to code stuff like that is quite the same as re-inventing a wheel which never will roll that smooth as the one you have already in front of you.
It is only my personal preference due to my small(!) experience!
1) I don't like e.g. Java as I was searching 99% of the time for a function not knowing what might be its name whether it exists or not and whether I have to code it my self anyway ...
2) I don't like C++ because I have to write more than I would nee to write a script like language like mq4 or even Perl.
3) I don't like C++ because understanding someone else' code let me jump from file to file where I find only functions with 2,3 lines which makes it really hard to find out what and how s.th. is calculated. Of course there are explanation like "calculation the stop" but the calc.-procedure is as well split in several functions in different files.
4) I am absolutely fine with enum and arrays of enum-variables. I don't need to code imagined real objects. GUIs might be a different problem as it consists of many other things that could be coded as objects for an easy way of re-using them. But how many different objects does an EA need? One for the positions? If there were a lot of different 'objects' (GUI) it might help - but I don't see them here.
5) Finally MQ5 still can't run its backtest on customer ticks :( <Edited by moderator as off-topic : this has nothing to do with mql5 but with MT5>
i really respects someone who codes assemble, you must have a good knowledge of how hardware itself works, simply amazing, tough noone uses today
I dont code it anymore, but in the past really mainly. On Intel 80x86 chips it was the only chance to achieve a real edge in view of visual performance. And of course, its a basic knowlege that I dont want to miss at all, even if I dont need it in detail anymore, but you always know what happens with your code in the end and you know how to use this as an advantage in view of execution speed.
Yeah "good" old times ;) ... But insane too, there were not even variables, no real functions, no if then else, just registers, stacks, interrupts and memory addresses. Crazy shit :)
OOP it's a tool for split code in small reusable parts. But the best part are templates. This feature permit you simplification of code. The best example is array class. In Java you have create a class for type. In C++ and Mql5 you can have it in one class reducing redundant code and bypassing some problems when you mix primitives and objects
PS: About ASM, it's old school. I used it when before first protect mode compilers and was funny overpass limitations. 64K segments with selectors was the nightmare of coders in that time. Every time you writed in wrong place you had been reboot computer :)