Errors, bugs, questions - page 2521
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
fxsaber:
Подскажите, как в C++ с этим? Задумался, использовать эту фишку в своем коде или нет. Если в C++ работает, буду использовать. Нет - вряд ли, т.к. могут отменить в следующих билдах.
b = a; a = b; // OKThe first assignment only works in MQL. And it's too bad that it works. I wish they would finally abolish this misunderstanding. There are no problems with the second one.
The first assignment works only in MQL. I wish they would finally cancel this misunderstanding. I have no problems with the second one.
That's odd. I thought that the first one must work and the second one does not.
That's odd. I thought that the first one must work and the second one does not.
Well, apparently, the MQL-developers do not quite understand the essence of assignment, either. For I have been telling them about this problem for a long time, but it hits a wall.
The essence of the assignment is that the object is assigned an equivalent object. It means that the right object is first casted to the left object's type implicitly and only then the assignment (copying) takes place. And in the first case such casting (A->B) is certainly impossible.In C++ there will be an error, but in MQL instead the left object is casted to the right one and A::operator=(A&) is executed, replacing only part of the b object. Is this an assignment?
Imagine that you are assigning int to long, but only the first four bytes are being replaced and the rest is left untouched. It's the same here.
Imagine you assign an int to a long, but only the first four bytes are replaced, and the rest is left untouched. It's the same here.
So it's convenient, I guess. In the context of structures, of course.
So it's convenient, it seems. In the context of structures, of course.
It may save characters in a string, but it is a source of random errors and complicates/distorts understanding of the code. As was said above, the equal sign has a clear and unambiguous meaning that theentire object is changed. That's why the operator is not used as intended in this case. If you want such non-standard behavior, you should overload the operator for such purposes.
p.s. The only exception is if class B has no fields of its own, i.e. it's exactly the same as class A (fully equivalent to it), then there's no reason to prevent this assignment, although it doesn't work in C++ anyway, but in MQL you can allow it.
In the opt-file, in the chunk where all input parameters are prescribed, the value for optimised parameters (defined via size and offset fields) does not contain Value (as without optimisation), but Start.
It would be logical to have Value there.
Well, it seems that MQL developers do not quite understand the essence of assignment either. For I have been telling them about this problem for a long time, but it hits a wall.
The essence of the assignment is that the object is assigned an equivalent object. In other words, of the same type.
The essence of operations for user types is not defined beforehand. And only their order is defined, which in this case consists in calling the appropriate operator=.
In MQL, unlike in C++ operator= is inherited, so b = a; is equivalent to calling A::operator=(const A&);
In general, there is no contradiction here. In the special case of assigning an equivalent object, there is some inconsistency of entities, but no more than that
In MQL unlike C++ operator= is inherited, so b = a; is equivalent to calling b.operator=(const A&);
Well, yes, that's the problem. But the writing difference doesn't play a role here. In C++ it won't compile in both cases.
In general, there is no contradiction here. In the special case of assignment of an equivalent object, there is some inconsistency of entities
There will be a contradiction with C++ at least. If it compiles, it means that the right operand is implicitly cast to the left one and then a complete substitution of the object takes place, as it should logically work. I gave an example with int->long. And substitution of part of an object's interior is not an assignment. So there is both contradiction and inconsistency.
p.s. Although the B::operator=(A&) operator can also be overloaded, but I suppose a sensible programmer would replace the B object there completely instead of partially, for this is the essence of assignment.
If one wants concise spelling, one could make some other operator for it: &= or |= for example. At least they are not commonly used, so there is no confusion.
..........
A contradiction would be at least with C++. ......
..........
What makes you think that MQL must be fully equivalent to C++ ???
C-like does not mean equivalent!
MQL is developed for definite tasks and is not obliged to copy completely the language on the basis of which it was created.
Will you stop being indignant?
But in Pascal you can .........
In Assembler you can go to .....
And in Java ....
And in BASIC ....
Do you practice comparing languages here?
=======
P.S. It's not just you...
What makes you think that MQL should be fully compliant with C++ ???
...
Do you practice comparing languages here?
I was responding to a specific phrase. Calm down. Take some valerian and go to bed. It's not good for you to worry. ...Some people get hot at the word "C++".