Bitwise Object Comparison - Is it possible & safe?

Discussion in 'C++' started by D. Susman, Mar 18, 2008.

  1. D. Susman

    D. Susman Guest

    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?
     
    D. Susman, Mar 18, 2008
    #1
    1. Advertising

  2. D. Susman wrote:
    > 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
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Mar 18, 2008
    #2
    1. Advertising

  3. D. Susman

    D. Susman Guest

    On Mar 18, 3:49 pm, "Victor Bazarov" <> wrote:
    > D. Susman wrote:
    > > 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
    > --
    > Please remove capital 'A's when replying by e-mail
    > I do not respond to top-posted replies, please don't ask



    Since this looks like hecking C code inside C++, this isn't quite
    safe, eh?
     
    D. Susman, Mar 18, 2008
    #3
  4. D. Susman wrote:
    > On Mar 18, 3:49 pm, "Victor Bazarov" <> wrote:
    >> D. Susman wrote:
    >>> 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
    >> --
    >> Please remove capital 'A's when replying by e-mail
    >> I do not respond to top-posted replies, please don't ask

    >
    >
    > 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
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Mar 18, 2008
    #4
  5. D. Susman

    Jerry Coffin Guest

    In article <8a103019-9cd5-4cbf-b8bb-e7449fa5c6a1
    @u10g2000prn.googlegroups.com>, says...
    >
    > 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.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, Mar 18, 2008
    #5
  6. D. Susman

    Jeff Schwab Guest

    Jerry Coffin wrote:
    > says...

    ....
    >> 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.


    What he said.
     
    Jeff Schwab, Mar 18, 2008
    #6
  7. Jerry Coffin wrote:

    >> 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,


    The compiler provides a default comparison operator for a class? Where
    can I find that in the standard?
     
    Eberhard Schefold, Mar 18, 2008
    #7
  8. Jerry Coffin wrote:
    > In article <8a103019-9cd5-4cbf-b8bb-e7449fa5c6a1
    > @u10g2000prn.googlegroups.com>, says...
    >>
    >> 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.


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

    >
    >> 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.


    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Mar 18, 2008
    #8
  9. On 2008-03-18 17:41, Eberhard Schefold wrote:
    > Jerry Coffin wrote:
    >
    >>> 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,

    >
    > 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.

    --
    Erik Wikström
     
    Erik Wikström, Mar 18, 2008
    #9
  10. D. Susman

    peter koch Guest

    On 18 Mar., 17:30, Jeff Schwab <> wrote:
    > Jerry Coffin wrote:
    > > says...

    > ...
    > >> 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.

    >
    > What he said.


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

    /Peter
     
    peter koch, Mar 18, 2008
    #10
  11. D. Susman

    peter koch Guest

    On 18 Mar., 14:46, "D. Susman" <> wrote:
    > 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
     
    peter koch, Mar 18, 2008
    #11
  12. D. Susman

    Kai-Uwe Bux Guest

    peter koch wrote:

    > On 18 Mar., 17:30, Jeff Schwab <> wrote:
    >> Jerry Coffin wrote:
    >> > says...

    >> ...
    >> >> 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.

    >>
    >> What he said.

    >
    > "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
     
    Kai-Uwe Bux, Mar 18, 2008
    #12
  13. D. Susman

    Jeff Schwab Guest

    peter koch wrote:
    > On 18 Mar., 17:30, Jeff Schwab <> wrote:
    >> Jerry Coffin wrote:
    >>> says...

    >> ...
    >>>> 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.

    >> What he said.

    >
    > "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.
     
    Jeff Schwab, Mar 18, 2008
    #13
  14. D. Susman

    peter koch Guest

    On 18 Mar., 20:38, Kai-Uwe Bux <> wrote:
    > peter koch wrote:
    > > On 18 Mar., 17:30, Jeff Schwab <> wrote:
    > >> Jerry Coffin wrote:
    > >> > says...
    > >> ...
    > >> >> 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.

    >
    > >> What he said.

    >
    > > "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- 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, Mar 18, 2008
    #14
  15. D. Susman

    peter koch Guest

    On 18 Mar., 21:15, Jeff Schwab <> wrote:
    > peter koch wrote:
    > > On 18 Mar., 17:30, Jeff Schwab <> wrote:
    > >> Jerry Coffin wrote:
    > >>> says...
    > >> ...
    > >>>> 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.
    > >> What he said.

    >
    > > "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.


    Yes - it is more than likely ;-)

    /Peter
     
    peter koch, Mar 18, 2008
    #15
  16. D. Susman

    Jerry Coffin Guest

    In article <frp0jn$g5g$>,
    says...

    [ ... ]

    > > 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*?


    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... :)

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, Mar 19, 2008
    #16
  17. Erik Wikström wrote:

    >> 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.


    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?
     
    Eberhard Schefold, Mar 19, 2008
    #17
  18. D. Susman

    James Kanze Guest

    On Mar 18, 10:01 pm, peter koch <> wrote:
    > On 18 Mar., 20:38, Kai-Uwe Bux <> wrote:
    > > peter koch wrote:
    > > > On 18 Mar., 17:30, Jeff Schwab <> wrote:
    > > >> Jerry Coffin wrote:
    > > >> > says...
    > > >> ...
    > > >> >> 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.


    > > >> What he said.


    > > > "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.


    > 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.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orient�e objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34
     
    James Kanze, Mar 19, 2008
    #18
  19. D. Susman

    Pete Becker Guest

    On 2008-03-19 04:31:50 -0400, Eberhard Schefold
    <> said:

    >
    > 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.

    --
    Pete
    Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
    Standard C++ Library Extensions: a Tutorial and Reference
    (www.petebecker.com/tr1book)
     
    Pete Becker, Mar 19, 2008
    #19
  20. D. Susman

    Jerry Coffin Guest

    In article <frqj1n$r04$>,
    says...
    > Erik Wikström wrote:
    >
    > >> 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.

    >
    > 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.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, Mar 19, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark Rae

    Bitwise comparison in RowFilters

    Mark Rae, Oct 7, 2006, in forum: ASP .Net
    Replies:
    2
    Views:
    767
    Mark Rae
    Oct 7, 2006
  2. tschmittldk
    Replies:
    8
    Views:
    398
    Jorgen Grahn
    Dec 29, 2010
  3. Moe Sisko
    Replies:
    2
    Views:
    234
    Moe Sisko
    Jan 7, 2008
  4. corky

    Bitwise comparison failing

    corky, Jul 10, 2004, in forum: Perl Misc
    Replies:
    1
    Views:
    152
    Anno Siegel
    Jul 10, 2004
  5. Deepu
    Replies:
    1
    Views:
    267
    ccc31807
    Feb 7, 2011
Loading...

Share This Page