Will OOP be in demand in MQL5? - page 6

 

If you want, you can find OOP in BASIC, which is an interpreter, too.


I think we need to wait and see how much OOP will be in demand in indicators, Expert Advisors and scripts. And on the fact to decide how it really is.

 

HideYourRichess писал(а) >>

I think we should wait and see how much OOP will be in demand in indicators, EAs and scripts. And then decide how it actually works.

At the moment I'm trying to automate the copying of data buffers with all of them in indicators. It's a hard process, I always face such problems like absence of references, constructors with parameters (RAII is unrealizable), etc.

And I'm not satisfied with a similar thing that comes with it. Not at all.

C-4 wrote >>

Z.U. Most people associate OOP with a particular programming language C++

Why, is it badly implemented? Imho, quite well implemented. As in any other normal object-oriented language.

, MQ5 is an OOP,

But it's poor in features.

OOP exists even in C, yet for some reason many don't know about it, which again speaks of superficial knowledge.

Please explain a bit more about this point.

 
TheXpert >> :

Now I'm trying to automate the copying of buffer data with all the accompanying in the indicators. It's going hard, it's complicated, I'm constantly bumping into walls like lack of references, constructors with parameters (RAII is unrealizable), etc.

And I'm not satisfied with a similar thing that comes with it. Not at all.

To tell you the truth, I tried that too. It was nothing special, just a dabble. I gave it up, I didn't get anything good out of it. Either I need to retrain a lot, or the OOP needs to be expanded. Neither of them are expected yet. In general, I went over the rake, and did not understand whether I was such a fool or whether I should send tickets to technical support, - I gave up on it all for the time being.

 

Please, I can elaborate:

INCAPSULATION:

struct mail

{

int zipcode;

char adr[50];

char comment[10];

...

}

The mere presence of structures is an unprotected encapsulation.

STATIC POLYMORPHISM:

double d=3.12, c;

int i=5;

c=d+i;

(Different data types are summed together by the same operator)

DYNAMIC POLYMORPHISM:

void qsort(void *buf, size_t st, size_t s,int (*compare) (const void *, const void *));

The qsort function will behave differently, depending on the type of comparison subfunction

INCLAPSULATION:

Same example as in dynamic polymorphism, in this case the qsort function sort of takes on the properties of compare()

 
C-4 >> :

Please, I can elaborate:

Something like this is what I was expecting to see. Only static polymorphism is counted. I see no sense in continuing the discussion on this subject (OOP in C) and will not.

I thought you'd really surprise me.

 
If you want to see something like classic overloading of functions etc., download some modern C compiler, for example LCC, and look it up. The LCC, for example, supports classical OOP, although this is outside the standard.
 

To sum up some very preliminary results, we can say that OOP in the implementation of meta-quotes is not accepted even by experienced programmers. Perhaps it is because of the implementation. Perhaps one will have to get used to it and the OOP will really become more convenient. But so far we have what we have. It seems to be more convenient without it. I.e. you can probably write it, but only for OOP, not for usability, speed of writing, not to mention the performance of the code itself, which anyway will be slower against PP.

Such is the case...

 

Is the need for OOP really that important (no matter who understands under this abbreviation)? For me it's more important what new trading and service functions will appear that will facilitate the trader's and programmer's work, and how well/completely they will be implemented.

If you show me at least ten certificates of compliance of MQL5 with OOP standards, but without the creation of objects by indicators no OOP will save you from the intricacies of displaying simple text on the screen. What good is a proud use of OOP, if you can't even use a common wrist wheel in this chart object? A button that works as a checkbox, and the lack of a standard combo box, so that, for example in an Expert Advisor you could just select the timeframe for calculations, and the ability to group several objects into one. I am not even speaking about the editor of dialog forms, because the platform is developed for auto-trading... :(

IMHO: In MQL5 there is only (heavily) truncated version of possibilities inherent in classic OOP. The developers have done a great job and it surely simplifies writing a source code, but it's all in vain, and I still want a taxi, and I hope that developers won't start working on MQL6 soon, but will fruitfully work long to "finalize" MQL5 ;)

 
ForexTools >> :

But is the demand for OOP so important (no matter who understands this acronym)? For me it is much more important what new trading and service functions will appear that will facilitate the work of the trader and the programmer, and how well/completely they will be implemented.

Yes, of course. And a lot has been said about this in the corresponding threads. It seems to me, for example, that MC, instead of solving old problems, has only made their solution more complicated by innovations.

I'm not talking about OOP right now. But the energy spent on this feature could very well have been spent on something actually useful and in demand.

 
Svinozavr >> :

Yes, of course. And a lot has been said about it in the relevant threads. It seems to me, for example, that the MC, instead of sorting out the old problems, has only complicated their solution with innovations.

I do not mean the PLO now. But the energy spent on this opportunity, it would be quite possible to spend on something really useful and in demand.

It's not a simple question, really. In fact. We don't see any redesigns in the server. According to sketchy information on the Internet it is cooler than it was. It's all certainly not for us, for the docs, but on the other hand the service may improve, in general.