Bitwise Object Comparison - Is it possible & safe?

[D. Susman]

Hi,

Is it possible to supply a generic == operator for a hierarchy of
classes? Like bitwise comparison. For example:

class Base
{

bool operator==( const Base& base )
{
// some bitwise
}
}

class Foo : public Base
{
// hundreds of fields here
}

Any ideas?

 

[Victor Bazarov]

Is it possible to supply a generic == operator for a hierarchy of
classes? Like bitwise comparison. For example:

class Base
{

bool operator==( const Base& base )
{
// some bitwise
}
}

class Foo : public Base
{
// hundreds of fields here
}

Any ideas?

If you have a virtual 'size' function (and make sure the 'Foo' and
every other derived class implements it), you could make your op==
virtual and use 'memcmp' on the bytes if the sizes are the same.
Whether it's a good idea is another topic.

V

 

[D. Susman]

If you have a virtual 'size' function (and make sure the 'Foo' and
every other derived class implements it), you could make your op==
virtual and use 'memcmp' on the bytes if the sizes are the same.
Whether it's a good idea is another topic.

V

Since this looks like hecking C code inside C++, this isn't quite
safe, eh?

 

[Victor Bazarov]

Since this looks like hecking C code inside C++, this isn't quite
safe, eh?

I believe you are using some strange definition of the word "safe".
There is nothing inherently *dangerous* about 'memcmp' or virtual
functions, provided you're not in the UB land.

It is possible that you're trying to save yourself some typing when
you are looking to delegate the equality comparison to the base class
like that. It is better to implement the operator== for each derived
class and let it compare the data itself.

Allowing 'memcmp' to do the work and hoping for the correct result is
rather /irresponsible/ of the implementor. You want to avoid having
to edit the class' op== function when adding another member, is that
it? What if you add a member of the type 'std::string'? Comparison
of strings is quite well-defined and it does not actually involve
comparing pointers in the bitwise manner. Same for any other
standard containers.

Once a month (maybe once a quarter) we see a question "how do I make
some function do some operation for all members of the class?" There
is no way currently in the language to do that. And I believe the
creators of the language did not want to add this because it only
makes sence in a very small number of cases.

Bite the bullet, make every derived class implement its operator ==
that does the correct thing when comparing two objects. Put the
appropriate semantics there. And document the necessity to revisit
the implementation of that function when adding new members. No
proper design/implementation/maintenance technique can be easily
substituted with some magical language trick.

V

 

[Jerry Coffin]

Hi,

Is it possible to supply a generic == operator for a hierarchy of
classes? Like bitwise comparison. For example:

Yes and no. The compiler will supply one that does member-wise
comparison, and provided your sub-objects all act like values, that's
probably sufficient by itself.

class Base
{

bool operator==( const Base& base )
{
// some bitwise
}
}

class Foo : public Base
{
// hundreds of fields here

What in the world are you doing with a class that contains hundreds of
members? I have a hard time believing a class should have _a_ hundred
members, not to mention hundred_s_ of members.

 

[Jeff Schwab]

(e-mail address removed) says... ....

What in the world are you doing with a class that contains hundreds of
members? I have a hard time believing a class should have _a_ hundred
members, not to mention hundred_s_ of members.

What he said.

 

[Eberhard Schefold]

Yes and no. The compiler will supply one that does member-wise
comparison,

The compiler provides a default comparison operator for a class? Where
can I find that in the standard?

 

[Victor Bazarov]

Yes and no. The compiler will supply one that does member-wise
comparison, and provided your sub-objects all act like values, that's
probably sufficient by itself.

WHAT??? The compiler will do *what*?

What in the world are you doing with a class that contains hundreds of
members? I have a hard time believing a class should have _a_ hundred
members, not to mention hundred_s_ of members.

V

 

[Erik Wikström]

The compiler provides a default comparison operator for a class? Where
can I find that in the standard?

You can't, and Jerry knows that too, he just confused the assignment
operator with the comparison operator.

 

[peter koch]

What he said.

"What he said"? The OP said absolutely nothing about why he had a
class with houndreds of members.

/Peter

 

[peter koch]

Hi,

Is it possible to supply a generic == operator for a hierarchy of
classes? Like bitwise comparison. For example:

class Base
{

   bool operator==( const Base& base )
   {
       // some bitwise
   }

}

class Foo : public Base
{
    // hundreds of fields here

}

Any ideas?

No you can not. That is - you can, but it will not work reliably. So
you might risk your operator == returns false when the objects are
identical.

/Peter

 

[Kai-Uwe Bux]

"What he said"? The OP said absolutely nothing about why he had a
class with houndreds of members.

The question Jerry responded to is not "why he had a class with hundreds of
members" but "What in the world are you doing with a class that contains
hundreds of members". And the OP partially answered that: he is going to
compare them for being equal.


Best

Kai-Uwe Bux

 

[Jeff Schwab]

"What he said"? The OP said absolutely nothing about why he had a
class with houndreds of members.

"He" being Jerry, not the OP. I meant to agree with Jerry. Apologies
for not providing an antecedent.

A class with 100s of members may just possibly be justifiable, but more
than likely it's a sign that refactoring is in order.

 

[peter koch]

The question Jerry responded to is not "why he had a class with hundreds of
members" but "What in the world are you doing with a class that contains
hundreds of members". And the OP partially answered that: he is going to
compare them for being equal.

Best

Kai-Uwe Bux- Skjul tekst i anførselstegn

Okay - my fault. English is not my native language, and I took Jerrys
question as asking why the class had houndreds of members - just as in
"What are you doing out in the cold" is another way of asking why you
do not come in. Actually thinking again, I still believe this is the
one interpretation that gives meaning as long as you believe Jerry to
be a person of normal intelligence (or better!).

/Peter

 

[peter koch]

"He" being Jerry, not the OP.  I meant to agree with Jerry.  Apologies
for not providing an antecedent.

A class with 100s of members may just possibly be justifiable, but more
than likely it's a sign that refactoring is in order.

Yes - it is more than likely ;-)

/Peter

 

[Jerry Coffin]

[ ... ]

WHAT??? The compiler will do *what*?

Oops -- of course, you're right that it won't. My apologies. Next time
I'll try to remember to quit posting _before_ I go to sleep...

 

[Eberhard Schefold]

You can't, and Jerry knows that too, he just confused the assignment
operator with the comparison operator.

I see. Come to think of it (and at the risk of asking an FAQ, but I
couldn't find it), why is there a compiler generated copy constructor
and assignment operator, but no equality operator? It seems to me that
these methods are equally as useful (or potentially unwanted), so
there's a bit of an asymmetry here. Or am I missing a point?

 

[James Kanze]

Okay - my fault. English is not my native language, and I took
Jerrys question as asking why the class had houndreds of
members - just as in "What are you doing out in the cold" is
another way of asking why you do not come in. Actually
thinking again, I still believe this is the one interpretation
that gives meaning as long as you believe Jerry to be a person
of normal intelligence (or better!).

That's the way I would interpret it too. In this case, it's
more or less a retorical question: a means of saying that you
shouldn't have a class with hundred's of members.

 

[Pete Becker]

I see. Come to think of it (and at the risk of asking an FAQ, but I
couldn't find it), why is there a compiler generated copy constructor
and assignment operator, but no equality operator?

Because that's the way things work in C.

 

[Jerry Coffin]

I see. Come to think of it (and at the risk of asking an FAQ, but I
couldn't find it), why is there a compiler generated copy constructor
and assignment operator, but no equality operator? It seems to me that
these methods are equally as useful (or potentially unwanted), so
there's a bit of an asymmetry here. Or am I missing a point?

In this case, C++ is just doing what C did: when you create a struct, it
automatically supports assignment but not comparison. If you want to
support comparison, you have to write your own code to do it. At a
guess, that's done because in many cases you wouldn't want to compare
all the fields in a struct anyway -- you'd consider a few "key" fields,
and the rest would be ignored in a comparison.