operator= in subclass

Question

Hi,

I'm quite confused about how to solve the following problem (search both on SO and google didn't help much).

Say we have a class defining basic operators and a simple vector as only data and add only additional methods in inherited classes:

class Foo
{
    public:
        // this only copies the data
        Foo& operator=(const Foo& foo);

        // do something that computes a new Foo from *this
        Foo modifiedFoo();

    //..
    private:
        std::vector<int> data;
}

class Bar: public Foo
{
    public:
       void someNewMethod();
    //..
    // no new data
}

Inheritance now ensures that the operator= in the case bar1 = bar2 does the right thing. But from the data point of view, both Bar and Foo are basically the same, so I'd like to be able to write both

Foo foo;
Bar bar;

foo = bar;  // this ...
bar = foo;  // .. and this;

and more specifically

bar = foo.modifiedFoo();

[ Edit: And btw, this doesn't work either obviously...

bar1 = bar2.modifiedFoo();

]

I thought it would be as easy as adding another Bar& operator=(const Foo & foo) in Bar, but somehow this is ignored (and I don't like this anyways, what if I derive more and more classes?)

So what is the right way to go about this??

Thanks!! And sorry if this has been asked before.

Answer 1

This is known as the slicing problem:

foo = bar;

Basically the bar object is used as if it is only a Foo.
Then the Foo part of bar is copied onto the foo object (thus slicing away any knowledge that it was a Bar).

Because the compiler automatically defines an assignment operator for a class. The following is not valid:

bar = foo; 

Here the compiler sees bar is of type 'Bar' and looks for the assignment operator. It finds the compiler generated one in 'Bar' and tries to apply it (the one in Foo is now hidden). The compiler generated assignment operator looks like this:

Bar& operator=(Bar const& rhs)

Thus the above line does not match and assignment fails.

Answer 2

If you want to be able to implicitly cast Foos into Bars, create a non-explicit constructor.

class Bar: public Foo
{
    public:
        Bar(const Foo&);
    //
}

Now when you write 'bar = foo', the Foo is implicitly cast into a temporary Bar, so the Bar assignment operator can be used successfully.

Answer 3

Martin told you what went wrong, here's what you should do instead:

Bar bar;
Foo& foo = bar;  // this works now

Now foo is a reference to a an object, and you can have base class references (and pointers, BTW) refer to objects of derived classes.

However, this

bar = foo;

will never work (at least not implicitly) and it shouldn't. What you're trying to do here is to assign a base class object (or reference) to a derived class.
However, while a derived class can always stand in for a base class object, the opposite is not true. (You can't just mindlessly use any vehicle when what you need is a boat, because not all vehicles are boats, the vehicle you're using might be a car and you'd drown.)

This is not to say that you cannot make it work. if you know how to create a derived class object from a base class object, you can write a function to do so. It's just that the compiler doesn't know how to make a car from a vehicle.

As solipist has shown, such a conversion function can be a constructor. However, I would make conversion constructors explicit:

class Bar: public Foo
{
    public:
        explicit Bar(const Foo&);
    //
}

The explicit keyword makes sure that the compiler will never attempt to call this constructor unless you say so. If you remove it, then this code would compile:

//void f(Foo); // you meant to call this, but forgot to include its header
void f(Bar); // you didn't even know this was included

Foo foo;
f(foo);  // won't compile with the above Bar class

and the compiler would silently generate this code: f(Bar(foo));
While this seems handy at first, I think I have sooner or later been bitten by every single implicit conversions I allowed to creep into my code and had to remove them later. So many years ago I swore to never allow them anymore.
Note that even with the explicit conversion constructor you can still call f(Bar) with a Foo object - you just have to say so explicitly:

f(Bar(foo)); // compiles fine even with the explicit conversion constructor