Prévenir l'héritage de classe en C++

Récemment, un de mes ami m'a demandé comment faire pour empêcher l'héritage de classe en C++. Il voulait la compilation échoue.

Je pensais à elle et a trouvé 3 réponses. Vous ne savez pas lequel est le meilleur.

1) Constructeur(s)

class CBase
{

public:

 static CBase* CreateInstance() 
 { 
  CBase* b1 = new CBase();
  return b1;
 }

private:

 CBase() { }
 CBase(CBase3) { }
 CBase& operator=(CBase&) { }


};

2) à l'Aide de CSealed de la classe de base, privé ctor & héritage virtuel

class CSealed
{

private:

 CSealed() {
 }

 friend class CBase;
};


class CBase : virtual CSealed
{

public:

 CBase() {
 }

};

3) à l'Aide d'un CSealed de la classe de base, protégé ctor & héritage virtuel 

class CSealed
{

protected:

 CSealed() {
 }

};

class CBase : virtual CSealed
{

public:

 CBase() {
 }

};

Toutes les méthodes ci-dessus, assurez-vous que CBase classe ne peut pas être héritée plus loin.
Ma Question est:

1) Qui est la meilleure méthode ? Toutes les autres méthodes disponibles ?

2) Méthode 2 & 3 ne fonctionnera pas à moins que le CSealed classe est héritée virutally. Pourquoi est-ce ? A-t-elle quelque chose à voir avec vdisp ptr ??

PS:

Le programme ci-dessus a été compilé dans MS compilateur C++ (Visual Studio).
référence : http://www.codeguru.com/forum/archive/index.php/t-321146.html

InformationsquelleAutor ring0 | 2010-02-02
  1. 69

    Comme du C++11, vous pouvez ajouter le mot-clé final de votre classe, par exemple,

    class CBase final
{
...

    La principale raison que je vois pour vouloir le faire (et la raison pour laquelle je suis à la recherche pour cette question) est à marquer d'une classe non subclassable de sorte que vous pouvez utiliser en toute sécurité un non-destructeur virtuel et d'éviter une vtable tout à fait.

    • Il existe une autre bonne raison et c'est la prévention des classes dérivées pour rompre le contrat de l'immuable classes.
    • Borique qui s'appliquerait à toute la sous-classe et de tout contrat, et pas seulement de la mutabilité. Toute sous-classe peut potentiellement briser toutes les garanties des contrats de la classe - qui n'est pas vraiment une bonne raison pour réfuter toutes les sous-classes. Pour un objet immuable, si vous souhaitez ajouter une valeur dérivée, par exemple FullName() à partir de Prenom() et Nom() les méthodes, ou peut-être un spécifique de la fonction de hachage.
    InformationsquelleAutor Peter N Lewis
  2. 11

    Vous ne pouvez pas empêcher l'héritage (avant C++11 est final mot-clé) - vous ne pouvez vous empêcher l'instanciation de classes héritées. En d'autres termes, il n'y a aucun moyen de prévenir:

    class A { ... };

class B : public A { ... };

    Le meilleur que vous pouvez faire est d'empêcher les objets de type B d'être instanciée. Cela étant le cas, je vous suggère de prendre kts, les conseils et le document le fait qu'Un (ou autre) n'est pas destiné à être utilisé pour l'héritage, de lui donner un non-destructeur virtuel, et pas d'autres fonctions virtuelles, et d'en rester là.

    • +1: Vous ne pouvez pas empêcher quelqu'un de choisir d'utiliser l'héritage de plus de composotion, même si nous (et le reste de l'univers) ne sont pas d'accord. Document
    • Notez qu'en C++11, vous pouvez facilement empêcher l'héritage.
    InformationsquelleAutor
  3. 10

    Vous allez par le biais de contorsions pour prévenir d'autres sous-classement. Pourquoi? Document le fait que la classe n'est pas extensible et faire la dtor non-virtuel. Dans l'esprit de c, si quelqu'un veut vraiment ignorer la façon dont vous l'intention de ce à être utilisé pourquoi arrêter? (Je n'ai jamais vu le point de final classes/méthodes en java soit).

    //Note: this class is not designed to be extended. (Hence the non-virtual dtor)
struct DontExtened
{
  DontExtened();
  /*NOT VIRTUAL*/
  ~DontExtened();
  ...
};
    • Je pense que le point en Java, c'est que le compilateur JIT peut optimiser les appels de méthodes virtuelles si la classe est définitive
    • Je comprends la jvm peut l'aimer, mais il devrait y avoir un moyen facile d'annuler ce w/o modification de la source. @ReallyOverride?
    • C'est se laisser distraire un peu. En Java, le final mot a un sens, car toutes les fonctions sont virtuel par défaut, et il y a donc beaucoup à gagner en permettant au compilateur JIT pour réaliser ces optimisations. En C++, il n'y aurait rien à gagner d'un mécanisme similaire pour éviter de sous-classement, c'est pourquoi la langue n'a pas de fournir une mecehanism pour le faire.
    • La santé mentale ftw. Laissez les gens se tirer dans le pied si ils le veulent.
    • -1: de Telles contorsions sont pour les accidents. Aussi, cela ne permet pas de répondre à l'OP de la question (même si c' peut (pas) être un X-Y de problème). Votre réponse est équivalent à rendre le tout publique et de documenter tous logiquement privé de l'élément en tant que tel. Ma règle est de laisser le compilateur vous aider à ne pas faire d'erreurs lorsque cela est possible.
    • Eh bien, vous pouvez penser que, mais vous êtes tout à fait tort. C'est le idiomatiques façon en c++ 2011. Ma règle est d'écrire du code qui peut être attendu d'être bien compris par l'ensemble de la communauté des programmeurs pour une langue. Aussi, si votre compilateur ne pas vous avertir sur les hériter d'une classe avec un non-virtuel dtor, vous avez besoin d'un nouveau.
    • Je pensais que C++11 a final dans ce but. Donc je m'attends à ce que ce soit le idiomatiques façon de le faire en C++11. Pourquoi utiliser les commentaires quand vous avez une fonctionnalité du langage pour faire exactement ce que les commentaires d'essayer (mais ne parviennent pas) pour faire respecter?
    • Je suis d'accord avec @ThomasEding la final identificateur, est la meilleure option. Il permet au compilateur de vous aider, et des documents très justement que cette classe n'est pas prévu pour l'héritage. Si vous choisissez de prendre le chemin de commentaires, alors vous avez le programmeur de regarder jusqu'à la source, et d'interpréter le commentaire. Qui peut être sur plusieurs lignes, peut-être même au sein d'un gros bloc de commentaire. En utilisant final l'IDE peut aider à leur première tentative pour hériter de la classe. Outre l'utilisation de final le développeur sait où regarder, même si il/elle n'est pas utilisée pour le style de programmation utilisé.
    • Cette réponse a d'autres problèmes en plus, y compris qui dérivent d'une classe dérivée, avec un destructeur virtuel; et légitime de non-virtuel-classement (prendre std::unary_function par exemple). stackoverflow.com/questions/7403883/...
    • -1. Mon compilateur n'a pas de lire la documentation, et parfois, certains de mes collègues ne savent pas non plus. La qualité de l'entreprise logiciels sous-traite les contraintes du code.
    • La raison pour laquelle je suis en utilisant final sur mon struct est parce que je l'utilise, en valeur, dans un std::vector. Si quelqu'un s'étend et devient l'un dans l' std::vector, c'est vraiment mal.

    InformationsquelleAutor KitsuneYMG
  4. 5

    1) est une question de goût. Si je vois bien, votre plus de fantaisie 2e et 3e solutions de déplacer l'erreur, dans certaines circonstances, de lien fois au moment de la compilation, qui, en général, devrait être mieux.

    2) l'héritage Virtuel est nécessaire pour forcer la responsabilité pour initialiser le (virtuel) de la classe de base pour la plupart de la classe dérivée d'où la classe de base ctor n'est plus accessible.

    InformationsquelleAutor
  5. 4

    Pour répondre à votre question, vous ne pouvez pas hériter de CBase parce que dans l'héritage virtuel une classe dérivée aurait besoin d'avoir un accès direct à la classe à partir de laquelle il a été hérité pratiquement. Dans ce cas, une classe qui découleraient de CBase aurait besoin d'avoir un accès direct à CSealed qui il ne peut pas puisque le constructeur est privé.

    Bien que je ne vois pas l'utilité de tout cela (c'est à dire: arrêt de l'héritage) vous pouvez généraliser l'utilisation des modèles (je ne pense pas qu'il compile sur tous les compilateurs, mais il le fait avec MSVC)

    template<class T>
class CSealed
{
    friend T;    //Don't do friend class T because it won't compile
    CSealed() {}
};

class CBase : private virtual CSealed<CBase>
{
};
    • Il a de la classe CBase : privé virtuel CSealed<CBase>. Sinon, CBase peut être dérivée.
    InformationsquelleAutor Francis Boivin
  6. 1

    Si vous le pouvez, j'irais pour la première option (constructeur privé). La raison en est que à peu près tout connu programmeur C++ verrez que d'un coup d'oeil et être en mesure de reconnaître que vous essayez d'éviter de sous-classement.

    Il y a peut être d'autres plus délicat des méthodes pour prévenir la sous-classement, mais dans ce cas, le plus simple sera le mieux.

    InformationsquelleAutor T.E.D.
  7. 0
    class myclass;

    class my_lock {
        friend class myclass;
    private:
        my_lock() {}
        my_lock(const my_lock&) {}
    };

    class myclass : public virtual my_lock {
        //...
    public:
        myclass();
        myclass(char*);
        //...
    };

    myclass m;

    class Der : public myclass { };

    Der dd;  //error Der::dd() cannot access
            //my_lock::my_lock(): private  member

    Je l'ai trouvé ici pour donner du crédit. Je suis de poster ici juste d'autres personnes peuvent facilement accéder à
    http://www.devx.com/tips/Tip/38482

    InformationsquelleAutor Vijay
  8. 0

    D'élaborer sur La réponse de françois: si la classe Bottom dérive de la classe Middle, qui a pratiquement hérite de la classe Top, c'est que la plupart de la classe dérivée (Bottom) qui est responsable de la construction de la quasi hérité de la classe de base (Top). Sinon, dans le multi-héritage/diamond-de-mort scénario (où l'héritage virtuel est classiquement utilisé), le compilateur ne sais pas lequel des deux "middle classes" doit construire une seule classe de base. Le Middle's du constructeur appel à la Tops'constructeur est donc ignorée lorsque Middle est construit à partir de Bottom:

    class Top {
    public:
        Top() {}
}

class Middle: virtual public Top {
    public:
        Middle(): Top() {} //Top() is ignored if Middle constructed through Bottom()
}

class Bottom: public Middle {
    public:
        Bottom(): Middle(), Top() {}
}

    Ainsi, dans l'approche 2) ou 3) dans votre question, Bottom() ne peux pas appeler Top() parce que c'est héréditaire en privé (par défaut, comme dans le code, mais il vaut la peine de rendre explicite) dans Middle et n'est donc pas visible dans Bottom. (source)

    InformationsquelleAutor Blazej Czapp
  9. -1

    La solution:

    template < class T >
class SealedBase
{
protected:
    SealedBase()
    {
    }
};

#define Sealed(_CLASS_NAME_) private virtual SealedBase<_CLASS_NAME_>


#include "Sealed.h"

class SomeClass : Sealed(Penguin)
{
};
    • L'ajout d'une macro pour le mix n'est pas de faire de cette nouvelle solution.
    InformationsquelleAutor Sergey Teplyakov