Overhead for the PLO - 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
Of course, the beautiful OOP must be paid for with resources and a lot of debugging time. OOP only makes sense as a handy text wrapper or with minimal use in run-time initialization... Actually, OOP was just a marketing thing from Microsoft to increase the costs of programmers' working hours and to stimulate the purchase of more advanced equipment. And they are not fools themselves and write all the software in C and assembler.
what a load of crap.
everyone knows that MS programmers write directly in machine code
every programmer has a book with processor machine codes on his/her desk and they just burn the codes on punched cards
Bill Gates can compile an operating system in his head.)
What a load of crap.
Everyone knows that MS programmers write directly in machine code
Your clownery is not quite clear, it's known that assembly language inserts are used to improve code performance...
I can suppose that OOP is used in terminal to a minimum or not at all because it's hard to get such compact files without large external libraries as in dotnet...
Do you have any meaningful arguments on the essence of what was said?
Check. Alexei is indeed just reacting emotionally. And in essence, the objections are as follows.
OOP is very useful when you need to support some complex code.
Certainly, it makes no sense to apply all OOP tricks to an indicator-MA. Though when basic classes are written - even for MA - still OOP-approach is at least as good as a usual, procedural approach.
The main advantage of OOP is revealed with the support of developed object structures. When the encapsulation ensures the absence of the necessity to understand all the nuances of the overloaded functions every time. When it is based on polymorphism, thecode reuse becomes much higher.
The essence of OOP is closer to the real world where any object is always related to its properties and has certain rules of interaction with the environment.
About the "increased cost of working hours" - it is not so. Certainly, when designing a system in the OOP-style it requires a bit more work than in the procedural-oriented approach. However, these extra costs are more than compensated by the convenience of maintaining and modifying the written code.
Personally, I write very small "Knee-Written" indicators without any objects. However, when something more (at least cross-platform) is required - I always use OOP-style and existing practices in objects libraries.
Your clownery is not quite clear, we know that assembly language inserts are used to improve code performance...
I can assume that the terminal uses minimal or no OOP, because without huge external libraries like in dotnet it's hard to get such compact files...
1. OOP - it helps a lot when you need to support some kind of complex code.
2. of course, there is no sense to apply all OOP tricks for indicator-MA. Although, when basic classes are written - even for MA - still OOP-approach is at least as good as a usual, procedural approach.
3. The main advantage of OOP is revealed with the support of developed object structures.
1. e.g.? Catchy slogans are good, but it is not clear what exactly they mean...
2. It has already been said that as a text wrapper OOP is good, but that's because it hasn't been brought up to speed in procedural programming.
3. Why do we need to multiply these "developed structures"? It will be destructive for the code's performance and it is not sure that it will be easier and faster to catch bugs in it.
Modern compilers optimize many times better than an average or even good programmer.
Maybe some simple and trivial things can, but only because people sat down and manually wrote the algorithm, but if something non-standard, it is far from certain, especially if OOPesheh features are found there.
In drivers, yes, they use assebler, but not because of the speed, it's just easier to work with the hardware..,
Well, people are not stupid - why would they want something complicated and confusing that is also slow?
And for example? Catchy slogans are nice, but it's hard to understand what exactly we are talking about... 3.
2. It has already been said that as a text wrapper OOP is good, but that's because it hasn't been brought up to speed in procedural programming.
3) Why should we multiply these "developed structures"? It would be terrible for the code performance and it's not the fact that it will be easier and faster to catch bugs in it.
1. For example, you need an array of objects. This could well be done procedurally or based on CArrayObj and CObjest. The problems will start when you need to change the behaviour of, say, adding or deleting objects or sorting them. In OOP, support for a pointer array proper and working with it is enclosed in the base objects. Modifying descendant objects that are actually contained in the array does not affect anything. In procedural style - modifying real objects that are actually contained in an array - usually affects a lot more places, at least because we have to consider changes in the size of objects. Which will more easily lead to errors.
Cross-platform - also much more convenient to organize in OOP-style. When on the request, say, a trade position - we get an interface, and it does not matter what platform we work on - the interface offers virtual functions, on which we can get all of the data on all orders (for MT4) or positions (MT5), and, from the expert point of view - there is no difference. The Expert Advisor does not need to know what platform it works on.
2. Well, "finishing in procedural programming" means "writing objects-procedures", i.e. creation of some links between data and procedures, which represent objects in OOP.
3. And then we have, say, a number of kinds of orders, which have a lot in common. It would be reasonable to make an object COrderInfo - which would be the base object, and its descendants would represent different kinds of orders. In this case, the trade processor (I have the CTradeProcessor class) will automatically support exactly that order, which has been passed to it, by those procedures that are needed to process this order.
It's easier to catch bugs where there are fewer cross-links. Which is exactly provided by encapsulation and polymorphism. We request the trade position interface (CTradePositionI) and all connections with real classes that represent this position (CMT4PositionInfo,CMT5PositionInfo) are performed only through this interface, and this precisely contributes to easier error correction than if we work directly with real functions that return trade position data.