Will OOP be in demand in MQL5? - page 3
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
At least the learning of MQL4 will not be a waste of time. If you've used only standard indicators, the conversion, as I understand, will not be very difficult.
I think the average semi-professional programmer won't need OOP in MQL5.
If I've got a good impression the speed will be higher in all aspects, I'd rather not look at such indicators that may solve big problems. I repeat - I am not a professional.
Although, maybe now enthusiasts will use MQL5 to simulate the emergence of life from the primary broth? ;)
P/S Forgot. Event handling functions. Gud.
... library returns an interface (a class with virtual functions). In the case of "uncoordinated" usage with me, it returns a stub interface (with not very obvious computation flaws).
Can you do it without swearing? Women sometimes come to the forum here.
There will be a protection benefit - the EX5 library returns an interface (a class with virtual functions). In case of "uncoordinated" use with me it returns interface stub (with not very obvious calculation errors).
If it is worth it, they will crack it, and the interface with clean humanoids will not help :)
Therefore, protection is the same as elsewhere - no physical access to the code, plus a delay required for specific TS with trade review (equity investor may be given real time).
Well, OOP in EAs is a very valuable thing, starting from events, possibility of competent support and fine-tuning, etc. Of course, I don't understand why C# wasn't a good idea, because the absence of MQL5 framework with clear namespace declarations, as well as non-standard + immature language, will require more efforts than initially reasonable from everyone :(
They no longer have OOP at their core (although absolute OOP is practically unusable). We should have created abstract classes from the beginning and used inheritance and polymorphism to reach real objects. For example, to create an abstract base class for custom indicators with abstract methods and properties. It is better to build a hierarchical tree of classes: a tree for graphical objects, for working with the account, for schedules and access to time-series, etc. And the predefined procedures and functions should be left only with the elementary routines that require speed. Then the capabilities of the platform could be extended from any level of abstraction, which would reduce the code size, improve its readability and ease of understanding for other programmers. And in MT5 already implemented quite complex things at procedure level (in fact the whole platform is ready to use) and I haven't seen the possibility of access by pointers at least to descriptors of created internal structures, which is very limiting (judging by the help). In general, the need for OOP is questionable, with such an implementation we could be limited to structures and dynamic placement. OOP should be supported from below by a well-developed hierarchy of classes.
Yeah. That's what I'm saying. The way it's done, IMHO, is unlikely to be very useful. That's what this is for. But, still, maybe there are other opinions?
Whistles'n'Bells, definitely. However, if there is any support for external objects, that's great.
Without namespaces, it's not really feasible.
Without namespaces, it's not really feasible to provide proper support.
One can do without this latest fancy stuff from Microsoft. But you can't do without this latest fancy stuff like ' interface libraries ' at least while we talk about winnda. Actually it's a pity that MT developers seem to have sworn an undying fealty to the melkomsoft until the grave and not pay any attention to the rest. My gut tells me that making even completely sinless MT5 work under Linux via Wine will be a real pain in the ass.