views:

369

answers:

2

Hi, all. I'm pretty new to C++, and I'm writing a small library (mostly for my own projects) in C++. In the process of designing a type hierarchy, I've run into the problem of defining the assignment operator.

I've taken the basic approach that was eventually reached in this article, which is that for every class MyClass in a hierarchy derived from a class Base you define two assignment operators like so:

class MyClass: public Base {
public:
    MyClass& operator =(MyClass const& rhs);
    virtual MyClass& operator =(Base const& rhs);
};

// automatically gets defined, so we make it call the virtual function below
MyClass& MyClass::operator =(MyClass const& rhs);
{
    return (*this = static_cast<Base const&>(rhs));
}

MyClass& MyClass::operator =(Base const& rhs);
{
    assert(typeid(rhs) == typeid(*this)); // assigning to different types is a logical error
    MyClass const& casted_rhs = dynamic_cast<MyClass const&>(rhs);
    try {
        // allocate new variables
        Base::operator =(rhs);
    } catch(...) {
        // delete the allocated variables
        throw;
    }
    // assign to member variables
}

The part I'm concerned with is the assertion for type equality. Since I'm writing a library, where assertions will presumably be compiled out of the final result, this has led me to go with a scheme that looks more like this:

class MyClass: public Base {
public:
    operator =(MyClass const& rhs); // etc
    virtual inline MyClass& operator =(Base const& rhs)
    {
        assert(typeid(rhs) == typeid(*this));
        return this->set(static_cast<Base const&>(rhs));
    }
private:
    MyClass& set(Base const& rhs); // same basic thing
};

But I've been wondering if I could check the types at compile-time. I looked into Boost.TypeTraits, and I came close by doing BOOST_MPL_ASSERT((boost::is_same<BOOST_TYPEOF(*this), BOOST_TYPEOF(rhs)>));, but since rhs is declared as a reference to the parent class and not the derived class, it choked.

Now that I think about it, my reasoning seems silly -- I was hoping that since the function was inline, it would be able to check the actual parameters themselves, but of course the preprocessor always gets run before the compiler. But I was wondering if anyone knew of any other way I could enforce this kind of check at compile-time.

A: 

If you want things to be determined at compile-time, then dynamic polymorphism (virtual functions, etc) is not the right tool for you. I generally don't see the need to mix dynamic polymorphism with things "normal value types" have -- like assignment operators. Maybe concrete and non-polymorphic classes is what works best in your case. But it's hard to tell because you havn't said anything about what you're trying to do with the classes.

sellibitze
+7  A: 

You can't perform this assert at compile time for the simple reason that the run-time types won't be known until, well, run time.

assert(typeid(rhs) == typeid(*this));
return this->set(static_cast<Base const&>(rhs));

In the non-inline version you had dynamic_cast. I would retain this so that you get a well-defined error and not undefined behaviour if your assertion is violated.

If you do this the assertion is either overly restrictive or pointless. The dynamic_cast will throw a bad_cast exception in both debug and release builds. This is what you want.

Personally, I would question the whole polymorphic assignment issue. I would follow Scott Meyers' Effective C++ advise and make all your non-leaf nodes in the inheritance hierarchy abstract. You can then make the base class assignment operators protected and non-virtual.

This enables you to use their implementation in derived classes assignment operator but prevents clients from slicing objects. If a client class has only a base class reference or pointer it is questionable whether the should be attempting to assign to the class anyway. If the do, they should be responsible for the casting and type safety guarantees.

Charles Bailey
+1 for `protected` assignment operator and copy constructor for non-leaf classes. There's always the virtual `clone` method for copying anyway.
Matthieu M.