Pourquoi n'avons-nous pas un constructeur virtuel en C++?

L'entendre de la bouche des chevaux:).

De Bjarne Stroustrup C++ de Style et de la Technique FAQ
Pourquoi n'avons-nous pas des constructeurs virtuels?

Un appel virtuel est un mécanisme pour obtenir le travail effectué partiels
de l'information. En particulier, "virtuel" nous permet d'appeler une fonction
sachant que toutes les interfaces et pas le type exact de l'objet. Pour
créer un objet, vous avez besoin d'une information complète. En particulier, vous
besoin de connaître le type exact de ce que vous voulez créer. Par conséquent,
un "appel à un constructeur" ne peut pas être virtuel.

L'entrée de la FAQ va donner le code pour un moyen de parvenir à cette fin sans un constructeur virtuel.

Contrairement aux langages orientés objet tels que Smalltalk ou Python, où le constructeur est une méthode virtuelle de l'objet représentant la classe (ce qui signifie que vous n'avez pas besoin du GoF abstrait modèle de fabrique, que vous pouvez passer de l'objet représentant la classe autour au lieu de faire votre propre), le C++ est une classe de langue, et de ne pas les objets qui représentent tout de la langue de constructions. La classe n'existe pas comme un objet au moment de l'exécution, de sorte que vous ne pouvez pas appeler une méthode virtuelle sur elle.

Cela concorde avec l' "vous n'avez pas à payer pour ce que vous n'utilisez pas de "philosophie", bien que chaque grand projet C++ que j'ai vu a fini par mettre en place une certaine forme de résumé de l'usine ou de réflexion.

Nous faisons, c'est juste pas un constructeur 🙂

struct A {
  virtual ~A() {}
  virtual A * Clone() { return new A; }
};

struct B : public A {
  virtual A * Clone() { return new B; }
};

int main() {

   A * a1 = new B;
   A * a2 = a1->Clone();    //virtual construction
   delete a2;
   delete a1;
}

Résumé: la Norme C++ pourrait spécifier une notation et le comportement de "virtuel constructeur"s qui est assez intuitif et pas trop dur pour les compilateurs de soutien, mais pourquoi faire un changement de Norme pour cette notamment lorsque la fonctionnalité peut déjà être correctement mis en œuvre à l'aide de create() /clone() (voir ci-dessous)? Il n'est pas aussi utile que de nombreuses autres langues proposition dans le pipeline.

Discussion

Laissez le postulat d'un "virtuel constructeur" mécanisme:

Base* p = new Derived(...);
Base* p2 = new p->Base();  //possible syntax???

Ci-dessus, la première ligne construit un Derived objet, de sorte *pvirtuelle expédition table peut raisonnablement fournir un "virtuel constructeur" pour une utilisation dans la deuxième ligne. (Des dizaines de réponses sur cette page indiquant "l'objet n'existe pas encore de manière virtuelle la construction est impossible" sont inutilement myope porté sur l'objet construit.)

La deuxième ligne postulats de la notation new p->Base() à la demande de l'allocation dynamique et par défaut de la construction d'un autre Derived objet.

Notes:

• le compilateur doit orchestrer l'allocation de la mémoire avant d'appeler le constructeur - constructeurs normalement soutien automatique (officieusement "pile") allocation, statique (pour global/espace de noms de la portée et de la classe/fonction-static objets), et dynamique (officieusement "tas") lorsque new est utilisé

  • la taille de l'objet à être construit par p->Base() peut généralement pas être connue à la compilation, donc l'allocation dynamique est la seule approche qui fait sens

    • il est possible d'allouer à l'exécution, les quantités indiquées de la mémoire sur la pile - par exemple GCC est de longueur variable tableau extension, alloca() - mais conduit à d'importantes inefficacités et de la complexité (par exemple, ici et ici respectivement)

• pour l'allocation dynamique, il doit retourner un pointeur ainsi, la mémoire peut être deleted plus tard.

• la postulé notation explicitement listes new d'insister sur l'allocation dynamique et le pointeur type de résultat.

Le compilateur devra:

• savoir de combien de mémoire Derived nécessaire, soit par l'appel implicite virtual sizeof fonction ou d'avoir de telles informations disponibles via le RTTI
• appel operator new(size_t) d'allouer de la mémoire
• invoquer Derived() avec le placement new.

OU

• créer un supplément de vtable entrée pour une fonction qui combine l'allocation dynamique et la construction

Soi - il ne semble pas insurmontable pour spécifier et mettre en œuvre des constructeurs virtuels, mais le million dollar question est: comment serait-il mieux que ce qui est possible à l'aide de C++ existant fonctionnalités de la langue...? Personnellement, je ne vois pas l'avantage, par rapport à la solution ci-dessous.

---

"clone ()" et " create()`

La C++ FAQ documents "virtuel constructeur" l'idiome, contenant virtual create() et clone() méthodes à défaut de construire ou copiez-la construction d'un nouveau allouée dynamiquement l'objet:

class Shape {
  public:
    virtual ~Shape() { } //A virtual destructor
    virtual void draw() = 0; //A pure virtual function
    virtual void move() = 0;
    //...
    virtual Shape* clone() const = 0; //Uses the copy constructor
    virtual Shape* create() const = 0; //Uses the default constructor
};
class Circle : public Shape {
  public:
    Circle* clone() const; //Covariant Return Types; see below
    Circle* create() const; //Covariant Return Types; see below
    //...
};
Circle* Circle::clone() const { return new Circle(*this); }
Circle* Circle::create() const { return new Circle(); }

Il est également possible de modifier ou de surcharge create() à accepter des arguments, mais pour correspondre à la classe de base /interface virtual signature de fonction, les arguments pour les remplacements doivent correspondre exactement à celui de la classe de base des surcharges. Avec ces explicite de l'utilisateur des installations, il est facile d'ajouter de journalisation, d'instrumentation, de modifier l'allocation de la mémoire etc..

Bien que le concept de virtuel les constructeurs ne cadrent pas bien depuis type d'objet est pré-requis pour la création d'objet, il n'est pas complètement ignoré.

GOF de l'usine de la méthode "design pattern permet d'utiliser le "concept" de virtuel constructeur, ce qui est pratique dans certaines situations de calcul.

Quand les gens posent une question comme ça, j'aime à penser à moi-même "qu'arriverait-il si c'était réellement possible?" Je ne sais pas vraiment ce que cela signifie, mais je pense qu'il aurait quelque chose à voir avec le fait d'être en mesure de remplacer le constructeur mise en œuvre, basé sur le type dynamique de l'objet créé.

Je vois un certain nombre de problèmes potentiels avec cette. Pour une chose, la classe dérivée ne sera pas entièrement construite à l'époque du virtuel constructeur est appelé, il y a donc des problèmes potentiels avec la mise en œuvre.

Deuxièmement, ce qui se passerait dans le cas de l'héritage multiple? Votre constructeur virtuel serait appelé plusieurs fois probablement, vous devez avoir un moyen de savoir qui a appelé.

Troisièmement, en général au moment de la construction, l'objet n'a pas la table virtuelle entièrement construit, ce qui signifie qu'il aurait besoin d'un grand changement de la spécification du langage pour permettre le fait que le type dynamique de l'objet qui allait être connu au moment de la construction. Cela permettrait alors de la base de constructeur de classe peut-être appeler d'autres fonctions virtuelles au moment de la construction, avec un pas entièrement construite dynamique type de classe.

Enfin, comme quelqu'un l'a souligné, vous pouvez mettre en œuvre une sorte de virtual constructeur statique à l'aide de "créer" ou "init" type de fonctions qui, en gros, faire la même chose qu'un constructeur virtuel ferait.

Vous ne devez pas appeler une fonction virtuelle au sein de votre constructeur soit. Voir : http://www.artima.com/cppsource/nevercall.html

En plus je ne suis pas sûr que vous avez vraiment besoin d'un constructeur virtuel. Vous pouvez obtenir des polymorphes de la construction sans elle: vous pouvez écrire une fonction qui permettra de construire votre objet, selon les paramètres nécessaires.

Cant nous disons tout simplement qu'il aime.. On ne peut pas hériter des constructeurs. Donc, il n'y a pas de point déclarant virtuel car le virtuel fournit polymorphisme .

Il y a une très simple raison: les Constructeurs sont effectivement des fonctions statiques, et en C++ aucune fonction statique peut être virtuel.

Si vous avez beaucoup d'expérience avec C++, vous savez tout sur la différence entre statique & fonctions de membre. Les fonctions statiques sont associés à la CLASSE, et non pas les objets (instances), de sorte qu'ils ne voient pas d'un pointeur "this". Seulement des fonctions de membre peut être virtuel, parce que la vtable - le caché tableau de pointeurs de fonction qui fait "virtuel" de travail est vraiment un membre de données de chaque objet.

Maintenant, qu'est-ce que le constructeur de l'emploi? C'est dans le nom - un "T" constructeur initialise T les objets comme ils sont affectés. Automatiquement, cela s'oppose à une fonction de membre de! Un objet doit EXISTER avant d'avoir un pointeur "this" et donc une vtable. Cela signifie que même si la langue traitée constructeurs comme des fonctions (il n'a pas, pour des raisons que je ne vais pas entrer dans), ils doivent être des fonctions de membre statique.

Une excellente façon de voir cela est de regarder la "Fabrique" de modèle, en particulier de l'usine de fonctions. Ils font ce que vous êtes après, et vous remarquerez que si la classe T est une méthode de fabrique, il est TOUJOURS STATIQUE. Il doit être.

Si vous pensez logiquement comment les constructeurs de travail et le sens/l'utilisation d'une fonction virtuelle est en C++, alors vous réaliserez qu'un constructeur virtuel serait dénuée de sens en C++. Déclarer quelque chose de virtuel en C++ signifie qu'il peut être remplacée par une sous-classe de la classe actuelle, cependant, le constructeur est appelé lorsque l'opposé est créé, à l'époque, vous ne pouvez pas créer une sous-classe de la classe, vous devez être la création de la classe donc il n'y en aurait jamais besoin de déclarer un constructeur virtuel.

Et une autre raison est que les constructeurs ont le même nom que son nom de la classe et, si nous déclarons constructeur virtuel, alors il devrait être redéfini dans sa classe dérivée avec le même nom, mais vous ne pouvez pas avoir le même nom de deux classes. Donc, il n'est pas possible d'avoir un constructeur virtuel.

La Vpointer est créé au moment de la création de l'objet. vpointer coutume existe avant la création de l'objet. donc, il n'y a pas de point d'en faire le constructeur virtuel.