Virtual Constructors.

Is there any need of Virtual Constructors? If so can any one post a scenario?

From stackoverflow Diwakar

• In what language? In C++ for example the constructors can not be virtual.

  From grigy

• As always: look up at C++ FAQ lite: virtual functions.

  It will explain not only "virtual constructor" but destructors/functions too!

  This of course, if you wanted C++ in the first place...

  From Marcin Gil

• The constructor can not be virtual by definition. At the time of constructor call there is no object created yet, so the polymorphism does not make any sense.

  Tim Jarvis : Thats simply not true. Construction certainly can be virtual, the whole idea is to be able to declare a variable of type baseclass and construct it from a different concrete class. Delphi is one language for example that allows virtual constructors.
  From grigy

• If you are talking about virtual destructors (in C++) then they should always be used if you are using your child classes polymorphically.

  class A
  {
    ~A();
  }
  
  class B : public A
  {
    ~B();
  }
  
  A* pB = new B();
  delete pB; // NOTE: WILL NOT CALL B's destructor
  
  class A
  {
    virtual ~A();
  }
  
  class B : public A
  {
    virtual ~B();
  }
  
  A* pB = new B();
  delete pB; // NOTE: WILL CALL B's destructor
  

  Edit: Not sure why I've got a downvote for this (would be helpful if you left a comment...) but have a read here as well

  http://blogs.msdn.com/oldnewthing/archive/2004/05/07/127826.aspx

  Roddy : ...Probably downvoted because your answer, while correct, is unrelated to the question. Not by me, BTW...
  From Mark Ingram

• Delphi is one language that supports virtual constructors.

  Typically they would be used in a class factory type scenario where you create a meta type i.e. that is a type that describes a type. You would then use that meta type to construct a concrete example of your descendant class

  Code would be something like....

  type
    MyMetaTypeRef = class of MyBaseClass;
  
  var
    theRef : MyMetaTypeRef;
    inst : MyBaseClass;
  begin 
    theRef := GetTheMetaTypeFromAFactory(); 
    inst := theRef.Create(); // Use polymorphic behaviour to create the class
  

  From Tim Jarvis

• There are plenty of scenarios, for example if you want to create GUIs for more than one environment. Let's say you have classes for controls (“widgets”) but each environment actually has its own widget set. It's therefore logical to subclass the creation of these widgets for each environment. The way to do this (since, as has been unhelpfully pointed out, constructors can't actually be virtual in most languages), is to employ an abstract factory and the above example is actually the standard example used to describe this design pattern.

  Tim Jarvis : Constructors can indeed be virtual in Delphi.
  From Konrad Rudolph

• In C++, there's no reason for constructors to ever be virtual, because they are static functions. That means they're statically bound, so you have to identify the very constructor function you're calling in order to call it at all. There's no uncertainty and nothing virtual about it.

  This also means that, no matter what, you need to know the class that your object is going to be. What you can do, however, is something like this:

  Superclass *object = NULL;
  if (condition) {
      object = new Subclass1();
  }
  else {
      object = new Subclass2();
  }
  object.setMeUp(args);
  

  ... have a virtual function and call it after constructon. This is a standard pattern in Objective-C, in which first you call the class's "alloc" method to get an instance, and then you call the initilializer that suits your use.

  The person who mentioned the Abstract Factory pattern is probably more correct for C++ and Java though.

  David : Pity C++ classes aren't objects.... ----------------- In C++, there's no reason for constructors to ever be virtual,
  From Kevin Conner