Testing for equality

[Brian Tyler]

I have got into the following habit for overloading the == operator:

class A {
const bool operator==( const A& rhs ) {
return bool( this == &rhs ? true : /* some condition */ );
}
};

I.e. first I check if the variables are actually the same variable, if
not I implement some logic to test for equality of the underlying data
members.

Is this first test a total waste of time (since the number of times I
actually check a variable against itself is probably zero)... hmm, that
pretty much answers my own question, but your opinions would be
appreciated.

Thanks,
Brian.

 

[Victor Bazarov]

I have got into the following habit for overloading the == operator:

class A {
const bool operator==( const A& rhs ) {
return bool( this == &rhs ? true : /* some condition */ );
}
};

I.e. first I check if the variables are actually the same variable, if
not I implement some logic to test for equality of the underlying data
members.

Is this first test a total waste of time (since the number of times I
actually check a variable against itself is probably zero)... hmm,
that pretty much answers my own question, but your opinions would be
appreciated.

It's not a total waste of time if you anticipate people (even yourself)
doing something like

A a;
...
if (a == a)

or

A a;
...
A &b = a;
...
if (a == b)

*a lot* in your code. Even if you can estimate how many times this
might happen, you'd still be better off actually measuring instead of
guessing (or "estimating" for picky folk).

Essentially it comes to this: can some function somewhere in your code
_ever_ compare two objects (referred to by two references) that might
actually be the same object? If it can, and it happens once every ten
thousands of comparisons (often enough?), then you'll be speeding your
comparison up by not doing the actual comparison by about 0.01%. At
the same time, the rest of your comparisons will be slowed down by the
pointer comparison code you've added, and the rate depends on how long
the rest of the comparison takes. It has to be very expensive (more
significantly than comparing pointers) to justify this slowdown. Let
us say that comparing pointers takes 5 CPU ticks. The portion of the
operator == you called "some condition" should then be 50000 CPU ticks
long (or more) to justify wasting 5 ticks to compare pointers just to
save one ten-thousandth occurrance (see the assumption above). To me
it's a simple arithmetic combined with probability.

V

 

[Brian Tyler]

Even if you can estimate how many times this

might happen, you'd still be better off actually measuring instead of
guessing (or "estimating" for picky folk).
To me it's a simple arithmetic combined with probability.

V

Yes, you are completely right, there are going to be cases where this
check might pay off, but that totally depends how the objects are used.
In my case I don't see why the situation of a == b and &a == &b would
occur, so it is totally pointless.

I'm a mathematician and no one in my department is a programmer, so
sometimes I do something odd once (with some kind of justification) and
then I get into the habit because there is no one to challenge me. I've
been writing C++ (maybe that should be rewriting!) a lot for the past
year or so, but this is a very subtle and complex language. Thanks for
giving me a little perspective.

Brian.

 

[Bo Persson]

Yes, you are completely right, there are going to be cases where
this check might pay off, but that totally depends how the objects
are used. In my case I don't see why the situation of a == b and &a
== &b would occur, so it is totally pointless.

I'm a mathematician and no one in my department is a programmer, so
sometimes I do something odd once (with some kind of justification)
and then I get into the habit because there is no one to challenge
me. I've been writing C++ (maybe that should be rewriting!) a lot
for the past year or so, but this is a very subtle and complex
language. Thanks for giving me a little perspective.

This is typically a case where you would write the simplest possible
code at first, and only when you application runs really slow would go
back and add this optimization later, when you know it's needed.

Most often, it won't be!


Bo Persson

 

[Brian Tyler]

This is typically a case where you would write the simplest possible
code at first, and only when you application runs really slow would go
back and add this optimization later, when you know it's needed.

Most often, it won't be!


Bo Persson

Yes I have definitely been guilty of attempting early optimization,
leading to the exact opposite effect.