virtual constructors and distructors...

[Shraddha]

What is the use of "PURE vitual distructors"?
And why we can not have vitual constructors?

 

[Andre Kostur]

What is the use of "PURE vitual distructors"?

Forces a child class to declare their own destructor. Note that even
though it's a pure virtual destructor, you still need to supply a body.

And why we can not have vitual constructors?

See the FAQ:

http://www.parashift.com/c++-faq-lite/virtual-functions.html#faq-20.8

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

What is the use of "PURE vitual distructors"?

If you have a class that you never want to be used as it is, instead you
want the user to always derive from it you can declare the destructor
pure virtual (but provide an implementation). This forces the user to
derive if they want to use the class.

 

[dasjotre]

What is the use of "PURE vitual distructors"?
And why we can not have vitual constructors?

what is the use of virtual function anyway?

the difference between pure virtual function and
pure virtual destructor is that you have to write
a body for PV destructor while you don't have to for
PV function. also PV function must be implemented
in the Derived (if you want to instantiate Derived) but
you don't have to implement ~Derive, compiler
generated one will suffice

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

struct Derived : public Base
{
~Derived(){}
void foo(){}
};

int main()
{
Base * p = new Derived;
p->foo();
delete p;
}

p->foo() will call Derived::foo, if Base::foo wasn't
virtual it would call Base::foo

delete p will call Derived destructor, if Base
destructor wasn't virtual it would call Base destructor

since ~Derived will call ~Base you have to provide
a body for ~Base even if it is pure virtual

regards

DS

 

[dasjotre]

also, declaring any member pure virtual makes
type non instantiable.

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

Base b; // ERR!

 

[Diego Martins]

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

this is a syntax error


it should be

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

Base::~Base() {}

 

[Guillermo Schwarz]

this is a syntax error

it should be

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

...

Base::~Base() {}

Good point. Also why destructor can be non virtual? Is there any use
for that? I have never seen a real world scenario where destructors
shoudl not be virtual.

On the other hand, constructors can't be virtual as was already
pointed out. Except for one compiler called Borland C++ Builder. That
compiler allowed to declare virtual constructors, although the meaning
was different of what you could expect.

Normally C++ constructors can't make virtual function calls, because
the the VMT (virtual method table) is not fully built yet, leading to
subtle and unexpected bugs. In C++ Builder, you could declare your
constructors to be virtual, meaning that before executing the
constructor, the VMT would be fully built and therefore the virtual
methods would be called as appropiate.

Cheers,
Guillermo.

 

[James Kanze]

Good point. Also why destructor can be non virtual? Is there any use
for that? I have never seen a real world scenario where destructors
shoudl not be virtual.

Really? What about structures which are shared with C? Putting
a vptr into the structure isn't going to please the C compiler
any. For that matter, making the destructor virtual for
something like complex<float> could double the size of the
object. An important consideration for people working with
large arrays of the thing. In general, for classes with value
semantics, there's no reason for the destructor to be virtual,
and every reason for it not to be.

Once a class has virtual functions, of course, the question
changes. The vptr is already there, so making the destructor
virtual doesn't change anything in this respect. And the
presence of virtual functions means that there is a very high
probability that inheritance will be involved somewhere, and
that a virtual destructor will be needed. On the other hand,
making the virtuality of the destructor depend on whether other
virtual functions are present or not isn't very orthogonal, to
say the least, and is another complication. And IMHO, C++
already has enough special cases, and doesn't really need
another one.

On the other hand, constructors can't be virtual as was already
pointed out. Except for one compiler called Borland C++ Builder. That
compiler allowed to declare virtual constructors, although the meaning
was different of what you could expect.

Normally C++ constructors can't make virtual function calls,

Normally, the can, and in some cases, do.

because the the VMT (virtual method table) is not fully built
yet,

Sorry, but the vtbl is always complete, according to the dynamic
type of the object.

leading to
subtle and unexpected bugs.

Avoiding subtle and unexpected bugs is precisely the reason why
the dynamic type evolves. Calling a function on a type whose
constructor hasn't yet started running is a sure recepe for
disaster. Look at all the NullPointerException it causes in
Java.

In C++ Builder, you could declare your
constructors to be virtual, meaning that before executing the
constructor, the VMT would be fully built and therefore the virtual
methods would be called as appropiate.

You mean, the call would dispatch to a function whose this
pointer pointed to raw memory? Thank God C++ doesn't support an
idiocy like that.

 

[Diego Martins]

Really? What about structures which are shared with C? Putting
a vptr into the structure isn't going to please the C compiler
any. For that matter, making the destructor virtual for
something like complex<float> could double the size of the
object. An important consideration for people working with
large arrays of the thing. In general, for classes with value
semantics, there's no reason for the destructor to be virtual,
and every reason for it not to be.

Once a class has virtual functions, of course, the question
changes. The vptr is already there, so making the destructor
virtual doesn't change anything in this respect. And the
presence of virtual functions means that there is a very high
probability that inheritance will be involved somewhere, and
that a virtual destructor will be needed. On the other hand,
making the virtuality of the destructor depend on whether other
virtual functions are present or not isn't very orthogonal, to
say the least, and is another complication. And IMHO, C++
already has enough special cases, and doesn't really need
another one.

FYI, g++ has a pretty useful compiler warning when a class without a
virtual destructor have other virtual functions


Diego