Comment déclarer une interface en C++?

Comment puis-je configurer une classe qui représente une interface? Est-ce juste une classe de base abstraite?

InformationsquelleAutor Aaron Fischer | 2008-11-25
  1. 670

    Pour étoffer la réponse par bradtgmurray, vous pouvez faire une exception à la méthode virtuelle pure liste de votre interface en ajoutant un destructeur virtuel. Cela vous permet de passer le pointeur de la propriété à une autre partie sans exposer le béton de la classe dérivée. Le destructeur n'a pas à faire quoi que ce soit, parce que l'interface n'ont pas de structures en béton. Il peut sembler contradictoire de définir une fonction à la fois virtuel et en ligne, mais croyez-moi - il n'est pas.

    class IDemo
{
    public:
        virtual ~IDemo() {}
        virtual void OverrideMe() = 0;
};

class Parent
{
    public:
        virtual ~Parent();
};

class Child : public Parent, public IDemo
{
    public:
        virtual void OverrideMe()
        {
            //do stuff
        }
};

    Vous n'avez pas à inclure un corps pour le destructeur virtuel -, il s'avère que certains compilateurs ont de la difficulté de l'optimisation d'un vide destructeur et il est préférable d'utiliser la valeur par défaut.

    • Virtuel desctuctor++! C'est très important. Vous pouvez également inclure virtuelles pures déclarations de l'opérateur= et constructeur de copie définitions pour empêcher le compilateur de l'auto-génération de ceux pour vous.
    • Une alternative à un destructeur virtuel est un protégé de destructeur. Cela désactive polymorphe de la destruction, qui peut être plus appropriée dans certaines circonstances. Recherchez "la ligne Directrice n ° 4" dans le gotw.ca/publications/mill18.htm.
    • Si vous savez que vous n'allez pas supprimer la classe par le biais d'une classe de base, vous n'avez pas besoin de le destructeur virtuel. Cependant, il n'est jamais vraiment nocif pour faire le destructeur virtuel de toute façon (sauf pour une vtable de recherche, oh non!).
    • Une autre option est de définir une virtuelle pure (=0) destructeur avec un corps. L'avantage ici est que le compilateur peut, théoriquement, de voir que vtable n'a pas de membres valides maintenant, et l'écarter complètement. Avec un destructeur virtuel avec un corps, dit destructeur peut être appelé (virtuellement) par exemple, dans le milieu de la construction par this pointeur (lorsque l'objet construit est toujours de Parent type), et donc que le compilateur doit fournir une preuve de vtable. Donc, si vous n'avez pas explicitement appeler les destructeurs virtuels via this au cours de la construction 🙂 vous pouvez enregistrer de la taille du code.
    • Quarante lunes auparavant, mais de toute façon - @Mark Rançon, vous avez écrit: "Cela vous permet de passer le pointeur de la propriété à une autre partie sans s'exposer à la classe de base." Vouliez-vous dire "sous-classe"? Parce qu'alors, dans votre commentaire vous avez écrit: "Si vous savez que vous n'allez pas supprimer la classe par le biais d'une classe de base, vous n'avez pas besoin de le destructeur virtuel." - Désolé si ma remarque n'a pas de sens - je suis un C++ noob et essayer d'apprendre à partir de ces questions et de réponses.
    • maintenant que j'y pense, vous avez tout à fait raison. L'interface est une classe de base, comme le béton de classe dérive de la et met en œuvre les méthodes. Je dois résoudre ce problème. Donnez-vous une étoile d'or pour être la première à le remarquer, je suis sûr que cette réponse a été visionnée des milliers de fois.
    • merci pour le virtuel étoile d'or. 🙂 En attendant, j'ai compris que vous devez dire ce que je pensais vous avait voulu parce que j'ai eu au bas de la page où Carlos réponse en fait le point de clair avec un exemple de code. Merci pour vos commentaires, après une longue période! -- Meilleur, Michael
    • un destructeur virtuel avec un corps, dit destructeur peut être appelé (virtuellement) par exemple, dans le milieu de la construction", sérieusement?
    • oui, vous pouvez appeler un destructeur dans le milieu de la construction, lorsque vous throw du constructeur d'une classe dérivée.
    • Mais presque?!!
    • Envisager une hiérarchie d'héritage: Base <- Derived <- MostDerived. Vous êtes dans la Dérivée ctor. Vous appelez une fonction globale, qui prend un Base* argument, en passant il this. Cette fonction peut appeler explicitement le destructeur via le pointeur, et il doit être distribué pratiquement.
    • ne serait-il pas UB pour détruire un objet explicitement avant qu'il soit achevé la construction d'? Je peux voir le MostDerived constructeur à être très malheureux. Au moins avec les détruire via throw le reste de la construction est court-circuité.
    • Il serait certainement UB par le temps qu'il arrive à la ctor de MostDerived, mais je ne vois pas ce qui ferait par exemple this->~Foo() dans un ctor UB tous par lui-même. Considérons le cas où vous détruire, et de ne jamais revenir à la ctor (par exemple, juste assis là dans une boucle infinie, de prise et de traitement de l'input). À l'intérieur de cette boucle, votre comportement serait bien définis, autant que je peux voir.
    • Comment typiques d'un C++ réponse que le sommet de la réponse n'a pas directement répondu à la question (même si évidemment le code est parfait), au lieu de cela, il optimise la réponse la plus simple.
    • N'oubliez pas qu'en C++11, vous pouvez spécifier le override mot-clé pour permettre la compilation de l'argument et la valeur de retour de vérification de type. Par exemple, dans la déclaration de l'Enfant virtual void OverrideMe() override;
    • cette réponse est antérieure à C++11 par quelques années, mais vous faites un bon point de grâce!
    • Je suis d'accord avec @PavelMinaev, il y a peu, voire aucune raison pour que le destructeur de la non-virtuelle pure.
    • Notez aussi que GCC ne peut pas gérer les pur-virtuel destructeurs et vous avez besoin de les définir: stackoverflow.com/a/3065223/447490
    • Je suis un peu confus maintenant en ce qui concerne la Marque de Rançons note sur l'optimisation du compilateur et de ton commentaire. Sonne comme l'ancien suggère d'utiliser virtuelle pure destructeurs tandis que le second l'interdit. Fait que j'ai mal compris quelque chose? Si non, est-il une solution générale pour cela ou est-ce compilateur à charge?
    • Non, vous comprenez tout à fait raison. Marque Rançon suggère de ne pas définir le destructeur virtuel alors que GCC vous oblige à le faire. Je ne pense pas vraiment qu'il existe une solution autre que de l'encombrement de votre code avec #ifdef et le compilateur vérifie mais dans ce cas je préfère juste aller avec la définition et peut-être de perdre certains avantages de l'optimisation sur certains compilateurs.
    • Pouvez-vous nous expliquer le raisonnement derrière le désir de prendre la cession de l'opérateur et le constructeur de copie virtuelle pure dans le IDemo classe.
    • une interface doit être un très petit sous-ensemble de la classe qui fait implémente l'interface; en particulier, il n'aura pas toutes les données membres. Qui garantit presque que l'généré par le compilateur de la copie et de l'affectation des opérateurs va faire la mauvaise chose. Si vous voulez les mettre en œuvre vous-même, faites-vous plaisir, mais il n'est généralement pas nécessaire - vous avez accès à une interface via un pointeur, et des copies du pointeur sont OK aussi longtemps que vous avez manipulé la propriété.
    • Ce MarkRansom dit. Si vous êtes à la déclaration d'une interface de cette façon, il est très improbable que le compilateur est générée automatiquement les tentatives de ces serait correct. Ainsi, il est plus prudent de déclarer explicitement eux virtuelle pure vous-même et assurez-vous que vous ne pouvez pas accidentelle tomber dans le piège de les utiliser.
    • Maintenant, je comprends le raisonnement, mais j'ai encore 2 questions que je ne comprends pas. Le premier est le compilateur de créer automatiquement la cession et le constructeur de copie pour toujours la classe, même si vous n'avez jamais utiliser dans votre code. Deuxièmement, pouvez-vous accidentellement déclencher, soit de la cession ou de constructeur de copie lorsque l'objet est un pointeur?
    • leur présence ou leur absence n'est pas détectable à moins que vous les appelez, donc par le "comme-si" la règle, il pourrait aller de toute façon - je soupçonne la plupart des compilateurs ne pas. Vous pouvez générer un appel avec, par exemple, *a = *b mais je vous l'accorde il n'est pas commun.
    • Aussi, il a tout simplement daoesn pas vraiment d'importance, comme assinging / copie de l'interface n'est pas ne n'importe quoi.
    • À l'intérieur de Child , est-il encore nécessaire d'écrire OverrideMe() comme virtual void ?
    • n'est pas nécessaire puisque la base de la déclaration de classe déjà fait virtuel, mais c'est une bonne pratique pour être cohérent. void est toujours nécessaire.
    • Il serait bien si vous mentionnez que le destructeur peut être fait de la pure virtuel si aucune autre fonction n'est disponible.
    • Ce qu'il faut faire avec l'avertissement que IDemo "n'a pas de hors-ligne virtuel définitions de méthode"?

    InformationsquelleAutor Mark Ransom
  2. 236

    Faire une classe avec des méthodes virtuelles pures. Utilisation de l'interface par la création d'une autre classe qui remplace ces méthodes virtuelles.

    Une méthode virtuelle pure est une méthode de classe est défini comme virtuel et affecté à 0.

    class IDemo
{
    public:
        virtual ~IDemo() {}
        virtual void OverrideMe() = 0;
};

class Child : public IDemo
{
    public:
        virtual void OverrideMe()
        {
            //do stuff
        }
};
    • vous devriez avoir une faire rien de destructeur dans IDemo de sorte qu'il est défini comportement à faire: IDemo *p = new Enfant; /*ce */ delete p;
    • Pourquoi le OverrideMe méthode dans la classe Enfant est virtuel ? Est-ce nécessaire ?
    • non, il n'est pas nécessaire, mais il ne fait pas de mal non plus.
    • Il est généralement une bonne idée de garder le mot "virtuel" à chaque fois que remplacement d'une méthode virtuelle. Bien que non obligatoire, il peut rendre le code plus clair, sinon, vous n'avez aucune indication que cette méthode pourrait être utilisée polymorphically, ou même qu'il existe dans la classe de base.
    • Sauf avec override en C++11
    • N'oubliez pas le point-virgule à la fin de la classe de déclarations.
    • Il n'est pas nécessaire de déclarer Child::OverrideMe() comme virtual, @Cemre, parce que IDemo::OverrideMe() fait Child::OverrideMe() implicitement virtual. Avoir une indication que c'est une fonction virtuelle (comme virtual, ou mieux encore, override en C++11 ou une version ultérieure) servira comme un rappel pour les programmeurs, avec override en particulier aussi aider le compilateur de vérifier qu'il ne fait écraser quelque chose.

    InformationsquelleAutor bradtgmurray
  3. 145

    La raison pour laquelle vous disposez d'une Interface spéciale de type catégorie en plus des classes de base abstraites en C#/Java est parce que C#/Java ne supporte pas l'héritage multiple.

    C++ supporte l'héritage multiple, et donc un type spécial n'est pas nécessaire. Une classe de base abstraite avec des non-abstrait (virtuelle pure) méthodes est fonctionnellement équivalent à un C#/Java de l'interface.

    • Il serait agréable d'être en mesure de créer des interfaces, pour nous sauver de taper beaucoup (virtuel , =0, destructeur virtuel). Aussi l'héritage multiple semble être une très mauvaise idée pour moi et je ne l'ai jamais vu utilisé dans la pratique, mais les interfaces sont nécessaires tout le temps. À mal le C++ la courtoisie de ne pas introduire des interfaces juste parce que je les veux.
    • Ha11owed: Elle possède des interfaces. On les appelle des classes avec des méthodes virtuelles pures et aucune méthode mise en œuvre.
    • Il y a quelques bizarreries dans Java causée par l'absence d'héritage multiple. Jetez un oeil à java.lang.Thread classe et java.lang.Runnable de l'interface, qui n'existe tout simplement parce que vous ne pouvez pas étendre Thread avec une autre base. De la documentation, il peut sembler qu'il est fourni pour votre choix, mais une fois j'ai été forcé d'utiliser Runnable en raison de l'absence d'héritage multiple.
    • Je sais, mais quand même, pourquoi me forcer à écrire autant de code réutilisable? Aussi, il serait clair que vous êtes à la recherche à une interface sans avoir à balayer toutes les méthodes et vérifier qu'ils sont tous virtuelle pure.
    • java.lang.Thread a des méthodes et des constantes que vous ne voulez probablement pas à avoir dans votre objet. Quel doit être le compilateur faire si vous étendre à partir du Fil, et une autre classe avec la méthode publique checkAccess()? Souhaitez-vous vraiment préfèrent utiliser nommé fortement de la base de pointeurs comme en C++? Cela semble être une mauvaise conception, vous devez normalement composition où vous pensez que vous avez besoin de l'héritage multiple.
    • c'était il y a longtemps donc je ne me souviens pas des détails, mais il avait des méthodes et des contants que je voulais avoir dans ma classe, et surtout, je voulais que mon objet de classe dérivée pour être un Thread instance. L'héritage Multiple peut être une mauvaise conception ainsi que la composition. Tout dépend des cas.
    • pour "vous devez normalement composition où vous pensez que vous avez besoin de l'héritage multiple"
    • Il n'y a pas de abstract mot-clé en C++.
    • "La raison pour laquelle vous disposez d'une Interface spéciale de type catégorie en plus des classes de base abstraites en C#/Java est parce que C#/Java ne supporte pas l'héritage multiple." - L'affirmation que c'est la raison qui est complètement faux. Existe des Interfaces en Java afin de ne pas confondre les concepts de conformation à un contrat et une mise en œuvre partagée. C'est une idée fausse très répandue parmi les développeurs C++ tenter de dénigrer ce qui est sans doute une conception plus cohérente avec pure langages à objets.
    • Objective-C prend également en charge ce à travers des Protocoles et va une étape plus loin (point de prêter à confusion au début), par mode de Protocole de mise en œuvre facultative. Ce programme a permis d'Objective-C avec beaucoup de ce que le C++ va bientôt obtenir via Concepts.
    • Vraiment? Objective-C est au moment de la compilation de l'évaluation, et des modèles?
    • Je fais référence à la propriété de la clé de concepts qu'ils permettent à un destinataire de l'appel (dans votre cas, un modèle), de spécifier des contraintes sur l'API qu'un argument doit/devrait soutenir lorsque ces contraintes sont exprimées dans la déclaration ou de la définition de l'appelant, plutôt que dans la hiérarchie de classe de l'argument. Pas d'Objective-C n'ont pas de modèles. Modèles dans cette discussion sont les choses étant améliorée par un "concept" qui ressemble à certains égards à Objective-C de protocoles. Mais je suis sûr que vous le saviez déjà.
    • puis donner un exemple de ce que vous appelez l'héritage multiple, becos jusqu'à présent, il semble que java peut le faire, mais pas du c++, java peut implment interface
    • c++ directement peut hériter de plusieurs classes. java ne peut directement hériter d'une classe.

    InformationsquelleAutor Joel Coehoorn
  4. 50

    Il n'y a pas de notion de "interface" en soi en C++. Autant que je sache, les interfaces ont été introduites dans Java pour contourner l'absence d'héritage multiple. Ce concept s'est avéré être tout à fait utile, et le même effet peut être obtenu en C++ en utilisant une classe de base abstraite.

    Une classe de base abstraite est une classe dans laquelle au moins l'un des membres de la fonction (méthode en Java le jargon) est une fonction virtuelle pure déclarées à l'aide de la syntaxe suivante:

    class A
{
  virtual void foo() = 0;
};

    Une classe de base abstraite ne peut pas être instanciée, j'. e. vous ne pouvez pas déclarer un objet de la classe A. Vous ne pouvez constituer des classes à partir d'Un, mais de toute classe dérivée qui n'est pas de fournir une implémentation de foo() sera aussi abstrait. Afin de cesser d'être abstraite, une classe dérivée doit fournir des implémentations pour toutes les fonctions virtuelles pures il hérite.

    Noter qu'une classe de base abstraite peut être plus qu'une interface, car il peut contenir des données des membres et des fonctions membres qui ne sont pas du pur virtuel. L'équivalent d'une interface serait une classe de base abstraite, sans données avec seulement des fonctions virtuelles pures.

    Et, en tant que Marque de Rançon a souligné, une classe de base abstraite doit fournir un destructeur virtuel, comme n'importe quelle classe de base, pour cette question.

    • Plus que "l'absence d'héritage multiple" je dirais, pour remplacer l'héritage multiple. Java a été conçu comme ça depuis le début, parce que l'héritage multiple de créer plus de problèmes qu'il en résout. Bonne réponse
    • Oscar, cela dépend si vous êtes un programmeur C++ qui a appris le Java ou vice versa. 🙂 À mon humble avis, si elle est utilisée à bon escient, comme presque rien en C++, l'héritage multiple résout les problèmes. Une "interface" classe de base abstraite est un exemple d'un très judicieuse utilisation de l'héritage multiple.
    • Mal. MI seulement crée des problème lors de l'utilisation abusive. La plupart des problèmes allégués à MI serait également venir avec d'autres plans (sans MI). Quand les gens ont un problème avec leur conception à MI, c'est la faute de MI; s'ils ont un problème de conception de SI, c'est de leur propre faute. "Diamant de la mort" (répété héritage) en est un bel exemple. MI bashing n'est pas de la pure hypocrisie, mais à proximité.
    • Du point de vue sémantique, les interfaces sont différentes de classes abstraites, donc Java les interfaces ne sont pas seulement une technique de contournement. Le choix entre la définition d'une interface ou une classe abstraite est entraînée par la sémantique, pas que des considérations techniques. Imaginons une interface "HasEngine": c'est un aspect, une caractéristique, et peut être appliquée à / mis en œuvre par des types très différents (que ce soit des classes ou des classes abstraites), nous allons donc définir une interface pour que, pas une classe abstraite.
    • vous avez peut-être raison, mais je souhaite que vous pourriez choisir un meilleur exemple. J'aime à penser en termes d'hériter d'une interface vs héritent d'une mise en œuvre. En C++, vous pouvez hériter à la fois de l'interface et la mise en œuvre de concert (public héritage) ou vous pouvez hériter que de la mise en œuvre (privé de l'héritage). En Java, vous avez la possibilité d'hériter juste l'interface, sans une mise en œuvre.
    • Qui le résume assez bien. De manière générale, il est plus difficile d'utiliser l'héritage multiple correctement que c'est à usage unique héritage correctement, mais simplement d'être plus difficile ne veut pas dire que c'est impossible. Un exemple serait quelque chose comme ceci: class Button; class Image; class ClickableIcon : public Button, public Image {}; . S'ils sont correctement conçus, Image offre les fonctionnalités graphiques et Bouton d'alimentation du fonctionnement interactif, sans chevauchement qui pourraient causer des problèmes, tandis que ClickableIcon lui-même gère la fonctionnalité de la touche est pour.
    • ...J'aurais pu le libellé de cet exemple, bien mieux. Button fournit interactive code, Image fournit le code des graphismes, et ClickableIcon fournit un code spécifique à lui-même, ainsi que tout le code nécessaire pour souder les deux classes parents ensemble. Aussi longtemps que les deux classes sont bien conçus, et n'ont pas de chevauchement des noms de membres de la classe devrait être entièrement viable, et plus facile à mettre en œuvre que si l'un des deux était une interface.

    InformationsquelleAutor Dima
  5. 43

    Autant j'ai pu tester, il est très important d'ajouter le destructeur virtuel. Je suis en utilisant les objets créés avec new et détruit avec delete.

    Si vous n'ajoutez pas le destructeur virtuel dans l'interface, puis le destructeur de la classe héritée n'est pas appelé.

    class IBase {
public:
virtual ~IBase() {}; //destructor, use it to call destructor of the inherit classes
virtual void Describe() = 0; //pure virtual method
};
class Tester : public IBase {
public:
Tester(std::string name);
virtual ~Tester();
virtual void Describe();
private:
std::string privatename;
};
Tester::Tester(std::string name) {
std::cout << "Tester constructor" << std::endl;
this->privatename = name;
}
Tester::~Tester() {
std::cout << "Tester destructor" << std::endl;
}
void Tester::Describe() {
std::cout << "I'm Tester [" << this->privatename << "]" << std::endl;
}
void descriptor(IBase * obj) {
obj->Describe();
}
int main(int argc, char** argv) {
std::cout << std::endl << "Tester Testing..." << std::endl;
Tester * obj1 = new Tester("Declared with Tester");
descriptor(obj1);
delete obj1;
std::cout << std::endl << "IBase Testing..." << std::endl;
IBase * obj2 = new Tester("Declared with IBase");
descriptor(obj2);
delete obj2;
//this is a bad usage of the object since it is created with "new" but there are no "delete"
std::cout << std::endl << "Tester not defined..." << std::endl;
descriptor(new Tester("Not defined"));
return 0;
}

    Si vous exécutez le code précédent sans virtual ~IBase() {};, vous verrez que le destructeur Tester::~Tester() n'est jamais appelée.

    • Meilleure réponse sur cette page, car il fait le point par la fourniture d'une pratique, compilable exemple. Cheers!
    • Testet::~Testeur() s'exécute uniquement lorsque l'obj est ", a Déclaré à Tester".
    • En fait, la chaîne privatename du destructeur sera appelé, et dans la mémoire, c'est tout, il sera attribué. Aussi loin que l'exécution, lorsque tout le béton membres d'une classe sont détruits, de sorte que l'instance de classe. J'ai tenté une expérience similaire avec une Ligne de classe, qui avait les deux Point les structures et trouvé à la fois les structures ont été détruites (Ha!) lors d'une suppression, d'appel ou de retour de l'englobant la fonction. valgrind confirmé 0 fuite.
    InformationsquelleAutor Carlos C Soto
  6. 33

    Ma réponse est essentiellement la même que les autres, mais je pense qu'il y a deux autres choses importantes à faire:

    1. Déclarer un destructeur virtuel dans votre interface ou faire un protégé non virtuelle d'éviter l'indéfini comportements si quelqu'un essaie de supprimer un objet de type IDemo.

    2. Utiliser l'héritage virtuel pour éviter les problèmes avec l'héritage multiple. (Il n'y a plus souvent l'héritage multiple lorsque nous utilisons des interfaces.)

    Et comme d'autres réponses:

    • Faire une classe avec des méthodes virtuelles pures.

    • Utilisation de l'interface par la création d'une autre classe qui remplace ces méthodes virtuelles.

      class IDemo
{
public:
virtual void OverrideMe() = 0;
virtual ~IDemo() {}
}

      Ou

      class IDemo
{
public:
virtual void OverrideMe() = 0;
protected:
~IDemo() {}
}

      Et 

      class Child : virtual public IDemo
{
public:
virtual void OverrideMe()
{
//do stuff
}
}
    • +1 pour la mention de l'héritage virtuel.
    • il n'est pas nécessaire pour l'héritage virtuel que vous n'avez pas toutes les données dans une interface.
    • L'héritage virtuel est important pour les méthodes. Sans elle, vous serez confronté à des ambiguïtés avec OverrideMe(), même si l'une des "instances" de la elle est virtuelle pure (juste essayé moi-même).
    • est pas nécessaire pour l'héritage virtuel que vous n'avez pas toutes les données dans une interface." de Mal.
    • Notez que l'héritage virtuel peut ne pas fonctionner sur certaines versions de gcc, comme la version 4.3.3 qui est livré avec WinAVR 2010: gcc.gnu.org/bugzilla/show_bug.cgi?id=35067
    • -1 pour avoir un non-virtuels protégés destructeur, désolé

    InformationsquelleAutor Rexxar
  7. 10

    En C++11, vous pouvez facilement éviter l'héritage tout à fait:

    struct Interface {
explicit Interface(SomeType& other)
: foo([=](){ return other.my_foo(); }), 
bar([=](){ return other.my_bar(); }), /*...*/ {}
explicit Interface(SomeOtherType& other)
: foo([=](){ return other.some_foo(); }), 
bar([=](){ return other.some_bar(); }), /*...*/ {}
//you can add more types here...
//or use a generic constructor:
template<class T>
explicit Interface(T& other)
: foo([=](){ return other.foo(); }), 
bar([=](){ return other.bar(); }), /*...*/ {}
const std::function<void(std::string)> foo;
const std::function<void(std::string)> bar;
//...
};

    Dans ce cas, une Interface de référence sémantique, c'est à dire que vous avez à faire assurez-vous que l'objet survit à l'interface (il est également possible de faire des interfaces avec la valeur sémantique).

    Ce type d'interfaces ont leurs avantages et leurs inconvénients:

    Enfin, l'héritage est la racine de tous les maux dans la conception de logiciels complexes. Dans Sean Parent de la Valeur de la Sémantique et de Concepts basés sur le Polymorphisme (fortement recommandé, les meilleures versions de cette technique y sont expliqués) le cas suivant est étudié:

    Dire que j'ai une application dans laquelle je traite avec mes formes polymorphically à l'aide de la MyShape interface:

    struct MyShape { virtual void my_draw() = 0; };
struct Circle : MyShape { void my_draw() { /* ... */ } };
//more shapes: e.g. triangle

    Dans votre application, vous faites la même chose avec des formes différentes à l'aide de la YourShape interface:

    struct YourShape { virtual void your_draw() = 0; };
struct Square : YourShape { void your_draw() { /* ... */ } };
///some more shapes here...

    Disent maintenant que vous souhaitez utiliser certaines des formes que j'ai développé dans votre application. Sur le plan conceptuel, nos formes ont la même interface, mais pour faire mes formes de travail dans votre application, vous devrez étendre mes formes comme suit:

    struct Circle : MyShape, YourShape { 
void my_draw() { /*stays the same*/ };
void your_draw() { my_draw(); }
};

    Tout d'abord, la modification de mes formes pourrait ne pas être possible à tous. En outre, l'héritage multiple conduit la route de code spaghetti (imaginez un troisième projet en utilisant le TheirShape interface... ce qui se passe si ils demandent également de leur fonction draw my_draw ?).

    Mise à jour: Il y a un couple de nouvelles références sur le non-héritage polymorphisme basé sur:

    • TBH l'héritage est beaucoup plus claire que celle de C++11 chose, qui prétend être une interface, mais est plutôt une colle pour lier certaines incohérences dans les dessins. Formes exemple est détaché de la réalité et Circle classe est une mauvaise conception. Vous devez utiliser Adapter modèle dans de tels cas. Désolé si ça va paraître un peu dur, mais essayez d'utiliser certains de la vie réelle de la bibliothèque comme Qt avant de faire des jugements à propos de l'héritage. L'héritage rend la vie beaucoup plus facile.
    • Le son n'est pas dure du tout. Quelle est la forme exemple détaché de la réalité? Pourriez-vous donner un exemple (peut-être sur ideone) de fixation de Cercle à l'aide de la Adapter modèle? Je suis intéressé de voir ses avantages.
    • O. K. je vais essayer de tenir dans cette petite boîte. Tout d'abord, vous avez l'habitude de choisir des bibliothèques comme "MyShape" avant de commencer à écrire votre propre application, à la sécurité de vos travaux. Sinon, comment pourriez-vous savoir Square n'est pas déjà là? Prescience? C'est pourquoi il est détaché de la réalité. Et en réalité, si vous choisissez de compter sur des "MyShape" bibliothèque vous pouvez adopter pour son interface depuis le début. Dans les formes exemple il y a beaucoup de bêtises (dont l'une est que vous avez deux Circle les structures), mais l'adaptateur ressemblerait à quelque chose comme ça -> ideone.com/UogjWk
    • Comme je l'ai mentionné Qt. Vérifiez cet exemple -> qt-project.org/doc/qt-5/qtwidgets-widgets-scribble-example.html pour voir quelle est la solidité de l'héritage tout à fait avec les méthodes virtuelles est. Et avec interdit d'héritage et que C++11 "interface" chose au lieu de cela, je suis censé mettre en œuvre tous les temps, TOUTES les méthodes virtuelles qui QWidget a? Aurais-je besoin de déléguer chaque appel afin de vérifier, par exemple, mon widget personnalisé position? D'autre part Qt devait devenir l'en-tête uniquement de la bibliothèque, en raison de "l'interface" chose nécessaire pour invoquer mon implémentations.
    • Il n'est pas détaché de la réalité d'alors. Lorsque la société A achète la société B et veut intégrer la société B de la base de code en Un, vous avez deux complètement indépendant des bases de code. Imaginez que chacun a une Forme de hiérarchie de types différents. Vous ne pouvez pas combiner facilement avec l'héritage, et ajouter de la société C et vous avez un énorme gâchis. Je pense que vous devriez regarder ce discours: youtube.com/watch?v=0I0FD3N5cgM Ma réponse est plus âgé, mais vous allez voir les similitudes. Vous n'avez pas à ré-écrire tout le temps,vous pouvez fournir une implémentation de l'interface et choisir une fonction membre, si disponible.
    • Il ya aussi un couple de négociations par Sean Parent concept de base du polymorphisme qui pourrait être intéressant pour vous.
    • Mentionné Qt a été possédé par 3 entreprises (Trolltech, Nokia, Digia), mais aucun d'entre eux n'a la chose que vous dites. Il est détaché de la réalité. Donnez-moi un exemple du monde réel logiciel si ce code de la fusion a eu lieu. Même si vous devez utiliser Adapter modèle. Fournir la mise en œuvre de l'interface comme dans votre réponse signifie que je dois fournir toutes les méthodes virtuelles, qui, autrement, pourrait être tout simplement hérité.
    • J'ai regardé la vidéo et ce qui est totalement faux. Je n'ai jamais utiliser dynamic_cast, sauf à des fins de débogage. Dynamique de fonte signifie theres quelque chose de mal avec votre conception et de dessins dans cette vidéo sont mauvais en dessin :). Guy mentionne même Qt, mais même ici, il est mal - QLayout n'hérite de QWidget, ni l'inverse!
    • J'ai mis à jour la réponse de référence dans le cas où vous êtes intéressés à en apprendre plus au sujet de cette. Ces trois sociétés que vous mentionnez tous travaillent à l'aide de la même bibliothèque. L'héritage devient un énorme problème quand ce n'est pas le cas. Des exemples de sociétés qui sont indiqués dans le Sean Parent parler de concept de base du polymorphisme.Les liens fournis ont plus d'informations que je peux donner ici.
    • J'ai regardé la vidéo sur le concept de base du polymorphisme. Alors que la technique est intéressante et peut trouver certaines applications, cela ne peut pas remplacer l'héritage polymorphisme basé sur (et ce concept de base du polymorphisme utilise encore l'héritage caché dans le privé modèle des structures). Le polymorphisme n'est pas seulement pour votre fonctionnement interne, mais aussi de fournir un moyen d'application d'interagir avec une bibliothèque. Photoshop n'est pas une bibliothèque de sorte qu'il n'était même pas considéré comme dans la vidéo. Je ne peux pas voir toutes les caractéristiques pratiques dans le conecpt basée sur le polymorphisme qui n'a pas pu être réalisé avec l'OMI beaucoup plus propre héritage.
    • Je suis d'accord que l'héritage basée sur le polymorphisme est très facile à utiliser en C++ (cette fonction a le plein soutien de la langue). En C par exemple, il est très difficile de le faire. En Haskell, la Rouille, la Scala.. vous avez traits et typeclasses qui sont un peu comme support de langue pour les non-héritage basée sur le polymorphisme. Je l'ai utilisé dans une application et a été très heureux avec elle. Principalement en raison de l'augmentation des performances, il m'a donné (je peux avoir des vecteurs de chaque type, et un vecteur d'interfaces, donc j'ai utiliser le polymorphisme où j'ai besoin vraiment de lui). Nous allons voir comment cela évolue en C++, les gens ont commencé à en parler assez récemment...
    • La droite. Le problème est que je ne vois pas pourquoi l'héritage est "la racine de tous les maux". Cette affirmation est ridicule.
    • Bien que l'instruction est plus comme "l'héritage basée sur le polymorphisme est la racine de tout mal". Après avoir réfléchi un peu plus sur la solution que vous avez fournis à l'aide de l'Adaptateur modèle, l'avantage que je vois à propos de l'utilisation d'un type effacé de l'interface à la place (comme celui de sean parent utilise), c'est que votre interface est en un seul endroit, et vous pouvez prolonger son comportement et de fournir des valeurs par défaut par non-membre non-amis fonctions de. L'interface est cependant plus complexe à mettre en œuvre. Le mécanisme d'extension... ses ADL vs non-ADL. Si vous allez pour les AVQ, vous êtes au fond "voler" les noms de fonction de vos utilisateurs des espaces de noms.
    • Et c'est de l'OMI mauvais, parce que vous voulez diviser logiciels complexes en petites parties logiques et à l'héritage vous aide à le réaliser. Avoir toutes sortes d'objets (les modèles dans ce cas précis) dégénéré à une seule classe n'est pas convaincant pour moi. Comment suis-je censé étendre ce concept de base de l'interface si je n'ai pas accès à object_t internes, ni je ne peux pas hériter d'après elle? De ce que je vois, je dois mettre en œuvre draw() fonction à partir de zéro sur mon propre et je ne suis pas lié à concept_t interface. Aussi, avec des méthodes virtuelles, je peux avoir des implémentations par défaut, ce que je peux remplacer ou non.
    • Terme "interface" vient du monde Java. Ce que Java doc est-à-dire: "mise en Œuvre d'une interface permet à une classe de devenir plus formelle sur le comportement qu'il promet de fournir. Interfaces forme d'un contrat entre la classe et le monde extérieur, et ce contrat est appliquée au moment de la construction par le compilateur. Si votre classe implémente une interface, toutes les méthodes définies par l'interface doit apparaître dans son code source avant de la classe compiler avec succès." (docs.oracle.com/javase/tutorial/java/concepts/interface.html) Chose que vous présentez est comme le monde à l'envers.
    • Exactement, et je pense que c'est la bonne chose à faire: inscrivez votre classe de première, en faire le modèle d'une interface plus tard". Il dissocie complètement de votre classe de mise en œuvre de la modélisation d'une interface donnée, et vous permet d'utiliser votre classe dans le contexte, vous ne pouviez pas avait pensé au moment de l'écriture. C++ concepts, haskell typeclasses, rouille/scala traits, et l'Adaptateur motif vous a montré le travail de cette façon. Ce même raisonnement est derrière l'INB idiome, mais ces autres solutions de dissocier la conception même plus, depuis une classe n'est pas une interface plus (dans la "est un" sens de l'héritage).
    • C'est une route de pur gâchis. Adaptateur modèle existe pour lier incompatible interfaces, si nécessaire, mais les interfaces qui existent déjà. Je ne sais pas pourquoi même les classes d'utilisation de l'approche "écrire votre classe de première". Cette demande de revenir à la pure C. Sur ce principe sont vous la construction de votre classe si vous ne savez pas comment il va interagir avec le monde extérieur? Dire que vous avez utilisé votre propre mise en œuvre de gnzlbg::vector dans votre classe et je fournir interface avec mes personnalisé doc::vector et vous devez convertir les données d'entrée et de sortie à votre intérieur. Où est notre code de la ré-utilisation et efficacité si vous avez besoin de les convertir?
    • Notez tout d'abord qu'une interface peut emballer un type, soit par la valeur de référence unique, ou de référence partagé. Deuxièmement, ce problème avec le vecteur existent déjà depuis allocateur est dans le std::vector type. La solution est soit de se convertir (qui consiste à copier: cher), ou de fournir une interface iterator au lieu par exemple à l'aide coup de pouce.Itérateur.any_iterator (qui utilise le type-erasure décrit ici, et il est lent). Pourquoi dites-vous qu'il vous demande de revenir à la pure C? Les interfaces sont de type sécurisé et peut être très mince. Je construis mes cours en sachant que mes connaissances au sujet de mon problème (et à mes besoins) va changer avec le temps.
    • Quel serait l'héritage en fonction de la solution si vous ne pouvez pas modifier mon code? Le mieux que je puisse vous arriver, c'est: avoir un pur virtuel de la classe de base vectoriel, faire le vôtre héritent de celui-ci (toujours payer vtable), faire vos vecteurs de la fonction virtuelle (toujours payer ce prix), et l'utilisation de l'Adaptateur de modèle pour mon vecteur. L'alternative serait de créer un vecteur interface qui s'adapte à votre vecteur et mon vecteur. Et l'utilisation de l'interface lorsque vous besoin pour polymorphically accéder à votre vecteur et mon vecteur, mais seulement dans ces endroits. Et ici quand je dis que l'interface, je veux dire le mien, ou celui basé sur l'adaptateur modèle.
    • Laissez-nous continuer cette discussion dans le chat.
    • Le type d'emballage ne vous empêchera pas de réimplanter la même fonctionnalité et fait très cher la conversion entre les types de vecteurs. Problème avec le vecteur n'existe pas si nous avons tous deux utiliser doc::vector ou gnzlbg::vector sur l'interface local. Vous devez apprendre à bien utiliser l'héritage, parce que ce que vous dites maintenant, n'a aucun sens!

    InformationsquelleAutor gnzlbg
  8. 9

    Toutes les bonnes réponses ci-dessus.
    Une autre petite chose que vous devez garder à l'esprit que vous pouvez également avoir un destructeur virtuel pur. La seule différence est que vous avez encore besoin de la mettre en œuvre.

    Confus? 

    
--- header file ----
class foo {
public:
foo() {;}
virtual ~foo() = 0;
virtual bool overrideMe() {return false;}
};
---- source ----
foo::~foo()
{
}

    La principale raison pour laquelle vous voulez faire si vous souhaitez fournir des méthodes d'interface, comme je l'ai, mais de faire de leur remplaçant, en option.

    À faire de la classe une classe d'interface nécessite une méthode virtuelle pure, mais l'ensemble de vos méthodes virtuelles ont des implémentations par défaut, de sorte que la seule méthode à gauche pour faire virtuelle pure est le destructeur.

    De réimplanter un destructeur de la classe dérivée est pas une grosse affaire à tous - j'ai toujours réimplémenter un destructeur virtuel ou pas, dans mes classes dérivées.

    • Pourquoi, oh pourquoi, quelqu'un voudrait-il faire de la dtor dans ce cas virtuelle pure? Quel serait le gain de qui? Vous venais de force quelque chose sur les classes dérivées qui il est probable qu'ils n'ont pas besoin de comprendre un dtor.
    • Mise à jour de ma réponse, pour répondre à votre question. Pure destructeur virtuel est un chemin valide pour atteindre (la seule façon de l'obtenir?) une interface de classe où toutes les méthodes ont des implémentations par défaut.
    InformationsquelleAutor Rodyland
  9. 7

    Si vous utilisez Microsoft C++ compilateur, vous pouvez effectuer les opérations suivantes:

    struct __declspec(novtable) IFoo
{
virtual void Bar() = 0;
};
class Child : public IFoo
{
public:
virtual void Bar() override { /* Do Something */ }
}

    J'aime cette approche, car il en résulte un beaucoup plus petit code de l'interface et de la taille du code généré peut être considérablement réduite. L'utilisation de novtable supprime toute référence à la vtable pointeur de la classe, de sorte que vous pouvez ne jamais l'instancier directement. Voir la documentation ici - novtable.

    • Je n'arrive pas à voir pourquoi vous avez utilisé novtable sur la norme de virtual void Bar() = 0;
    • C'est en plus (j'ai juste remarqué le manque = 0; que j'ai ajouté). Lire la documentation si vous ne le comprenez pas.
    • Je l'ai lu sans le = 0; et assumé, c'est juste un non-standard de la façon de faire exactement la même chose.
    InformationsquelleAutor Mark Ingram
  10. 4

    Un peu plus de ce qui est écrit là-haut:

    Tout d'abord, assurez-vous que votre destructeur est aussi virtuelle pure

    Seconde, vous pouvez hériter virtuellement (plutôt que normalement) lorsque vous procédez à mettre en œuvre, pour faire bonne mesure.

    • Pourquoi hériter pratiquement?
    • J'aime l'héritage virtuel parce que, conceptuellement, cela signifie qu'il n'existe qu'une seule instance de la classe héritée. Certes, la classe n'a pas de besoin d'espace de sorte qu'il peut être superflu. Je n'ai pas MI en C++ pour un certain temps, mais ne serait pas nonvirtual héritage compliquer upcasting?
    • Pourquoi, oh pourquoi, quelqu'un voudrait-il faire de la dtor dans ce cas virtuelle pure? Quel serait le gain de qui? Vous venais de force quelque chose sur les classes dérivées qui il est probable qu'ils n'ont pas besoin de comprendre un dtor.
    • Si il ya une situation que d'un objet qui serait détruit par le biais d'un pointeur vers l'interface, vous devez vous assurer que le destructeur est virtuel...
    • Il n'y a rien de mal avec un destructeur virtuel pur. Il n'est pas nécessaire, mais il n'y a rien de mal à cela. La mise en œuvre d'un destructeur dans une classe dérivée n'est pas énorme fardeau sur l'implémenteur de cette classe. Voir ma réponse ci-dessous pour expliquer pourquoi vous souhaitez faire cette.
    • +1 pour l'héritage virtuel, car avec les interfaces, il est plus probable que la classe va dériver de l'interface à partir de deux ou plusieurs chemins. J'ai opter pour une protection destructeurs dans les interfaces tho.
    • Je crois que l'intention derrière virtuelle pure destructeurs est d'empêcher une vtable d'être générés à moins qu'une classe qui hérite de l'interface de la classe est elle-même héritée de. Si c'est l'intention, cependant, le destructeur doit être à la fois déclarée virtuelle pure et définis de la manière suivante: class Base { public: ~Base() = 0; }; Base::~Base() {}, pour permettre au compilateur de générer des constructeurs par défaut pour les classes dérivées

    InformationsquelleAutor Uri
  11. 4

    Vous pouvez également envisager de contrat de classes mises en œuvre avec l'INB (Non Virtuel de l'Interface de Modèle). Par exemple:

    struct Contract1 : boost::noncopyable
{
virtual ~Contract1();
void f(Parameters p) {
assert(checkFPreconditions(p)&&"Contract1::f, pre-condition failure");
//+ class invariants.
do_f(p);
//Check post-conditions + class invariants.
}
private:
virtual void do_f(Parameters p) = 0;
};
...
class Concrete : public Contract1, public Contract2
{
private:
virtual void do_f(Parameters p); //From contract 1.
virtual void do_g(Parameters p); //From contract 2.
};
    • Pour les autres lecteurs, ce Dr Dobbs article "Conversations": Virtuellement Vôtre" par Jim Hyslop et Herb Sutter élabore un peu plus sur le pourquoi on pourrait vouloir utiliser l'INB.
    • Et aussi cet article "Virtualité" de Herb Sutter.
    InformationsquelleAutor Luc Hermitte
  12. 1

    Je suis encore nouveau dans le développement en C++. J'ai commencé avec Visual Studio (VS).

    Pourtant, personne ne semble mentionné le __interface VS (.NET). Je suis pas très sûr si c'est une bonne façon de déclarer une interface. Mais il semble fournir un d'application supplémentaires (mentionné dans les documents). De telle sorte que vous n'avez pas à spécifier explicitement le virtual TYPE Method() = 0;, car il sera automatiquement converti. 

    __interface IMyInterface {
HRESULT CommitX();
HRESULT get_X(BSTR* pbstrName);
};

    Cependant, je ne l'utilise pas parce que je suis préoccupation au sujet de la croix-plate-forme de compilation de compatibilité, car il uniquement disponible sous .NET.

    Si quelqu'un n'ai rien d'intéressant à ce sujet, s'il vous plaît partager. 🙂

    Grâce.

    InformationsquelleAutor Yeo
  13. 0

    Même s'il est vrai que virtual est le standard de facto pour définir une interface, il ne faut pas oublier le classique C-comme le modèle, qui est livré avec un constructeur en C++:

    struct IButton
{
void (*click)(); //might be std::function(void()) if you prefer
IButton( void (*click_)() )
: click(click_)
{
}
};
//call as:
//(button.*click)();

    Ceci a l'avantage que vous pouvez re-lier les événements d'exécution, sans avoir à construire votre classe à nouveau (comme le C++ n'a pas une syntaxe permettant de modifier des types polymorphes, c'est une solution de contournement pour caméléon classes).

    Conseils:

    • Vous pourriez hériter de cette classe de base (à la fois virtuel et non virtuel sont pas autorisés) et remplir click dans votre descendant du constructeur.
    • Vous pourriez avoir le pointeur de fonction en tant que protected membre et d'avoir un public de référence et/ou de lecture.
    • Comme mentionné ci-dessus, ceci vous permet de basculer de la mise en œuvre dans l'exécution. Ainsi, c'est une façon de gérer l'etat. En fonction du nombre de ifs vs modifications de l'état dans votre code, ce pourrait être plus rapide que switch()es ou ifs (redressement est attendu autour de 3-4 ifs, mais toujours mesurer en premier.
    • Si vous choisissez std::function<> sur des pointeurs de fonction, vous pourrait être en mesure de gérer l'ensemble de vos données d'objet dans IBase. À partir de ce point, vous pouvez avoir de la valeur de schémas pour IBase (par exemple, std::vector<IBase> de travail). Notez que cette pourrait être inférieure en fonction de votre compilateur et le code STL, et aussi que les implémentations actuelles de std::function<> ont tendance à avoir une surcharge par rapport à des pointeurs de fonction ou même des fonctions virtuelles (cela pourrait changer dans le futur).
    InformationsquelleAutor lorro
  14. 0

    Voici la définition de abstract class en c++ standard

    n4687

    13.4.2

    Une classe abstraite est une classe qui peut être utilisée que comme une classe de base classe; aucun objet d'un résumé
    la classe peut être créé, sauf que les sous-objets de classe qui en découlent. Une classe est abstraite si elle a au moins
    une fonction virtuelle pure.

    InformationsquelleAutor 陳 力
  15. -2
    class Shape 
{
public:
//pure virtual function providing interface framework.
virtual int getArea() = 0;
void setWidth(int w)
{
width = w;
}
void setHeight(int h)
{
height = h;
}
protected:
int width;
int height;
};
class Rectangle: public Shape
{
public:
int getArea()
{ 
return (width * height); 
}
};
class Triangle: public Shape
{
public:
int getArea()
{ 
return (width * height)/2; 
}
};
int main(void)
{
Rectangle Rect;
Triangle  Tri;
Rect.setWidth(5);
Rect.setHeight(7);
cout << "Rectangle area: " << Rect.getArea() << endl;
Tri.setWidth(5);
Tri.setHeight(7);
cout << "Triangle area: " << Tri.getArea() << endl; 
return 0;
}

    Résultat:
    Zone du Rectangle: 35
    L'aire du Triangle: 17

    Nous avons vu comment une classe abstraite définie une interface en termes de getArea() et les deux autres classes de mise en œuvre de la même fonction mais avec un autre algorithme pour calculer la surface spécifique de la forme.

    • Ce n'est pas ce qui est considéré comme une interface! C'est juste une classe de base abstraite avec une méthode qui doit être substituée! Les Interfaces sont généralement des objets qui ne contiennent que des définitions de méthode - un "contrat" d'autres classes ont à remplir lorsqu'ils mettent en œuvre l'interface.
    InformationsquelleAutor hims