Errors, bugs, questions - page 1357

New comment
 
By the way, I don't understand this code, where will operator== be called? It just compares two longs, that's all
 
Alexey Navoykov:
By the way, I don't understand this code, in what place will operator== be called? It's just a comparison of two longs, that's all
class A { public:
        bool operator==( const A& ) { Print(__FUNCTION__); return true; }
};
class B {};
void OnStart()
{
        bool res;
        A *a1, *a2;
        B *b1, *b2;
        res = a1 == a2; //сейчас сравниваются указатели
                        //предлагается вызывать operator==()
        res = b1 == b2; //сравниваются указатели (предложение здесь ничего не меняет, поскольку нет B::operator==)
        res = IsEqualPointer( a1, a2 ); //сравниваются указатели
}
IsEqualPointer can be either a template or a general function similar to ::GetPointer
 
A100:

...

IsEqualPointer can be either a pattern or a general function similar to ::GetPointer

I don't understand you at all, could you explain in human language what you are trying to do? The given code has errors (operator== has neither argument, nor return value), it's hard to understand something from all this.

Let me tell you right away that the problem of comparing/assigning pointers has never existed before, GetPointer(a)==GetPointer(b) is sufficient for that. So the task concerns only comparison/assignment of objects themselves, i.e. it is guaranteed to perform those operations regardless of whether these objects are represented by pointers or references

 
Alexey Navoykov:

The code you've given has errors (operator== has no argument or return value), it's hard to understand anything from all this.

Corrected. It is suggested to call operator==(...) for pointers as well, if it is defined, then GetPointer(a)==GetPointer(b) will cause a.operator==( b ) to be called, so to compare pointers for equality it is suggested to use IsEqualPointer
 
A100:
GetPointer(a)==GetPointer(b) will cause a.operator==( b )
Why would it do that?
 
Alexey Navoykov:

By the way, how about introducing * and & operators in MQL to allow explicit access to an object in the first case, and taking an object pointer in the second (instead of cumbersome GetPointer). The asterisk is a must, and it cannot be replaced by anything in the language.Without it, it is impossible to control situations like the one described by A100 above, when instead of the objects themselves some pointer actions are performed. Personally, this is a constant problem, I have to be constantly on the alert or specify A.operator=(B), A.operator!=(B) everywhere, i.e. brevity is lost, and overloading operators actually becomes meaningless.

I raised this problem once before, but the topic got stalled. Let's finish this issue at last.

Thanks for the message, if you mean the following usage:
CFoo   f1,f2;
CFoo *pf1=&f1;
CFoo *pf2=&f2;

*pf1!=*pf2
*pf1=*pf2;

I agree with that, I will certainly raise the issue and we will discuss it.
 
Alexey Navoykov:
Why would that be?
class A { public:
        bool operator ==( const A& ) { Print( __FUNCSIG__ ); return true; }
        bool operator  <( const A& ) { Print( __FUNCSIG__ ); return true; }
};
void OnStart()
{
        bool res;
        A a1, a2;
        res = GetPointer( a1 ) == GetPointer( a2 ); //сейчас сравниваются указатели, а будет вызываться operator==, как сейчас происходит для следующей строки
        res = GetPointer( a1 )  < GetPointer( a2 ); //вызывается operator<
}
If you equate operator== with operator<, the result is the same
 
A100:
...
If you equate operator== with operator<, the result will be the same too.

You didn't even check what you suggest! Just like in the previous case, when there were obvious errors in the code, i.e. you didn't even try to compile it. You sketched something on a crank, some thoughts of yours, like "eat it while I am kind, no pity"... Is that right? Let's not do this kind of nonsense.

I myself constantly compare pointers and overload operators, and it never happened what you are dreaming about now. And now having checked your code, no miracles happened, operator== is not executed as it should be.

 
Alexey Navoykov:

So now having checked your code, no miracles have happened, the operator== does not start as it should.

The essence of the proposal is precisely that it should run. I'm talking about changes to the existing system.
 
A100:
The point of the sentence is precisely that it should be triggered.

What's that for? It's upside down.

It makes more sense the other way around: < and > should cause comparison of pointers.

1...135013511352135313541355135613571358135913601361136213631364...3191
New comment