M
Mukesh
Why dont we have virtual constructors?
S
SG
Because it doesn't make any sense. Are you looking for the abstract
factory pattern?
J
Joshua Maurice
Generally, a virtual call goes to a particular function definition
based on the type of the most derived complete object it acts on. A
constructor is first called before the object it acts on exists, so
you can't do that same lookup. What semantics do you propose virtual
constructors have?
R
red floyd
This is a FAQ. Please see the FAQ, in particular FAQ 20.8
http://www.parashift.com/c++-faq-lite/virtual-functions.html#faq-20.8
J
James Kanze
Because virtual functions are dispatched on the type of an
existing object, and when you use a constructor, there is no
existing object.
T
tonydee
Been a few comments about this not making sense, but to elaborate with
a framework that might make it easier to explain what you had in mind,
or realise why it might not make sense...
class Fruit
{
Fruit() { }
virtual ~Fruit() { }
};
class Orange : public Fruit
{
Orange() { std::cout << "Orange()\n"; }
}
class Pear : public Fruit
{
Pear() { std::cout << "Pear()\n"; }
}
....then the Pear constructor can be invoked by...
new Pear(); // a new object on the heap
new (address) Pear(); // a new object at an arbitrary memory
location
Pear(); // a local stack-based temp
Pear a; // a local stack-based variable
In any of these situations, the Pear's constructor is called without
any need for "virtual", but the actual type Pear class must be
specified. Perhaps you're hoping a virtual constructor would remove
that latter restriction? That's kind of what virtual functions do in
general... let you invoke an Orange or Pear function when you only
know you have a Fruit. But remember that any given Fruit only becomes
an Orange or Pear at the time it's constructed. virtual functions
just harken back to the earlier determination. If you're calling the
constructor saying "make me a Fruit", you can't magically expect the
compiler to intuit that you felt like an Orange rather than a
Pear.
Hence the FAQ's Pear* clone() and static Pear* create() suggestions...
they use the language's "covariant return type" tolerance (so Pear*
successfully overloads Fruit*), and allow an existing object's runtime
type to determine the new object's type, even though you're referring
to the existing object via a general Fruit*. That's about the most
abstract way of specifying the type to be created. If that's not
enough, and you don't have an existing object of the right type, then
you have to create a factory function, returning Fruit*, with a switch
or if/else statement to run the "return new Orange()" or "return new
Pear()" as you feel appropriate....
Cheers,
Tony
M
Mukesh
I am agree that there is no sense using virtual construstor.
What about if we have default construtor and then virtual copy
constructor ?
What about if we have default construtor and then virtual copy
constructor ?
T
Tony D
Neat idea, and - as far as I can see - possible too. Still, it would
require some significant changes, as C++ currently mandates a distinct
memory allocation step independent of object construction. For your
idea to work, the heap memory allocation itself would need to access
the copy-constructor's argument's RTTI to find the possibly-derived
object's actual size. After that, the constructors from base to
derived could be called in succession....
So, possible, but not a good fit with current operator new
overloading, RTTI etc.. Bit of a shame, as obviously people are
interested enough in how to do this that the FAQ has to document clone
()....
Cheers,
Tony
J
James Kanze
Probably because it's not implementable.
In the end, you can't call the constructor directly; you only
have language constructs which eventually call the constructor.
After having allocated the necessary memory. And to allocate
the necessary memory, the compiler has to know, statically, the
size of the object. Which means that it has to know the type.
In other words, creating an object can't be "virtual".