Thread: copy assignment of polymorphic classes

You have observed type slicing: the copy assignment happens between two trace objects (even though they are actually intersection objects, i.e., the intersection part has been "sliced off" since you dereferenced the pointers to trace), hence only the trace subobjects of the intersection objects are copied.

Originally Posted by skewray

I have noticed that when using the default copy assignment for a virtual polymorphic class, I do not get the behaviour I expect. Although copy assignment of the derived class works fine, copy assignment of the parent class does not. See below to a sketch of an example. Why is there a difference?

Code:

struct trace
    {
    virtual trace* copytype() = 0 ;
    ...
    } ;

struct intersection: public trace    // has no copy assignment operator
    {
    Polynomial<long double> P ;        // has copy assignment operator
    ...
    } ;

    ...
    trace* T = this ;
    trace* X = dynamic_cast<intersection*>( T->copytype() ) ;
    ...
    // below works - X.P is copied to T.P
    *this = *( dynamic_cast<intersection*>(X) ) ;
    // below fails - X.P is not properly copied to T.P
    *T = *X ;

You'd better use smart pointers, unless you really need covariance in your copytype() function.

I don't know what you exactly want to do, but if I were you, I would think twice before using polymorphism and copy-assignment together. Most of the time there is only a need either for value semantics or identity semantics. Whenever I face a problem which looks like solvable via polymorphic value types, I always try to find a simpler solution before I continue to go that way. Why? Well, definitely there are usages for polymorphic value types and I do use them in very special cases. However, the main problem is that polymorphic value types may be hard to maintain in the future if the solution is not well thought out:
- Who and how can create new value types? Is there a need for factory? Traditionally, value types do not need any factory, because their concrete type is always very well known. On the other hand, there is an interface/base class, so each time you declare a value type you must decide whether you need abstraction or concrete functionality.
- What can you do with two polymorphic values through their base class/interface? Can you compare them or add one to another? Can the operation be always performed, or may it fail sometimes?

From my experience I can say that it was easy to get either an overengineered solution, or a solution not overengineered but hard to use. As a result, I am very cautious before incorporating a polymorphic value type. Usually there are other, safer ways of achieving the same results, for example using the strategy pattern.

The history of this is that I have code that works fine, except that there is one polymorphic function that has identical code for every subclass. I am trying to refactor and put the code into "trace". Even if I declare "intersection" to have a copy assignment, it won't work? So I need an explicit T.Copy(X) function for each subclass?

I suppose I could use a template, which might be even uglier.

Originally Posted by skewray

The history of this is that I have code that works fine, except that there is one polymorphic function that has identical code for every subclass. I am trying to refactor and put the code into "trace". So even if I declare "intersection" to have a copy assignment, it won't work?

The thing is, if trace is base class for intersection. It does not know about trace (nor should it), so how does it make sense to put code that clones an intersection into a trace? Similarly, if you make more subclasses from Trace, they would have their own copy logic. You can always use CRTP to reduce the code:

Code:

template<typename T>
class Base
{
    public: virtual T Clone() { return T(*static_cast<T*>(this)); }
};

class Derived: public Base<Derived>
{
}

*T = *X
This simply means to the compiler to call decltype(T)::operator =, which, while an operator, is actually also a function. That function is not declared virtual, hence the compiler will always call the base class's assignment operator. You CAN make it a virtual function, and this would allow for polymorphism, but you're still limited to using the same interface as for the base.

Code:

class A { public: virtual A& operator = (const A&) { std::cout << "Hello World!\n"; return *this; } };
class B: public A { public: virtual A& operator = (const A&) { std::cout << "Bye World!\n"; return *this; } };

int main()
{
	A a;
	B b;
	A& rA = a;
	A& rBThroughA = b;
	a = a;
	rBThroughA = rBThroughA;
}

Originally Posted by skewray

Does this mean that "*T = *X", as a shallow copy assignment, will leave the "intersection" bits of T untouched?

As I mentioned in post #2, the issue is that the type of both *T and *X are of the base class, so to the compiler it is a call to the base class copy assignment operator, since the copy assignment operator is not virtual, hence resulting in type slicing. If you do declare it to be virtual as in Elysia's post #7, then note that the derived class' override is not a copy assignment operator for the derived class: it is another assignment operator, one that has a const reference parameter of the base class type. You would presumably need to do a dynamic_cast to check that the actual argument really is a B object before doing the assignment of members, and this could be a Bad Thing if you are doing plenty of such assignments.

Originally Posted by skewray

Would this be considered good coding practise? Seems like a very clever way to make unmaintainable code.

No, I wouldn't consider is good practice. I was simply demonstrating the effect of virtual and why *T = *X didn't work the way you wanted it to.
Typical good practice with polymorphic classes is to use a Clone() method.

Originally Posted by Elysia

Typical good practice with polymorphic classes is to use a Clone() method.

A clone method is does polymorphic copy construction, not copy assignment though.