Is using a C++ "Virtual Constructor" generally considered good practice?

Yes i know the phrase "virtual constructor" makes no sense but i still see articles like this

one: http://www.informit.com/guides/content.aspx?g=cplusplus&开发者_JAVA技巧seqNum=184

and i'v heard it mentioned as a c++ interview.

What is the general consensus? Is a "Virtual Constructor" good practice or something to be avoided completely?

To be more more precise, can some one provide me with a real world scenario where they have had to use it, from where i stand this concept of virt. constr. is a somewhat useless invention but i could be wrong.

---

---

All the author has done is implement prototyping and cloning. Both of which are powerful tools in the arsenal of patterns.

You can actually do something a lot closer to "virtual constructors" through the use of the handle/body idiom:

struct object
{
  void f();
  // other NVI functions...
  object(...?);
  object(object const&)
  object& operator = (object const&);
  ~object();

private:
  struct impl;
  impl * pimpl;
};

struct object::impl
{
  virtual void f() = 0;
  virtual impl* clone() = 0;
  // etc...
};

struct impA : object::impl { ... };
struct impB : object::impl { ... };

object::object(...?) : pimpl(select_impl(...?)) {}
object::object(object const& other) : pimpl(other.pimpl->clone()) {}

// etc...

Don't know if anyone has declared this an Idiom but I've found it useful and I'm sure others have come across the same idea themselves.

Edit: You use factory methods or classes when you need to request an implementation for an interface and do not want do couple your call sites to the inheritance tree behind your abstraction.

You use prototyping (clone()) to provide generic copying of an abstraction so that you do not have to determine type in order to make that copy.

You would use something like I just showed for a few different reasons:

1) You wish to totally encapsulate the inheritance relation behind an abstraction. This is one method of doing so.

2) You want to treat it as a value type at the abstract level (you'd be forced to use pointers or something otherwise)

3) You initially had one implementation and want to add new specifications without having to change client code, which is all using the original name either in an auto declaration or heap allocation by name.

---

The best way to write "virtual constructors" is to use a Prototype pattern with a Clone() virtual method wich calls the copy constructor of the real type of the object and returns a pointer to a base class.

class Base
{
public:
    virtual Base*    Clone() { return new Base(*this); }
};

class Derived : public Base
{
    virtual Base*    Clone() { return new Derived(*this); }
};

It's not considered a good practice and is to use only if you need it (implement a copy-paste function for example)

---

I consider these so-called "virtual constructors" a bad design when used instead of constructors. These are nothing but virtual functions that are supposed to be called at the beginning of use of an instance of a class.

From the link you've posted:

class Browser
{
public:
  //virtual default constructor
  virtual Browser* construct() {return new Browser;} 
};

Let's add a member field:

class Browser
{
  int member;
public:
  //virtual default constructor
  virtual Browser* construct() {return new Browser;} 
};

We need to initialize the member field, how do we do it?

class Browser
{
  int member;
public:
  //virtual default constructor
  virtual Browser* construct() 
  { 
    Browser* b = new Browser;
    b->member = 0;
    return b;
  } 
};

Consider a situation when someone forgets to use template <class T> void func(T & obj) and does something like this:

Browser b;
printf("member=%d", b.member);

This way an uninitialized field is used. There is no way to prevent it.

Now, in this case

class Browser
{
  int member;
public:
  Browser() : member(0) { }
  virtual Browser* construct() { /* some init stuff */ return new Browser;} 
};

the default constructor is always used and member field always initialized. However calling the construct() a "virtual constructor" I consider a naming abuse.

The pattern I showed above is quite common eg. in MFC. CWnd and similar classes use constructors to init instances and Create(...) functions to fully init and create controls. I would never call the Create(...) function a "virtual constructor", anyway.

---

It's something you can use, but only when you really, really need it. Even the guy in the link said that it's only something that you use if desperate.

---

All the answer above doesn't answer the question but are giving some workaround. The answer to the above question is http://www.stroustrup.com/bs_faq2.html#virtual-ctor straight from the language author itself. In short it says you need complete information to construct an object, hence virtual constructor doesn't exist in C++.