MQL5 The compiler does not distinguish between a class and a pointer to it - page 6
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
Implicitly casting this pointer to an object
The correct name is "Implicit pointer dereferencing".
I support the proposal to disallow, leave implicit dereferencing only when referring to a class member, like:
Here it's the opposite - a pointer 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 MQL rules (since calling operator= is equal to calling any other object method), it leads to ambiguity in understanding 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 conclusion is this: when applying operators which are allowed for pointers in C++ to a pointer, prohibit an implicit casting of this pointer to an object. Correspondingly, the above example would have a compilation error.
Yes, I see. By using these simple examples I wanted to show all the doubters that the pointer and the object are different entities and one mustn't mix them up.
And this circumstance requires at least a certain style of writing code so that you won't make a mistake and build code that will compile and even pass the test but fail in real conditions, even worse if it was written for sale. It will not be an easy task to find an error point in the code where everything is so "implicit".
Finding a place of error in code where everything is so 'implicitly' equal will be quite a challenge.
It would be better if the developers left things as they are. If they start changing it again now, the language, a bunch of programs stop compiling, or even worse, stop working as expected, there will be a world-wide uproar.
From my point of view, auto-objects in µl are a rudiment, under-pointers with limited functions (constant pointer with auto-delete), and they mostly do not need to be used at all (except for garbage collector).
It would be better if the developers left things as they are. If they start changing again now, the language, a bunch of programs stop compiling, or worse, stop working as expected, there will be a world-wide uproar.
The changes here are minimal. It's just a matter of adding compile rules to
so that it does not allow to compile the crap that is now considered good.
So that it won't let you compile the kind of heresy that's now considered good.
like A a = new A? Or what exactly ) is now used by everyone, so it has no effect at all
But if you write A a, *b = a; you get a runtime error, in this case the compiler must explicitly generate the warning "probable use of uninitialized variable 'b'" like it does with all the other types. If not a compilation error at all. But not because of the assignment per se but because of using an overloaded function on an uninitialized variable which causes a run-time error, of course. This is really a bug and it seems to be related to excessive code optimization.
And in general there's no heresy in assigning auto to dino and vice versa, these may be useful features.
But I would cancel such thing as implicit copying of objects altogether. Though it is a standard in C++. It's actually the reason for all these troubles.like A a = new A? Or what exactly )
Well, that goes without saying. There's a memory leak here.
But in general there is no heresy in assigning auto to dino and vice versa, these may be useful features.
Yes, let it be. But explicit. And it will be done not by my mistake, but because I have to.
Well, that's a given. There's a memory leak here.
Well, this leak is purely your fault. If you have an object on the left, why would you write such a construct?
But the reverse situation, when you assign something to a pointer and it is suddenly dereferenced, is an unobvious error.
Everything is mixed up here, both flies and cutlets. I'm talking about the discussion of the topic.
If you have an object on the left, why write such a construction?
The human factor! The compiler should keep it to a minimum.
The human factor! The compiler should keep it to a minimum.