A question for OOP experts. - page 5
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
All lists are already equipped with a binary search. This does not mean going through the lists one by one, but rather filtering by the searched property. As a result, we get the index of the item we are looking for.
When a class object is created, apart from allocating memory for all properties (variables) of the class, one of the constructors is started (there may be more than one). The constructors can be non-parametric (default), parametric (when some parameters are specified when creating an instance of a class, or a copy constructor, when another instance of the class is specified as a parameter of an instance of the class.
I already solved this task publicly. The idea was to create a table of all symbols and all timeframes and to loop through it, fix the events of a new bar. After the first call of any function of this event, its flag is erased from the table. I can not judge how much more complicated it is than in OOP. But, in fact, rather simple and convenient solution.
as you wrote above, everything is relative.... using the last shot in the clip...
have you looked atthe standard library from MT's delivery? it's all OOP style, there are 2 options here either Metakvot programmers are professionals and use understandable styles or... Your version ;)
as you wrote above, everything is relative.... using the last shot in the clip...
have you looked atthe standard library from MT's delivery? it's all OOP style, there are 2 options here either Metakvot programmers are professionals and use understandable styles or... Your version ;)
I'm not well versed in OOP yet. They tell me about lists but I don't know what they are "eating" with. How they're announced, how they're accessed, how they're changed and so on... To me, a list is just a dynamic array without any additional syntax. An object is a set of properties in an array. And in OOP - Object is a whole class. Inheritance - linking of objects. Access to the object properties through the named references. So, everything in my case is much simpler and therefore I find it difficult to compare features and efficiency. I need to go deeper into it.
But one thing I have learned. You can't understand and use any one entity from the OOP concept without understanding the whole OOP and switching to it completely. It's either OOP or whatever you want. Just using one of its handy mechanisms probably won't work.
Simply using one of its handy mechanisms probably won't work.
The OOP can coexist with the procedural style without problems, but the functions must be completely separate and independent blocks of code, i.e. everything that the function uses must be in it or be passed as parameters to it
in general, as they write in Wiki, that OOP is an extension of the procedural style
But one thing I have understood. You cannot understand and use any one entity from the OOP concept without understanding the whole OOP and without going over to it completely
you can, I gave an example, and on the forum 90% of sources in OOP style are wrappers around procedural style - no inheritance, no abstractions, no ..... nothing, only encapsulation, but anyway it is at least convenient - it is convenient to have a completely transferable piece of code to another task - after all everything inside a class? ;)
with OOP procedural style without problems, but functions must be completely separate and independent blocks of code, i.e. everything that a function uses must be in it or be passed as parameters to it
in general, as they write in Wiki, OOP is an extension of the procedural style
you can, I gave an example, and on the forum 90% of OOP-style sources are wrappers around procedural style - no inheritance, no abstractions, no ..... nothing, only encapsulation, but still it is at least convenient - it is convenient to have a fully portable code block for another task - everything inside a class, right? ;)
Yes, code portability is a big plus of OOP. In my case only individual functions are portable (and only rarely), but when I build a big mechanism, nothing is portable. Just like human organs are not transferable (without professional intervention). My mechanisms are more like "organisms" in the sense that they are divided into large blocks, each performing a host of tasks. Therefore, portability is almost non-existent. However, these blocks are very easy to extend their functionality. You "add" it with just a few lines, and voila! - The blocks perform a whole layer of new work for which you have to write many separate functions. All in all, there are advantages. Well, the global scope is an incredibly powerful tool. The material the blocks work with is absolutely available to them and there's no need to transfer anything. Everything necessary for work is already there. All in all, the approaches are different and each has its own advantages.
I don't know a lot about OOP yet. They tell me about lists and I don't know what they are "eaten with". How they are declared, how they are accessed, how they are changed and so on... To me, a list is just a dynamic array without any additional syntax. An object is a set of properties in an array. And in OOP - Object is a whole class. Inheritance - linking of objects. Access to the object properties through the named references. So, everything in my case is much simpler and therefore I find it difficult to compare features and efficiency. I've got to delve deeper into it.
But one thing I've learned. You can't understand and use any one entity from the OOP concept without understanding the whole OOP and without going over to it completely. It's either OOP or whatever you want. Just using one of its handy mechanisms probably won't work.
Peter, you just have to try it. And I would recommend to try it exactly on list structures because there you can see all the advantages of OOP in all three directions - inheritance, encapsulation and polymorphism.
Due to inheritance, you have a single interface (a set of virtual functions) to work with objects inside a list. Objects can be simple or complex, inherited from the base.
By polymorphism - you can work with fundamentally different objects with this single interface.
Due to encapsulation - you have ONLY this interface, and have no access to any details of implementation - consequently, you cannot screw something up. Moreover, you know exactly, not only how those objects that are now work, but how the objects that aren't written yet will interact with your code.
Are these lists attached to anything within the OOP? I mean, what "load" do they carry with them? Classes, constructors, interfaces...? They are integrated into the class environment, aren't they?
Well, the global scope is an incredibly powerful tool. The material the blocks work with is absolutely available to them and there is no need to transfer anything. Everything you need to work is already there.
when it comes to the global scope of variables to be used as parameters of functions or code sections, then.... imho, this is the best way to get a completely non-transportable code with the possibility of getting hidden bugs that are impossible to detect later
SZZ: I modified such codes for MT4 EAs for many times, at first I renamed globally declared variables - then I made changes when I saw compiler errors, but last time I did it properly - I added new parameters to function signatures and then I removed globally declared variables, because if you managed to modify this wretched code once, you will have to do it all over again? - alas i'm lazy, but reasonably lazy )))))
when it comes to the global scope of variables to be used as parameters for functions or code sections, then.... imho, this is the best way to get a completely non-transportable code with the possibility of getting hidden bugs that are impossible to detect later
SZZ: I modified such codes for MT4 EAs for many times, at first I renamed globally declared variables - then I made changes when I saw compiler errors, but last time I did it properly - I added new parameters to function signatures and then I removed globally declared variables, because if you managed to modify this wretched code once, you will have to do it all over again? - alas i am lazy, but reasonably lazy )))))
The code is not portable, so that's what makes it special. It is not intended to be portable. It has another purpose. Well, the global scope of variables is a powerful tool for working with complex mechanisms. You just need to know how to use it. When people tell me about hidden errors and bugs, I get confused. I never had any bugs related to global variable visibility. In a word, not at all.