virtual == operator

Discussion in 'C++' started by Floogle, Oct 20, 2005.

  1. Floogle

    Floogle Guest

    how do i create a virtual == operator. I've tried the following but
    it's incorrect...

    class Interface
    {
    ...

    public:

    virtual bool operator==(const Interface& rhs)const=0;
    };

    class MyClass : public Interface
    {
    ...

    public:

    bool operator==(const MyClass& rhs)const;
    };

    thanks
    Floogle, Oct 20, 2005
    #1
    1. Advertising

  2. Floogle

    Atlas Guest

    Floogle wrote:
    > how do i create a virtual == operator. I've tried the following but
    > it's incorrect...
    >
    > class Interface
    > {
    > ...
    >
    > public:
    >
    > virtual bool operator==(const Interface& rhs)const=0;
    > };
    >
    > class MyClass : public Interface
    > {
    > ...
    >
    > public:
    >
    > bool operator==(const MyClass& rhs)const;
    > };
    >
    > thanks


    operator== should be declared friend to keep its intuitive behaviour.
    friend bool operator==(const Interface& d1,const Interface& d2);
    It can't be virtual, then.
    But it doesn't matter, because the parameter is reference, so you can
    still use dynamic binding by supplying both ends with
    MyClassObj1==MyClassObj2. You don't need to define it in MyClass.
    Atlas, Oct 20, 2005
    #2
    1. Advertising

  3. Floogle wrote:
    > how do i create a virtual == operator. I've tried the following but
    > it's incorrect...
    >
    > class Interface
    > {
    > ...
    >
    > public:
    >
    > virtual bool operator==(const Interface& rhs)const=0;
    > };
    >
    > class MyClass : public Interface
    > {
    > ...
    >
    > public:
    >
    > bool operator==(const MyClass& rhs)const;
    > };


    The argument has to be of the same type. Inside you can dynamic_cast it
    to MyClass const&, and catch the exception if it's not of MyClass type,
    and return false in that case, probably.

    V
    Victor Bazarov, Oct 20, 2005
    #3
  4. Floogle

    Mirek Fidler Guest

    > The argument has to be of the same type. Inside you can dynamic_cast it
    > to MyClass const&, and catch the exception if it's not of MyClass type,
    > and return false in that case, probably.


    Well, maybe dynamic_cast of pointer and testing for NULL is cheaper, is
    not it?

    Mirek
    Mirek Fidler, Oct 20, 2005
    #4
  5. "Floogle" <> wrote in message
    news:...

    > how do i create a virtual == operator.


    A search on Google groups proved that in the past, I've responded to such a
    question like this :)

    <quote>
    In the past, I've used a variation of that method for operator<, but
    it should work for operator== as well.

    Define 'bool operator==(B const & other) const;' in the base class but
    call a private pure virtual isEqual member when the types are the
    same:

    if (typeid(*this) == typeid(other))
    {
    return isEqual(other);
    }
    else
    {
    return false;
    }

    In the most derived classes, you can trust the typeid check performed
    in operator==, and do a static_cast in isEqual:

    class D
    {
    int member_;

    virtual bool isEqual(Base const & o) const
    {
    Derived const & other = static_cast<Derived const &>(o);

    return member_ == other.member_;
    }
    /* ... */

    };

    I couldn't use a compiler to test this code. I hope there aren't many
    errors :)

    Ali
    </quote>

    I think today I would write Base::eek:perator== in a shorter way:

    bool Base::eek:perator== (Base const & other)
    {
    return ((typeid(*this) == typeid(other)) &&
    isEqual(other));
    }

    Ali
    =?iso-8859-1?Q?Ali_=C7ehreli?=, Oct 20, 2005
    #5
  6. Mirek Fidler wrote:
    >> The argument has to be of the same type. Inside you can dynamic_cast it
    >> to MyClass const&, and catch the exception if it's not of MyClass type,
    >> and return false in that case, probably.

    >
    >
    > Well, maybe dynamic_cast of pointer and testing for NULL is cheaper, is
    > not it?


    Unless it's proven to be different (and actually affecting the program's
    performance), I am not going to guess. Neither should anyone else.

    V
    Victor Bazarov, Oct 20, 2005
    #6
  7. Floogle

    Kaz Kylheku Guest

    Floogle wrote:
    > how do i create a virtual == operator. I've tried the following but
    > it's incorrect...


    The short answer is that you use an more powerful object-oriented
    programming system in which a virtual function is dispatched by
    considering the dynamic types of *all* of the specializable arguments.

    There is a crutch design pattern that you can use in a less powerful
    object system, like that of C++, to emulate multiple dispatch. You end
    up making two virtual function calls.

    The first virtual call dynamically dispatches on the left object, and
    goes to a stub function, whose only purpose is to dispatch one more
    time on the right object.

    This is done in the ``Visitor Pattern'' for instance. The problem with
    that pattern is that it uses generic terminology like ``visit'' and
    ``accept'' which obscures the semantics of what the user is actually
    implementing. You can rip out the double dispatch trick, without
    taking in the whole pattern in.


    > class Interface
    > {
    > ...
    >
    > public:
    >
    > virtual bool operator==(const Interface& rhs)const=0;
    > };
    >
    > class MyClass : public Interface
    > {
    > ...
    >
    > public:
    >
    > bool operator==(const MyClass& rhs)const;
    > };


    Of course, the function you have here in MyClass is not an overload of
    the base class virtual function, because the type signature does not
    match. You must in fact implement:

    bool operator==(const Interface &rhs) const;

    So now, the problem is that this dispatches only on the type of the
    object on which the virtual is called. You know that your ``this''
    pointer is a MyClass, but you need to handle all combinations of
    MyClass and everything else. The trick is to invoke another virtual
    function, this time on the rhs object:

    bool MyClass::eek:perator==(const Interface &rhs) const
    {
    return rhs.operator == (*this);
    }

    In this second virtual call, the arguments are reversed: the parameter
    is now const MyClass & and static overload resolution is being used to
    find the method. That's because we know the exact type of the left hand
    side object!

    All you need now is additional virtual functions inside Interface which
    are specialized to various types of objects.

    // Inside Interface base:
    virtual bool operator==(const MyClass& rhs) const = 0;
    virtual bool operator==(const YourClass &rhs) const = 0;

    // .. etc ... for every darn class! Every time you add a class
    // to your framework, you have to add an entry here, and
    // implement the combination throughout the entire framework!!!

    So for instance the combination MyClass X MyClass -> bool is handled by
    writing an additional function in MyClass:

    bool MyClass::eek:perator == (const MyClass &lhs) const
    {
    }

    and the YourClass X MyClass -> bool combination is handled like this:

    // You HAVE to implement this because it's a pure virtual
    // inside the Interface base!!!

    bool MyClass::eek:perator == (const YourClass &lhs) const
    {
    // handle the combination here.
    }

    and so on. I'm calling it lhs because the order is reversed; we are at
    the second dispatch level, where we invoked the virtual function on the
    right hand side object in the original ==() call! The original left
    hand object is now the argument.

    One thing you might want to do is use a different name for the two
    steps, like in the visitor pattern, which has visit() for the first
    call and accept() for the other. Confusion can occur because some of
    the == functions can be called non-virtually, when you aren't going
    through base classes. In this case, it should all be cool because the
    comparison is commutative (right?)

    That is to say, if you have two MyClass objects and you compare them
    with ==, then it will just go to the operator == (const MyClass &)
    right away without the double dispatch, and the right hand side will be
    assumed to be the left.

    To avoid that, do it like this:

    class Interface {
    public:
    // entry point into comparison
    virtual bool operator == (const Interface &rhs) const = 0;

    // second dispatch completion routines, distinct from operator
    virtual bool eq_impl(const MyClass &from_lhs) const = 0;
    virtual bool eq_impl(const YourClass &from_lhs) const = 0;
    // repeat for every darn class, implement all combos
    };

    The operator == implementation is the same everywhere:

    return rhs.eq_impl(*this);

    everyone must implement this. Everyone must also implement every
    eq_impl for every left hand class.

    This could be extended to triple dispatch:

    virtual void func(Interface &B, Interface &C) = 0;

    Let's refer to the first object as the hidden parameter ``A'', so the
    manifest parameters are B and C.

    At the first level, the type of the object is established. So now, it
    can invoke a second level virtual, invoked on Interface B. The ``A''
    object now appears as a concrete parameter with an exact class. C
    remains abstract:

    virtual void func2(Concrete &A, Interface &C) = 0;

    here, the exact type of A and B is known, so a final virtual call can
    take place on object C, which statically chooses a virtual based on
    these two types:

    virtual void func3(Concrete &A, Concrete &B) = 0;

    Note that if you have M implementations of the interface, then you need
    M implementations of func(), M * M implementations of func2(), and M *
    M * M implementations of func3().

    Probably a good idea to make some of these impure, so you can inherit
    default behaviors and not have to deal with all the combos.
    Kaz Kylheku, Oct 20, 2005
    #7
  8. Floogle

    Kaz Kylheku Guest

    Mirek Fidler wrote:
    > > The argument has to be of the same type. Inside you can dynamic_cast it
    > > to MyClass const&, and catch the exception if it's not of MyClass type,
    > > and return false in that case, probably.

    >
    > Well, maybe dynamic_cast of pointer and testing for NULL is cheaper, is
    > not it?


    That depends on how exception handling is implemented, how frequently
    the exceptional case occurs in your program, and at what level you
    catch it.
    Kaz Kylheku, Oct 20, 2005
    #8
  9. Floogle

    Mirek Fidler Guest

    Kaz Kylheku wrote:
    > Mirek Fidler wrote:
    >
    >>>The argument has to be of the same type. Inside you can dynamic_cast it
    >>>to MyClass const&, and catch the exception if it's not of MyClass type,
    >>>and return false in that case, probably.

    >>
    >>Well, maybe dynamic_cast of pointer and testing for NULL is cheaper, is
    >>not it?

    >
    >
    > That depends on how exception handling is implemented, how frequently
    > the exceptional case occurs in your program, and at what level you
    > catch it.


    Well, I believe that:

    - test for type has to be performed in both cases (I mean both for
    pointer and reference)

    - raising exception will cost you something no matter what

    - in this case, the place where you catch the exception is in the same
    function, so no possible saveings from passing multiple frames here

    On some systems the difference might be small, but I do not believe that
    in this particular case there is platform where exception based solution
    would be faster. On many current platforms, it will be significantly slower.

    Plus, it is more complex and more verbose code as well.

    Mirek
    Mirek Fidler, Oct 21, 2005
    #9
    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. Derek Simmons
    Replies:
    0
    Views:
    785
    Derek Simmons
    Aug 1, 2004
  2. Jéjé
    Replies:
    2
    Views:
    385
    Jéjé
    Nov 30, 2005
  3. while_1
    Replies:
    2
    Views:
    613
    Roedy Green
    Jun 25, 2004
  4. Jim Fischer
    Replies:
    3
    Views:
    420
    Jim Fischer
    Jul 31, 2003
  5. Michael Winter
    Replies:
    9
    Views:
    600
    Michael Winter
    Sep 24, 2003
Loading...

Share This Page