Re: virtual constructors and distructors...
On Jun 28, 6:13 am, Guillermo Schwarz <guillermo.schw...@gmail.com>
wrote:
On Jun 27, 12:46 pm, Diego Martins <jose.di...@gmail.com> wrote:
On Jun 26, 7:55 am, dasjotre <dasjo...@googlemail.com> wrote:
struct Base
{
virtual ~Base()=0{}
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.
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.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34