Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Virtual construtors

Reply
Thread Tools

Virtual construtors

 
 
Mukesh
Guest
Posts: n/a
 
      01-26-2010
Why dont we have virtual constructors?
 
Reply With Quote
 
 
 
 
SG
Guest
Posts: n/a
 
      01-26-2010
On 26 Jan., 19:34, Mukesh <(E-Mail Removed)> wrote:
> Why dont we have virtual constructors?


Because it doesn't make any sense. Are you looking for the abstract
factory pattern?
 
Reply With Quote
 
 
 
 
Joshua Maurice
Guest
Posts: n/a
 
      01-26-2010
On Jan 26, 10:34*am, Mukesh <(E-Mail Removed)> 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?
 
Reply With Quote
 
red floyd
Guest
Posts: n/a
 
      01-26-2010
On Jan 26, 10:34*am, Mukesh <(E-Mail Removed)> wrote:
> Why dont we have virtual constructors?


This is a FAQ. Please see the FAQ, in particular FAQ 20.8

http://www.parashift.com/c++-faq-lit....html#faq-20.8
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      01-27-2010
On Jan 26, 6:34 pm, Mukesh <(E-Mail Removed)> 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
 
Reply With Quote
 
tonydee
Guest
Posts: n/a
 
      01-27-2010
On Jan 27, 3:34*am, Mukesh <(E-Mail Removed)> 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
 
Reply With Quote
 
Mukesh
Guest
Posts: n/a
 
      01-27-2010
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 <(E-Mail Removed)> wrote:
> On Jan 27, 3:34*am, Mukesh <(E-Mail Removed)> 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


 
Reply With Quote
 
Tony D
Guest
Posts: n/a
 
      01-27-2010
On Jan 27, 10:08*pm, Mukesh <(E-Mail Removed)> 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
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      01-27-2010
On Jan 27, 1:08 pm, Mukesh <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Inline destructors and construtors abhijith.net@gmail.com C++ 8 01-31-2009 12:44 AM
Construtors amit tikoo C++ 3 04-05-2006 01:17 PM
V1.1 Virtual Folder when V2.0 installed for the virtual server? Jéjé ASP .Net 2 11-30-2005 05:44 PM
virtual template and virtual access for ADSL circuits Gary Cisco 1 04-28-2005 07:26 PM
Virtual Computer Corporation (VCC) Virtual Workbench VW300 Derek Simmons VHDL 0 08-01-2004 04:55 AM



Advertisments