MQL5 The compiler does not distinguish between a class and a pointer to it - 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
There's no way to trigger it. It's pure memory leakage.
Make it so that it can be summoned.
By the way, gentlemen developers, we'd better fix this. After all, new does return a pointer, so add a check that at the other end = also a pointer, remove the implicit conversion (A) new A(); as I understand it - this is what happens.
By the way, dear developers, we'd better fix this. After all new really returns a pointer, so add a check that the other end = also a pointer, remove the implicit conversion (A) new A(); as I understood it - this is what happens.
There's a call for this operator
Forum on trading, automated trading systems & strategy testing
MQL5 Compiler does not distinguish between a class and a pointer
fxsaber, 2019.01.10 06:36
Since when are these defined (question for developers)
And how do they work? The following compiled code looks delusional
Roughly speaking, it looks like this
There goes the call to this operator
Roughly speaking, it looks like this
Before making a fuss, it would be good to know that in MQL all their life pointers have been implicitly cast to objects (dereferenced), it's convenient and everybody got used to it. Instead of hard-to-read a()->b()->c()->d() you can write in the usual OOP format: a().b().c().d(), and do less unnecessary transformations while passing to functions. And now because of someone's dissatisfaction you change everything?
Before you make a fuss about it, it would be nice to know that in MQL all their life pointers have been casted to objects implicitly (dereferenced), it's convenient and everyone got used to it. Instead of hard-to-read a()->b()->c()->d() you can write in the usual OOP format: a().b().c().d(), and do less unnecessary transformations while passing to functions. And now because of someone's dissatisfaction you change everything?
It's not about casting. You didn't get into it.
If we are guided by the declared prototype of MQL - C++.
In C++, the new operator returns a pointer, respectively, if m_A is an array of objects:
there would be a type error here.
This is the line the compiler would have skipped:
But it would cause a memory leak.
It would be nice if MQL had the same behavior.
Before you start making a fuss about it, you should know that in MQL all their lives pointers have been implicitly cast to objects (dereferenced), it's convenient and everyone got used to it. Instead of hard-to-read a()->b()->c()->d() you can write in the usual OOP format: a().b().c().d(), and less unnecessary transformations in the process of passing to functions. And now because of someone's dissatisfaction you change everything?
And if you go into detail with some simple examples.
As a result, we have
1. a' gets a copy of the created object, the pointer to the created new object is lost
2. What will happen to 'a' if new fails to create/memory allocate an object?
The second case (on the contrary)
1. After exiting the function, the 'b' object must be destroyed as a local object.
what will 'a' refer to then?
2. or will the copy operator still work and 'b' will be copied by the 'a' pointer ? and if 'a' hasn't been defined before ?
The second case (on the contrary)
Here it's vice versa - a pointer a is implicitly casted to an object (dereferenced) and then operator= is applied to it. fxsaber also mentioned it yesterday.
Although logically it does not contradict the MQL rules (since calling operator= is equivalent to calling any other object method), it leads to ambiguous understanding of such code and hard-to-find errors. And this concerns not only operator= but == and != as well, at least. Perhaps such casting should be prohibited for other operators as well, because in C++ you may apply to operators: +-<>[].
The short verdict is this: when applying operators which are allowed for pointers in C++ to a pointer, disallow an implicit casting of this pointer to an object. Correspondingly, the above example would cause a compilation error.