Virtual construtors

Discussion in 'C++' started by Mukesh, Jan 26, 2010.

  1. Mukesh

    Mukesh Guest

    Why dont we have virtual constructors?
     
    Mukesh, Jan 26, 2010
    #1
    1. Advertising

  2. Mukesh

    SG Guest

    On 26 Jan., 19:34, Mukesh <> wrote:
    > Why dont we have virtual constructors?


    Because it doesn't make any sense. Are you looking for the abstract
    factory pattern?
     
    SG, Jan 26, 2010
    #2
    1. Advertising

  3. On Jan 26, 10:34 am, Mukesh <> wrote:
    > Why dont we have virtual constructors?


    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?
     
    Joshua Maurice, Jan 26, 2010
    #3
  4. Mukesh

    red floyd Guest

    red floyd, Jan 26, 2010
    #4
  5. Mukesh

    James Kanze Guest

    On Jan 26, 6:34 pm, Mukesh <> wrote:
    > Why dont we have virtual constructors?


    Because virtual functions are dispatched on the type of an
    existing object, and when you use a constructor, there is no
    existing object.

    --
    James Kanze
     
    James Kanze, Jan 27, 2010
    #5
  6. Mukesh

    tonydee Guest

    On Jan 27, 3:34 am, Mukesh <> wrote:
    > Why dont we have virtual constructors?


    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
     
    tonydee, Jan 27, 2010
    #6
  7. Mukesh

    Mukesh Guest

    I am agree that there is no sense using virtual construstor.
    What about if we have default construtor and then virtual copy
    constructor ?


    On Jan 27, 11:24 am, tonydee <> wrote:
    > On Jan 27, 3:34 am, Mukesh <> wrote:
    >
    > > Why dont we have virtual constructors?

    >
    > 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
     
    Mukesh, Jan 27, 2010
    #7
  8. Mukesh

    Tony D Guest

    On Jan 27, 10:08 pm, Mukesh <> wrote:
    > I am agree that there is no sense using virtual construstor.
    > What about if we have default construtor and then virtual copy
    > constructor ?


    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
     
    Tony D, Jan 27, 2010
    #8
  9. Mukesh

    James Kanze Guest

    On Jan 27, 1:08 pm, Mukesh <> wrote:
    > I am agree that there is no sense using virtual construstor.
    > What about if we have default construtor and then virtual copy
    > constructor ?


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

    --
    James Kanze
     
    James Kanze, Jan 27, 2010
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Derek Simmons
    Replies:
    0
    Views:
    811
    Derek Simmons
    Aug 1, 2004
  2. Jéjé
    Replies:
    2
    Views:
    407
    Jéjé
    Nov 30, 2005
  3. while_1
    Replies:
    2
    Views:
    638
    Roedy Green
    Jun 25, 2004
  4. amit tikoo

    Construtors

    amit tikoo, Apr 5, 2006, in forum: C++
    Replies:
    3
    Views:
    335
    Ben Pope
    Apr 5, 2006
  5. Replies:
    8
    Views:
    534
    Alf P. Steinbach
    Jan 31, 2009
Loading...

Share This Page