tags:

views:

1477

answers:

10

Why do we not have a virtual constructor?

A: 

You shouldn't call virtual function within your constructor either. See : http://www.artima.com/cppsource/nevercall.html

In addition I'm not sure that you really need a virtual constructor. You can achieve polymorphic construction without it: you can write a function that will construct your object according to the needed parameters.

Edouard A.
+3  A: 

We do, it's just not a constructor :-)

struct A {
  virtual ~A() {}
  virtual A * Clone() { return new A; }
};

struct B : public A {
  virtual A * Clone() { return new B; }
};

int main() {

   A * a1 = new B;
   A * a2 = a1->Clone();    // virtual construction
   delete a2;
   delete a1;
}
anon
+18  A: 

Virtual functions basically provide polymorphic behavior. That is, when you work with an object whose dynamic type is different than the static (compile time) type with which it is referred to, it provides behavior that is appropriate for the actual type of object instead of the static type of the object.

Now try to apply that sort of behavior to a constructor. When you construct an object the static type is always the same as the actual object type since:

To construct an object, a constructor needs the exact type of the object it is to create [...] Furthermore [...]you cannot have a pointer to a constructor

(Bjarne Stroustup (P424 The C++ Programming Language SE))

Anton Gogolev
+16  A: 

Hear it from the horse's mouth:).

From Bjarne Stroustrup's C++ Style and Technique FAQ Why don't we have virtual constructors?

aJ
+1  A: 

When people ask a question like this, I like to think to myself "what would happen if this were actually possible?" I don't really know what this would mean, but I guess it would have something to do with being able to override the constructor implementation based on the dynamic type of the object being created.

I see a number of potential problems with this. For one thing, the derived class will not be fully constructed at the time the virtual constructor is called, so there are potential issues with the implementation.

Secondly, what would happen in the case of multiple inheritance? Your virtual constructor would be called multiple times presumably, you would then need to have some way of know which one was being called.

Thirdly, generally speaking at the time of construction, the object does not have the virtual table fully constructed, this means it would require a large change to the language specification to allow for the fact that the dynamic type of the object would be known at construction time. This would then allow the base class constructor to maybe call other virtual functions at construction time, with a not fully constructed dynamic class type.

Finally, as someone else has pointed out you can implement a kind of virtual constructor using static "create" or "init" type functions that basically do the same thing as a virtual constructor would do.

1800 INFORMATION
A: 

Only way it makes sense to me is if it is a pure virtual constructor - as in saying there is nothing to do here on say a class used as an interface. The thing is, you don't have to worry about it, the compiler will work that out.

Greg Domjan
+11  A: 

Unlike object oriented languages such as Smalltalk or Python, where the constructor is a virtual method of the object representing the class (which means you don't need the GoF abstract factory pattern, as you can pass the object representing the class around instead of making your own), C++ is a class based language, and does not have objects representing any of the language's constructs. The class does not exist as an object at runtime, so you can't call a virtual method on it.

This fits with the 'you don't pay for what you don't use' philosophy, though every large C++ project I've seen has ended up implementing some form of abstract factory or reflection.

Pete Kirkham
This is exactly the difference between construction in C++ and in a language such as Delphi, where you do have virtual constructors. Well put.
Frederik Slijkerman
+1 - Well written as usual, Pete.
duffymo
I was wondering how the question even made sense until I read this explanation of how object creation works in other languages. +1.
j_random_hacker
"Advanced C++" by James Coplien talks about how to implement virtual constructors in C++ (e.g., new animal("dog")). See http://users.rcn.com/jcoplien/Patterns/C++Idioms/EuroPLoP98.html#VirtualConstructor for some more information on how it's implemented
Tony Lee
+1  A: 

two reasons I can think of:

Technical reason

The object exists only after the constructor ends.In order for the constructor to be dispatched using the virtual table , there has to be an existing object with a pointer to the virtual table , but how can a pointer to the virtual table exist if the object still doesn't exist? :)

Logic reason

You use the virtual keyword when you want to declare a somewhat polymorphic behaviour. But there is nothing polymorphic with constructors , constructors job in C++ is to simply put an object data on the memory . Since virtual tables (and polymorphism in general) are all about polymorphic behaviour rather on polymorphic data , There is no sense with declaring a virtual constructor.

+1  A: 

Semantic reasons aside, there is no vtable until after the object is constructed, thus making a virtual designation useless.

Marius
A: 

The virtual mechanism only works when you have a based class pointer to a derived class object. Construction has it's own rules for the calling of base class constructors, basically base class to derived. How could a virtual constructor be useful or called? I don't know what other languages do, but I can't see how a virtual constructor could be useful or even implemented. Construction needs to have taken place for the virtual mechanism to make any sense and construction also needs to have taken place for the vtable structures to have been created which provides the mechanics of the polymorphic behaviour.

Rich