Thread: Is there any hidden complication?

Originally Posted by manav

Anyway, I will use virtual instead of using pure virtual which, requires more work in every derived class.

Not really since each of them should have a virtual destructor anyway.

Yes, otherwise they will also be abstract.
You must override each and every pure virtual function in the derived classes. Any pure virtual functions will make the class abstract.

This is another issue. You don't need to add the virtual keyword to subsequent functions in derived classes if the function is virtual in the base. They will be virtual anyway.
But for clarity, I always add virtual to all functions.
Try making the Base destructor pure virtual and omitting the one in Derived. The code won't compile if you create a Derived (or shouldn't).

Try making the Base destructor pure virtual and omitting the one in Derived. The code won't compile if you create a Derived (or shouldn't).

It should and would. The implicitly created destructor is a valid override of the pure function.

The code wouldn't link, though, because you still need an implementation of Base::~Base, even if you declared it pure.

Code:

inline Base::~Base() {}

Originally Posted by CornedBee

It should and would. The implicitly created destructor is a valid override of the pure function.

I see, I see. Guess that's what I get for never trying out a virtual destructor.

That seems strange but magical also

Why? The compiler generates a destructor - it has to. Why should this destructor be any different from an explicitly defined constructor in its ability to override the base version?

As for the link issue, I'll try to explain.

Code:

struct Base
{
  virtual ~Base() = 0;
};

struct Derived : Base
{
};

int main()
{
  Derived d;
}

This is the basic situation. Now the compiler generates a destructor for Derived. Including the implicit call to the base, the final version of a destructor looks like this:

Code:

Derived::~Derived()
{
  // Put code from the user-defined destructor here.
  // Put calls to members' destructors here.
  // Put calls to base destructors here.
  Base::~Base();
  // Many compilers end with this:
  return this;
}

See that call to Base::~Base()? It must be there, because the base class must be destructed, no matter what. So the call is generated. The linker then looks for Base::~Base(), but it won't find it, because there is none. The explicit declaration in Base means that the destructor isn't generated, but you don't define it either.

So you have to define it explicitly. Since Base has nothing special to do, it's empty. It still has to be there.

Code:

Base::~Base() {}

As for the inline, it allows the compiler to inline non-virtual calls to the destructor. And because all calls to the destructor are non-virtual (virtual calls aren't possible due to it being pure), that's a good idea. It means the compiler can then optimize the destructor away completely.

So now a Derived HAS-A and IS-A Base? I think I'd roll my own code and stop using generated cruft like that. Or maybe use a language with more elegant support for calling web services (maybe Java, perl, python?).