Question

Consider this simple program:

class Shape
{
public:
    virtual double getArea() = 0;

};

class Rectangle : public Shape
{
    int width;
    int height;

public:
    Rectangle( int w , int h ) :width(w) , height(h) {}

    double getArea() const
    {
        return width * height;
    }
};


int main() {

    Rectangle* r = new Rectangle(4,2);
}

Trying to compile this problem gives me:

 'Rectangle' : cannot instantiate abstract class

Why is this not allowed in C++ when covariant return types are? Of course I can fix the program by making Rectangle::getArea to be a non-const function but I am curious as to why the language designers decided otherwise.

EDIT

Lots of people have mentioned in their answers how the signature is different. But so is

class Shape
{
public:
    virtual BaseArea* getArea() = 0;

};

class Rectangle : public Shape
{
public:
    virtual RectangleArea* getArea();
};

but C++ goes out of its way to allow it, when C# doesn’t.

C++ supports covariant return types because if I expect an interface to return a BaseArea* and an implemention returns a RectangleArea*, it is ok as long as RectangleArea derives from BaseArea because my contract is met.

On the same lines, isn’t an implementation that provides a non-mutating function satisfying an interface that only asks for a mutating function?

Answer 1

Most of the answer say why it’s not allowed in terms of the current rules of the language, instead of saying why the rules were written that way. I’ll try to answer why the rules couldn’t have been the way you suggest.

Stroustrup’s Design & Evolution of C++ book describes why the overriding rules were relaxed to allow covariant returns, which weren’t always allowed in C++. So one answer to your question would be that originally overrides had to be exact matches for the signature, and an exception was made for “compatible” return types that don’t weaken the contract of a virtual function. It’s possible they just weren’t relaxed further because noone thought of it or noone suggested it. D&E does mention other possible relaxations of the overriding rules but says “We felt that the benefits from allowing such conversions through overriding would not outweigh the implementation cost and the potential for confusing users.” That’s relevant because I think your idea has plenty of potential for confusing users, and can actually cause safety problems, specifically it weakens the type system.

Consider:

class Square : public Rectangle
{
public:
  explicit Square(int side) : Rectangle(side, side) { }

  virtual double getArea() // N.B. non-const, overrides Shape::getArea
  {
    // class author decides this would be a sensible "sanity check"
    // (I'm not suggesting this is a good implementation)
    if (height != width)
      height = width;
    return Rectangle::getArea();
  }
};

const Square s(2);

int main()
{

  double (Rectangle::*area)() const = &Rectangle::getArea;
  double d = (s.*area)();
}

I believe that your idea would make this code valid, a const member function is invoked on a const object, but actually it is a virtual function so it calls Square::getArea() which is non-const and so it tries to modify a const object, which could be stored in read-only memory and so would result in a segfault.

This is just one example of how allowing your overriding relaxation in the Shape example could result in undefined behaviour, I’m sure in more realistic code there could be bigger, maybe subtler problems.

You could argue that the compiler should not allow a non-const function to override Rectangle::getArea and so should reject Square::getArea (“once a virtual function has gone const it can’t go back”) but that would make hierarchies very fragile. Adding or removing intermediate base classes with getArea functions with different constness would change whether Square::getArea() is an override or an overload. There is already some fragility like this with virtual functions, especially covariant returns, but according to D&E Stroustrup considered covariant returns useful because “the relaxation allows people to do something important within the type system instead of using casts.” I don’t think allowing const functions to override non-const ones fits nicely within the type-system, and doesn’t allow doing anything important, and doesn’t get rid of casts to allow a new (safe) techniques to be used.