Did Structs Change with the last MT5 Update? - page 3

 

This shows the whole magic and how to avoid the most common errors when compiling.


struct CPoint
   {
   public:
   int               x;                   // horizontal coordinate
   int               y;                   // vertical coordinate

   bool operator == (CPoint &point) { return (x==point.x && y==point.y); }
   bool operator != (CPoint &point) { return (x!=point.x || y!=point.y); }
   void operator =  (CPoint &point) { x=point.x; y=point.y; }
   
   void CPoint() {}
   void CPoint(int vx, int vy)   { x=vx; y=vy; }
   void CPoint(CPoint &p)        { this=p; }
   
   };

After this, code like 

CPoint a, b;
a=b;

still works. 

In case you inherit from another struct, you have to implement the operators and constructors again. Otherwise you will get complaints. 

 

When I see the interest in topics like these, its clear again what the level of the most MQL coders is. 

And I cant avoid the question: What are such changes good for.

There are so many other things which really should be improved in MQL. This - not. It also worked before without any drama. 

 
Doerk Hilger #:

When I see the interest in topics like these, its clear again what the level of the most MQL coders is. 

And I cant avoid the question: What are such changes good for.

There are so many other things which really should be improved in MQL. This - not. It also worked before without any drama. 

Arrogance is a bad thing. 😉

This change is in preparation to the transition to the new compiler which will probably include a lot of things you will like to see. And most probably some missing features which we would like (for example there will not be multiple inheritance even in a simplified way), we will see.

 

Someone should also mention, that its kinda suicidal to overload the assignment operator = with structs, while have a copy-constructor with 'this' the same time. 

This:

... will end up in a stack overflow. Funnywise not always. In my case after a week the first time. Code unchanged in the meanwhile. 

 
Alain Verleyen #:

Arrogance is a bad thing. 😉

This change is in preparation to the transition to the new compiler which will probably include a lot of things you will like to see. And most probably some missing features which we would like (for example there will not be multiple inheritance even in a simplified way), we will see.

Its a fact and has zero to do with arrogance. If you wanna understand it that way, go for it. 

But you see yourself, that just a hand full of developers, and kinda always the same group, responds. 

 
Doerk Hilger #:

Its a fact and has zero to do with arrogance. If you wanna understand it that way, go for it. 

But you see yourself, that just a hand full of developers, and kinda always the same group, responds. 

It's an interpretation of a fact, that doesn't mean anything about the "level of the most MQL coders". Maybe professional coders have no interest about this forum, or to participate to this topic ? 

Anyway I answered your question about why "such changes are good for".

 
Doerk Hilger #:

Someone should also mention, that its kinda suicidal to overload the assignment operator = with structs, while have a copy-constructor with 'this' the same time. 

This:

... will end up in a stack overflow. Funnywise not always. In my case after a week the first time. Code unchanged in the meanwhile. 

In my opinion, assigning to this is a bad (MQL) practice.
 
Alain Verleyen #:

It's an interpretation of a fact, that doesn't mean anything about the "level of the most MQL coders". Maybe professional coders have no interest about this forum, or to participate to this topic ? 

Anyway I answered your question about why "such changes are good for".

Ok, and where are they, if not here? Every time I try to find an answer, I do find your stuff and Fernandos (also mine) via Google and end up here. Stackoverflow? Not really. And ChatGPT is also not that skilled with MQL. I have to tell it all the time "No, doesnt work man" :D 
 
Alain Verleyen #:
In my opinion, assigning to this is a bad (MQL) practice.
Its the nature of a struct that you have sequential data, managed via the stack at once. Thats exactly the advantage vs. classes. And doing it with this= is the fastest and most natural way. The data is copied via rep movsd(x) (assembler) at once. Single assignments, var by var, takes the same time for each var. If you have a struct with 50 fields, you need 50 times the time. 
 
Doerk Hilger #:
Ok, and where are they, if not here?

I know for sure several very good coders who don't participate here or very rarely. By the way, you are not participating much either.

Why does it matters ?