How to ensure comparison operator is "complete"?

[Asperamanca]

Let's say I have a class with n member variables. I want to provide a comparison operator for the whole class.

How can I ensure I do not forget about the operator== when adding members later on, or otherwise changing the class? Same goes for the copy constructor, BTW.

Usually, it's no big deal. But there's always a time when you change code in a hurry, and later on wonder why some other perfectly fine code doesn't do as expected. I'd like to have some kind of safety net.

Ideas?

[andre]

-Rely on the automatically generated ones?-

Edit:
If your classes derive from QObject, you could use Qt's property system to do your comparisons. If you expose all relevant properties via Q_PROPERTY, your implementation of the comparison operator could iterate over these properties and always work, even for subclasses. However, that has two downsides:

• It only move the responsibility of keeping the operators in sync to making sure all properties are Q_PROPERYs
• It would run slower than using direct comparisons.

I can't think of another way though.

Edit 2:
There are no default generated ones, thanks for correcting me.

[Asperamanca]

I often have non-trivial comparisons, like fuzzyCompare for qreal values.

[goetz]

How should any algorithm know whether a new attribute in your class is relevant for a comparison?

Even if the answer in your case would be "any one is relevant", that would be out of the scope of a compiler. One would have to analyze the source code and then to analyze the operator== method.

The method Andre did outline, works too. But it cannot handle the cases where your forgot to make the new attribute a property. So you're not gaining that much from that.

For our projects, I just would add a HUGE comment at the place where the attributes are added in the header:

@
/************************

• CAUTION!
• if you add an attribute here
• ADD IT TO THE comparison methods too!
  ************************/
  @

:-)

[Asperamanca]

I was afraid this would be the answer...

well, one could hope.

[goetz]

Yes, hope dies last :-)

[andre]

Perhaps you can find a static code analysis tool that can warn for these cases?

[Asperamanca]

Yes, I also thought this would be in the realm of static code analysis.
If anyone knows about a static code analysis tool that can provide that, please speak up.

[rwst]

Maybe this is a stupid question but do you need the operator==() for comparison?
(edit:I meant to say, do you need == within the comparison?)
It could be that it suffices for your application to compare the allocated memory
blocks using sizeof(Class1/2) and memcmp()? OK, this is C not C++...

[andre]

As the topic starter stated, he needs to do non-trival comparisons, like fuzzy comparisons of reals. That is never going to work with doing a memcmp. -Otherwise, relying on the default comparison operator would have been just as effective.-

Edit: there is no such thing as a default comparison operator in C++, thanks for correcting me.

[Asperamanca]

[quote author="Andre" date="1333107436"]Rely on the automatically generated ones?[/quote]

Took me a while to notice...since when do automatically generated comparison operators exist?

[andre]

[quote author="Asperamanca" date="1334563036"][quote author="Andre" date="1333107436"]Rely on the automatically generated ones?[/quote]

Took me a while to notice...since when do automatically generated comparison operators exist?

[/quote]

Sorry, you are right: they don't. I thought there were, but I was wrong on this count. I stand corrected.

StackOverflow has an interesting "discusson":http://stackoverflow.com/questions/217911/why-dont-c-compilers-define-operator-and-operator on the why (not) of automatic operator==() definition.

[Asperamanca]

I think it's the same one I stumbled upon. ;-)