Question

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&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.

---

Answer 1

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.