Experimental Physics and
Industrial Control System

Kay-Uwe Kasemir <[email protected]> · Thu, 29 Sep 2005 10:54:27 -0400

On Sep 28, 2005, at 11:03 , Jeff Hill wrote:

1) reflexive =>  x==x is always true
2) symetric  => if x==y then y==x
3) transitive => if x==y and y==z then x==z

I agree that this is the correct definition of equivalence.

It's somewhat slower to guarantee this, but perhaps necessary.

It may be that a fast, but incorrect == operator may not be very

useful.

Marty's right on the mathematical side.
On the practical side, when I write
    catA.equals(catB),
then I'm fairly certain that property catalog catA is compared to catB
by invoking catA's equal() method.

With operators I never know.
I can define a propertyCatalog/Container PC for doubles,
with a constructor that takes double,
a cast operator to double,
and now I can write
    catA == 3.14,
but don't know if the catA gets automatically cast to double
and compared as a number, or if the compiler generates a
temporary DoubleContainer instance from 3.14 and invokes its
comparison routine.
g++ 3.3 actually gives an error message:
error: ambiguous overload for `PC& == double' operator
error: candidates are: operator==(double, double) <built-in>
error:                 bool PC::operator==(const PC&)

In this case, I understand the message because I just created the mess
on purpose. But I had cases where I created those operators
for 'convenience', and a month later I worked on the code, got
a similar error message, and was very surprised what the compiler had
done to me to 'help' and now got confused.
Of course this probably only happens to me, because everybody else
understands C++ much better and should by all means use the operators,

but maybe we can still keep the methods in the API in case I have to

use it.

Thanks,
-Kay

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System