virtual functions

[vaividhya]

We can have virtual destructors.Why we can't have virtual constructors?

 

[Tomás]

(e-mail address removed) posted:

We can have virtual destructors.Why we can't have virtual constructors?

'Cause they'd be redudant. A constructor is called once: upon
construction of the object. An object is contructed as follows:

TypeName object_name;

Therefore, the compiler knows straight away which contructor should be
called, and therefore need not consult any v-table.

-Tomás

 

[Rolf Magnus]

We can have virtual destructors.Why we can't have virtual constructors?

Because for virtual functions (including the destructor), the system
determins the dynamic type of the object to find out which function to call
at runtime. But a constructor is called to create the object, so there is
no dynamic type to find out yet.

 

[Tejas Kokje]

We have virtual destructors because of run time polymorphism. Consider
following example,

class Base {

char *p;

Base() {
p = new char[20];
}

~Base() {

delete[] p;

}

};

class Derived: public Base {

char *t;

Derived() {
t = new char[20];
strcpy (t,p);
}

~Derived() {
delete[] t;
}

};

Now if you declare a Base class pointer

Base *b = new Derived();

and then do
delete b;

it will call Base class destructor instead of derived class destructor
since Base class desctructor is not virtual. This will keep memory
allocated to t and never free up. Also, if p is being used by derived
class, it will be freed by Base class destructor before derived class
is destroyed.

If we declare Base class destructor as virtual, then derived class
destructor will be called first and then Base class destructor.

As for constructor not being virtual, you would not want to use p in
derived class before it is allocated in Base class. Base class
constructor should be called first and then derived class.

Hope this helps.

Tejas Kokje
Code Monkey
http://mailmount.sf.net

 

[Phlip]

Because for virtual functions (including the destructor), the system
determins the dynamic type of the object to find out which function to
call at runtime. But a constructor is called to create the object, so
there is no dynamic type to find out yet.

That's not "why", it just states what the current mechanism is.

The compiler always knows the type of the fully-formed object at
construction time. So C++ could have been defined as constructing the
complete virtual method jump table first, instead of last. Then
constructors could freely call virtual methods into the derived classes,
and the result would be virtual construction.

The reason we can't upgrade the current language to support that feature is
too much code depends on constructors calling virtual methods that don't
dispatch to their derived overrides. The work-around might be "Coplien's
Curiously Recurring Template Pattern".

 

[Alf P. Steinbach]

* Phlip:

That's not "why", it just states what the current mechanism is.

Right you are, so far.

In at least one situation the C++ abstract machine is capable of finding
a relevant static function based on an object's dynamic type (namely, a
deallocation function, 'operator delete'), and in like manner the
language could technically have supported virtual constructors, either
with some run-time checking of argument types, or corresponding checking
of an assumed signature against the actual dynamically found signature,
or simply requiring some fixed, generic signature.

The compiler always knows the type of the fully-formed object at
construction time. So C++ could have been defined as constructing the
complete virtual method jump table first, instead of last. Then
constructors could freely call virtual methods into the derived classes,
and the result would be virtual construction.

In one sense of "virtual construction", yes: that's the way it works in
Java and C#.

But this is something very different from calling a constructor virtually.

Instead, it's all about virtual calls from a constructor.

The reason we can't upgrade the current language to support that feature is
too much code depends on constructors calling virtual methods that don't
dispatch to their derived overrides.

No, the reason that we can't downgrade to the Java/C# model is that we
want to preserve type safety, where type safety includes the notion of
class invariants; see the FAQ at <url:
http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.5>.

The reason why we, in practice, can't upgrade C++ to directly support
virtual constructors, virtual calls of constructors, is that this would
extend the language a great deal for something that can easily be
achieved within the language as-is, namely via clone functions.

For those who are not familiar with clone functions, see the FAQ, <url:
http://www.parashift.com/c++-faq-lite/virtual-functions.html#faq-20.8>.

The work-around might be "Coplien's Curiously Recurring Template Pattern".

That's one of several work-arounds for implementing something akin to
the Java/C# model; see the FAQ at <url:
http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.6>.

 

[Phlip]

But this is something very different from calling a constructor virtually.

Instead, it's all about virtual calls from a constructor.

Correct. I'm playing language inventor. I tell my teeming minions that y'all
can't get virtual constructors, but I will give you virtual method calls
from within constructors, because they are just as useful. And per your FAQ
citation, they are indeed dangerous, but that never stopped C++ before. And
the FAQ citation doesn't say why we _can't_ downgrade to the Java system,
just why we won't.

Also The Standard sez that constructors are "not functions", so I don't want
to go against whatever else that implies. Subconstructor notation,
try{}catch wrappers, and who knows what else.

So the ultimate "why" is probably going to be "because" here...

 

[chakresh]

I am unable to undestand why we need virtual constructor.
As when we create some object we know the type of object and call that
constructor so why need virtual const.
In decst..case we can have a case where derived object is pointed by a
pointer of base class and we use delete to release memory. and if it
would be virtual distructor then only it can call proper derivced class
const...

Corect me if I am wrong