L'appel de méthode virtuelle dans la classe de base constructeur

Je sais que l'appel d'une méthode virtuelle à partir d'un constructeur de classe de base peut être dangereux depuis la classe fille peut ne pas être dans un état valide. (au moins en C#)

Ma question est ce que si la méthode virtuelle est celui qui initialise l'état de l'objet ? Est il bon de le faire ou faut-il un processus en deux étapes, d'abord à créer l'objet et ensuite à la charge de l'état ?

Première option: (en utilisant le constructeur pour initialiser l'état)

public class BaseObject {
    public BaseObject(XElement definition) {
        this.LoadState(definition);
    }

    protected abstract LoadState(XElement definition);
}

Deuxième option: (à l'aide d'un processus en deux étapes)

public class BaseObject {
    public void LoadState(XElement definition) {
        this.LoadStateCore(definition);
    }

    protected abstract LoadStateCore(XElement definition);
}

Dans la première méthode, le consommateur, le code permet de créer et d'initialiser l'objet avec une seule instruction:

//The base class will call the virtual method to load the state.
ChildObject o = new ChildObject(definition)

Dans la deuxième méthode, le consommateur devra créer l'objet et à la charge de l'état:

ChildObject o = new ChildObject();
o.LoadState(definition);
  • Pourquoi est-ce dangereux en C#? Vous écrivez que la classe enfant peut ne pas être dans un état valide. Tu veux dire que la classe enfant peut ne pas avoir été initialisé encore?
  • L'enfant de la classe n'EST pas encore initialisé. Classe de Base des constructeurs exécuter avant de enfant de constructeurs de classe. Si l'enfant constructeurs de classe n'est pas anodin, l'état de l'objet sera incohérent.
  • Il n'y a rien de mal avec l'appel de fonction VIRTUELLE dans le constructeur. Plutôt, Ce que vous entendez doit être fonction ABSTRAITE, non? Donc, votre question semble défectueux.
  • Je ne vois pas où est la différence entre virtuel et de méthodes abstraites. Dans les deux cas, elle permet au constructeur de base pour utiliser l'objet enfant dans un état non valide.
  • J'ai écrit au sujet de ce problème ici, avec des captures d'écran et code de.
InformationsquelleAutor Yona | 2009-01-15
  1. 39

    (Cette réponse s'applique à C# et Java. Je crois que C++ fonctionne différemment sur ce sujet).

    L'appel d'une méthode virtuelle dans un constructeur est en effet dangereux, mais parfois, il peut se retrouver avec le plus propre code.

    Je voudrais essayer d'éviter, lorsque cela est possible, mais sans courber le design très. (Par exemple, le "initialiser plus tard" option interdit l'immuabilité.) Si vous ne l'utilisation d'une méthode virtuelle dans le constructeur, document, il très fortement. Tant que tout le monde est conscient de ce qu'il fait, il ne devrait pas provoquer de trop de nombreux problèmes. Je voudrais essayer de limiter la visibilité si, comme vous l'avez fait dans votre premier exemple.

    EDIT: Une chose qui est important ici, c'est qu'il y a une différence entre C# et Java, dans l'ordre de l'initialisation. Si vous avez une classe telle que:

    public class Child : Parent
{
    private int foo = 10;

    protected override void ShowFoo()
    {
        Console.WriteLine(foo);
    }
}

    où la Parent constructeur appelle ShowFoo, en C#, il affiche 10. Le programme équivalent en Java devrait afficher 0.

    • Gardez à l'esprit que FxCop signalons également cela comme un problème, mais Jon points, parfois, il est la meilleure option. C'est l'un de ceux FxCop questions qu'il est important de ne pas ignorer, à moins que vous comprenez pleinement les implications derrière ce qui se passe.
    • D'accord. Il peut être un peu subtile cause de bugs.
    • Downvoters: veuillez ajouter des commentaires si vous pensez que je me trompe! Je veux en savoir trop...
    InformationsquelleAutor Jon Skeet
  2. 10

    En C++, l'appel d'une méthode virtuelle dans une classe de base constructeur de simplement appeler la méthode comme si la classe dérivée n'existe pas encore (car il n'a pas). Cela signifie donc que l'appel est résolu au moment de la compilation pour quelle que soit la méthode, il doit appeler dans la classe de base (ou les classes dérivées à partir de).

    Testé avec GCC, il vous permet d'appeler une fonction virtuelle pure à partir d'un constructeur, mais il donne un avertissement, et les résultats dans un lien à l'erreur. Il semble que ce comportement n'est pas défini par la norme:

    "Fonctions de membre peut être appelé à partir d'un constructeur (ou destructeur) d'une classe abstraite; l'effet de faire un appel virtuel (classe.virtuel) à une fonction virtuelle pure directement ou indirectement à l'objet en cours de création (ou détruit) à partir d'un tel constructeur (ou destructeur) n'est pas défini."

    • pur pur est juste une compilation de contrat, dans la pratique, cela ne change rien au comportement. Seulement le problème, c'est la v-table de pointeur de points à la table de la classe en cours de construction. Donc la base au premier abord. Ce qui signifie que vous obtenir en cours au niveau des fonctions appelées et non dérivé des remplacements. Ce qui est un problème dans la pure et non-pur cas tout de même. Une autre chose est de savoir si votre pur-virtuel n'a pas de définition, alors.. eh bien, il a une définition, un nom par défaut qui imprime "fonction virtuelle pure appelés" et se bloque. c.f. artima.com/cppsource/pure_virtual.html
    InformationsquelleAutor Greg Rogers
  3. 4

    Avec C++ les méthodes virtuelles sont acheminés à travers la vtable pour la classe qui est en cours de construction. Donc dans votre exemple, il serait de générer une méthode virtuelle pure exception puisque tout BaseObject est en cours de construction il n'y a pas LoadStateCore méthode à invoquer.

    Si la fonction n'est pas abstrait, mais ne font rien, alors vous aurez souvent le programmeur se gratter la tête en essayant de se rappeler pourquoi il est que la fonction n'est pas appelée.

    Pour cette raison que vous simplement ne pouvez pas le faire de cette façon en C++ ...

    • En d'autres termes, ce n'est pas vraiment acheminé à travers la vtable à tous. Il est appelé comme s'il n'était qu'un banal non-méthode virtuelle.
    • Pas de. Il est toued par le biais de la v-table et échoue. Elle n'appellera PAS les attendus de la méthode.
    • Il est défini et, par conséquent, vous ne pouvez pas argumenter, de toute façon. L'appel de pure virtuals peut invoquer nasale démons, pour tous C++ soucis.
    • Oui, mais l'appel d'une méthode virtuelle (pas une méthode virtuelle pure) est parfaitement bien définis, et c'est ce que la question était de savoir.
    • Ah, je vois. Ce que j'ai oublié c'était le cas de la fonction virtuelle appelée indirectement, par l'intermédiaire d'un autre membre de la fonction: Si le constructeur est toujours en cours d'exécution, la classe actuelle de la méthode est appelée, pas la version d'origine. Lorsqu'il est appelé directement au constructeur, c'est le même effet qu'un non-appel virtuel.
    InformationsquelleAutor Rob Walker
  4. 4

    Pour le C++, le constructeur de base est appelée avant que la dérivée constructeur, ce qui signifie que la table virtuelle qui contient les adresses de la classe dérivée est substituée fonctions virtuelles) n'existe pas encore. Pour cette raison, il est considéré comme une chose TRÈS dangereuse à faire (surtout si les fonctions sont virtuelle pure dans la classe de base...ce sera la cause d'une pure virtuel exception).

    Il y a deux façons de contourner cela:

    1. Faire un processus en deux étapes de la construction + initialisation
    2. Déplacer les fonctions virtuelles pour une classe interne qui vous permet de mieux contrôler (pouvez utiliser l'approche décrite ci-dessus, voir l'exemple pour plus de détails)

    Un exemple de (1) est:

    class base
{
public:
    base()
    {
      //only initialize base's members
    }

    virtual ~base()
    {
      //only release base's members
    }

    virtual bool initialize(/* whatever goes here */) = 0;
};

class derived : public base
{
public:
    derived ()
    {
      //only initialize derived 's members
    }

    virtual ~derived ()
    {
      //only release derived 's members
    }

    virtual bool initialize(/* whatever goes here */)
    {
      //do your further initialization here
      //return success/failure
    }
};

    Un exemple de (2) est:

    class accessible
{
private:
    class accessible_impl
    {
    protected:
        accessible_impl()
        {
          //only initialize accessible_impl's members
        }

    public:
        static accessible_impl* create_impl(/* params for this factory func */);

        virtual ~accessible_impl()
        {
          //only release accessible_impl's members
        }

        virtual bool initialize(/* whatever goes here */) = 0;
    };

    accessible_impl* m_impl;

public:
    accessible()
    {
        m_impl = accessible_impl::create_impl(/* params to determine the exact type needed */);

        if (m_impl)
        {
            m_impl->initialize(/* ... */);  //add any initialization checking you need
        }
    }

    virtual ~accessible()
    {
        if (m_impl)
        {
            delete m_impl;
        }
    }

    /* Other functionality of accessible, which may or may not use the impl class */
};

    Approche (2) utilise le modèle de Fabrique de la mise en œuvre de la accessible classe (qui fourniront la même interface que vos base classe). L'un des principaux avantages est que vous obtenez de l'initialisation lors de la construction de accessible qui est en mesure de faire usage de membres virtuels de accessible_impl en toute sécurité.

    • Votre suggestion est correct, mais pas l'explication. la v-table N'existe pas, et il points de fonctions de base. la v-table de pointeur est mis à jour en tant que constructeur de la hiérarchie est déroulé.
    InformationsquelleAutor Brian
  5. 3

    Pour le C++, l'article 12.7, paragraphe 3 de la Norme couvre ce cas.

    Pour résumer, c'est légal. Il permettra de résoudre à la bonne fonction du type de constructeur en cours d'exécution. Par conséquent, l'adaptation de votre exemple de syntaxe C++, vous auriez du appeler BaseObject::LoadState(). Vous ne pouvez pas obtenir à ChildObject::LoadState(), et d'essayer de le faire en spécifiant la classe ainsi que les résultats de la fonction de comportement indéfini.

    Les constructeurs de classes abstraites sont couverts dans la section 10.4, paragraphe 6. En bref, ils peuvent appeler des fonctions de membre, mais l'appel d'une fonction virtuelle pure dans le constructeur est un comportement indéfini. Ne pas le faire.

    InformationsquelleAutor David Thornley
  6. 3

    Si vous avez une classe comme indiqué dans votre post, qui prend un XElement dans le constructeur, la seule place qui XElement pouvait venir est la classe dérivée. Alors pourquoi ne pas charger l'état dans la classe dérivée qui a déjà les XElement.

    Soit votre exemple manque certaines informations fondamentales qui change la situation, ou il n'y a pas besoin de dos de la chaîne jusqu'à la classe dérivée avec les informations de la classe de base, parce qu'il vient de vous dire que des informations exactes.

    c'est à dire

    public class BaseClass
{
    public BaseClass(XElement defintion)
    {
        //base class loads state here
    }
}

public class DerivedClass : BaseClass
{
    public DerivedClass (XElement defintion)
        : base(definition)
    {
        //derived class loads state here
    }
}

    Puis votre code est très simple, et vous n'avez pas du virtuel appel de la méthode des problèmes.

    InformationsquelleAutor Greg Beech
  7. 3

    Pour le C++, lire Scott Meyer article correspondant :

    Ne jamais Appeler des Fonctions Virtuelles en cours de Construction ou de Destruction

    ps: attention à cette exception dans l'article:

    Le problème serait presque certainement
    devenir apparente avant l'exécution,
    parce que le logTransaction fonction est
    virtuelle pure dans la Transaction. À moins qu'il
    avait été défini (peu probable, mais
    possible) le programme n'aurait pas un lien: l'éditeur de liens serait incapable de trouver le nécessaire de mise en œuvre de la Transaction::logTransaction.

    InformationsquelleAutor Özgür
  8. 1

    Habituellement, vous pouvez obtenir autour de ces questions en ayant une plus gourmand constructeur de base. Dans votre exemple, vous êtes en passant un XElement à LoadState. Si vous permettre à l'etat d'être directement défini dans votre constructeur de base, puis votre enfant de la classe peut analyser la XElement avant de faire appel à votre constructeur.

    public abstract class BaseObject {
   public BaseObject(int state1, string state2, /* blah, blah */) {
      this.State1 = state1;
      this.State2 = state2;
      /* blah, blah */
   }
}

public class ChildObject : BaseObject {
   public ChildObject(XElement definition) : 
      base(int.Parse(definition["state1"]), definition["state2"], /* blah, blah */) {
   }
}

    Si l'enfant les besoins de la classe pour faire un bon peu de travail, il peut se défausser d'une méthode statique.

    InformationsquelleAutor Mark Brackett
  9. 1

    En C++, il est parfaitement possible d'appeler des fonctions virtuelles à partir de l'intérieur de la classe de base - aussi longtemps qu'ils sont non-pur - avec quelques restrictions. Cependant, vous ne devriez pas le faire. Mieux initialiser des objets à l'aide de non-fonctions virtuelles, qui sont explicitement marquées comme étant l'initialisation des fonctions à l'aide des commentaires et un nom approprié (comme initialize). Si c'est le même déclaré que pure virtual dans la classe de l'appelant, le comportement est indéfini.

    La version qui est appelé est celui de la classe de l'appeler à partir de l'intérieur du constructeur, et non pas quelque overrider dans certains de la classe dérivée. Cela n'a pas beaucoup à faire avec virtual tables de fonction, mais plus avec le fait que le remplacement de cette fonction pourrait appartenir à une classe qui n'est pas encore initialisé. C'est donc interdite.

    En C# et Java, qui n'est pas un problème, car il n'y a pas une telle chose comme un défaut d'initialisation qui est fait juste avant d'entrer dans le corps du constructeur. En C#, les seules choses que l'on fait à l'extérieur du corps est l'appel de la classe de base ou de la fratrie des constructeurs, je crois. En C++, cependant, les initialisations fait pour les membres des classes dérivées par l'overrider de cette fonction serait annulée lors de la construction de ces membres lors du traitement du constructeur d'initialiseur de liste juste avant d'entrer dans les constructeurs de corps de la classe dérivée.

    Modifier: en Raison d'un commentaire, je pense qu'un peu de clarification est nécessaire. Voici un (fictive) par exemple, supposons qu'il serait autorisé à appeler virtuals, et l'appel seraient le résultat d'une activation de la finale overrider:

    struct base {
    base() { init(); }
    virtual void init() = 0;
};

struct derived : base {
    derived() {
        //we would expect str to be "called it", but actually the
        //default constructor of it initialized it to an empty string
    }
    virtual void init() {
        //note, str not yet constructed, but we can't know this, because
        //we could have called from derived's constructors body too
        str = "called it";
    }
private:
    string str;
};

    Que le problème peut en effet être résolu en changeant la Norme C++ et le laisser - réglage de la définition de constructeurs, durée de vie des objets et autres joyeusetés. Les règles devraient être faits pour définir ce str = ...; signifie pour un qui n'est pas encore construit de l'objet. Et de noter comment l'effet de celle-ci dépend alors de qui a appelé init. La fonction que nous obtenir ne justifie pas les problèmes que nous avons à résoudre ensuite. Donc, C++ simplement interdit la distribution dynamique tandis que l'objet est en cours de construction.

    • Votre dernier paragraphe est incorrecte. Toutes les initialiseurs (initialisation définies à l'extérieur du corps du constructeur) est exécuté dans l'ordre de la plupart des dérivés de moins dérivées, et puis par la suite le constructeur de corps sont exécutées dans l'ordre de moins dérivées pour la plupart des dérivés.
    • heureusement, j'ai expliqué la chose de l'ordre dans une autre réponse: stackoverflow.com/questions/375141/... 🙂
    • donc, même si votre commentaire est en partie droite, il est incomplet. en raison de l'initialiseur listes interleave. données-membres d'une part, et de la classe de base des sous-objets de l'autre côté. la base-classes sont initialisés dans l'ordre, de dérivés à la base, mais les données membres sont initialisés dans l'ordre à partir de la base de dérivé.
    InformationsquelleAutor Johannes Schaub - litb