Pourquoi un substituée fonction dans la classe dérivée cacher d'autres surcharges de la classe de base?

Examiner le code : 

#include <stdio.h>

class Base {
public: 
    virtual void gogo(int a){
        printf(" Base :: gogo (int) \n");
    };

    virtual void gogo(int* a){
        printf(" Base :: gogo (int*) \n");
    };
};

class Derived : public Base{
public:
    virtual void gogo(int* a){
        printf(" Derived :: gogo (int*) \n");
    };
};

int main(){
    Derived obj;
    obj.gogo(7);
}

Eu cette erreur :

>g++ -pedantic -Os test.cpp -o test 
test.cpp: In function `int main()': 
test.rpc:31: error: no matching function for call to `Dérivée::gogo(int)' 
test.rpc:21: remarque: les candidats sont: virtual void Dérivés::gogo(int*) 
test.rpc:33:2: attention: pas de saut de ligne en fin de fichier 
>le code de Sortie: 1

Ici, la classe Dérivée de la fonction est éclipsant toutes les fonctions de même nom (pas de signature) dans la classe de base. En quelque sorte, ce comportement de C++ n'a pas l'air OK. Pas polymorphes.

  • Dupliquer: stackoverflow.com/questions/411103/...
  • brillant question, je n'ai découvert cela récemment trop
  • Je pense que Bjarne (à partir du lien Mac posté) celui qui a le mieux en une phrase: "En C++, il n'y a pas de surcharge dans les étendues de la classe dérivée étendues ne sont pas une exception à cette règle générale."
  • Que le lien est brisé. Voici le bon (comme maintenant) - stroustrup.com/bs_faq2.html#overloadderived
  • Si tu sûr, il ne veut pas nuire à quoi que ce soit sans cacher la classe de base gogo fonctions, vous pouvez éviter de le cacher en ajoutant using Base::gogo dans la classe Dérivée.
  • Aussi, je voulais souligner que obj.Base::gogo(7); fonctionne toujours par l'appel de la fonction cachée.

InformationsquelleAutor Aman Aggarwal | 2009-10-27
  1. 390

    À en juger par la formulation de votre question (que vous avez utilisé le mot "hide"), vous savez déjà ce qui se passe ici. Le phénomène est appelé "nom de la clandestinité". Pour une raison quelconque, chaque fois que quelqu'un pose une question à propos de pourquoi nom de cacher qui se passe, les gens qui répondent dire que ce qu'on appelle "nom de la clandestinité et expliquer comment cela fonctionne (qui vous savez probablement déjà), ou d'expliquer comment le remplacer (ce qui vous jamais demandé à ce sujet), mais personne ne semble se soucier de répondre aux "pourquoi" question.

    La décision, le raisonnement derrière le nom de la clandestinité, c'est à dire pourquoi il en fait a été conçu en C++, est d'éviter certains contre-intuitif, imprévisibles et potentiellement dangereux d'un comportement qui pourraient avoir lieu si les hérité d'un ensemble de fonctions surchargées ont été autorisés à mélanger avec de l'actuel ensemble de surcharges dans la classe donnée. Vous le savez probablement qu'en C++, la résolution de surcharge fonctionne en choisissant la meilleure fonction à partir de l'ensemble des candidats. Cela se fait en faisant correspondre les types des arguments de types de paramètres. Les règles de correspondance pourrait être compliqué à la fois, et conduisent souvent à des résultats qui pourraient être perçus comme illogique par un dépourvu de l'utilisateur. L'ajout de nouvelles fonctions à un ensemble de déjà existants pourraient résulter plutôt un changement radical dans la résolution de surcharge résultats.

    Par exemple, disons que la classe de base B a une fonction membre foo qui prend un paramètre de type void *, et tous les appels à foo(NULL) sont résolus à B::foo(void *). Disons qu'il n'y a aucun nom de la clandestinité et de ce B::foo(void *) est visible dans beaucoup de différentes classes descendantes de B. Cependant, disons que dans certains [indirecte, à distance] descendant D de classe B une fonction foo(int) est défini. Maintenant, sans nom de cacher D a deux foo(void *) et foo(int) visible et en participant à la résolution de surcharge. Quelle fonction les appels à foo(NULL) résoudre à, si elle est faite par l'intermédiaire d'un objet de type D? Ils vont résoudre à D::foo(int), depuis int est une meilleure correspondance intégrale de zéro (c'est à dire NULL) que n'importe quel type de pointeur. Ainsi, tout au long de la hiérarchie des appels à foo(NULL) résoudre à une seule fonction, tandis que dans D (et moins) ils ont soudainement résoudre à un autre.

    Un autre exemple est donné dans La Conception et l'Évolution de C++, page 77:

    class Base {
    int x;
public:
    virtual void copy(Base* p) { x = p-> x; }
};

class Derived{
    int xx;
public:
    virtual void copy(Derived* p) { xx = p->xx; Base::copy(p); }
};

void f(Base a, Derived b)
{
    a.copy(&b); //ok: copy Base part of b
    b.copy(&a); //error: copy(Base*) is hidden by copy(Derived*)
}

    Sans cette règle, b l'état serait partiellement mis à jour, conduisant à découpage.

    Ce comportement a été jugé indésirable quand le langage a été conçu. Une meilleure approche, il a été décidé de suivre le nom "cacher" de la spécification, ce qui signifie que chaque classe commence par un "clean sheet" à l'égard de chaque nom de la méthode, il déclare. Afin de tenir compte de ce comportement, une action explicite est requis de l'utilisateur: à l'origine un redeclaration de la méthode héritée(s) (actuellement obsolète), et maintenant une utilisation explicite de l'utilisation de la déclaration.

    Comme vous l'avez observé dans votre post original (je fais référence à la "Pas polymorphe" la remarque), ce comportement peut être considéré comme une violation de l'EST-UN relationsip entre les classes. C'est vrai, mais apparemment, à l'époque, il avait été décidé qu'à la fin du nom de la clandestinité se révélera être un moindre mal.

    • Oui, c'est une vraie réponse à la question. Je vous remercie. J'ai été trop curieux.
    • Super réponse! Aussi, en pratique, la compilation serait probablement obtenir beaucoup plus lent si la recherche par nom de a à aller tout le chemin vers le haut à chaque fois.
    • ~~Cool answer~~
    • J'étais à la recherche pour cette réponse depuis longtemps.
    • (Vieille réponse, je sais). Maintenant nullptr je voudrais objet de votre exemple en disant "si tu voulais appeler le void* version, vous devez utiliser un pointeur de type". Est-il un autre exemple où cela peut être mauvais?
    • Ça semble être un problème de structure de données. Le compilateur doit être assez intelligent pour stocker la base et dérivées des méthodes d'une classe dérivée dans une table de hachage ou une structure similaire pour la fonction de recherche rapide à la place de l'analyse de la hiérarchie.
    • Le nom de la clandestinité n'est pas vraiment mal. Le "est-un" de la relation est toujours là, et disponible par le biais de l'interface de base. Alors peut-être d->foo() vous n'obtiendrez pas de "Est-un Base", mais static_cast<Base*>(d)->foo() est, y compris la dynamique de l'expédition.
    • Quand je fais int n = pow(2,4), j'ai une erreur de compilation, en disant que cet appel est ambiguë et peut être assorti à T pow(T,T) pour T=double T=float ou T=long. Comment se fait l'un comportement indésirable justifiant nom de cacher (c'est à dire foo(NULL) peut être jumelé à foo(void *) ou foo(int)) n'est pas géré par une telle ambiguë "appel" erreur de compilation ?
    • Dans le pow exemple, l'erreur est générée, car il n'y a pas de correspondance exacte pour votre argumentation. Dans foo(NULL) cas avec NULL défini comme 0, le int version offre une correspondance exacte et aucune erreur n'est générée.
    • Je ne suis toujours pas clair pourquoi la surcharge serait considéré comme indésirable lorsque le nombre de paramètres à modifier. Dans les faits, j'étais sous l'impression que le compilateur génère un autre nom de la fonction pour chaque prototype de méthode.
    • Cette réponse est inutile, car l'exemple donné se comporte de la même avec ou sans cacher: D::foo(int) sera appelée, soit parce qu'il est un meilleur match ou parce qu'il a caché B:: foo(int).
    • de l'autre il fait plus de sens. Si nous avions B::foo(int) et D::foo(void*), puis, sans nom de cacher appel à D::foo(NULL) serait encore résoudre à B::foo(int) car il est évidemment meilleur match, mais généralement ce n'est pas ce que vous désirez. Mais, franchement, je ne peux pas penser à tout bon nom de cacher la rationalisation de l'autre que le fait que "c'est la façon dont la recherche d'un nom œuvres" - lorsque vous appelez une fonction dans un intérieur de la portée, vous vous attendez à utiliser une fonction à partir d'intérieure, de la portée, non pas de l'extérieur (éventuellement mondial) champ d'application.
    • Une autre brèche dans cette réponse, c'est que tout le monde accepte exactement ce comportement étrange en apparence, parce que c'est juste ce qui se passe si vous la surcharge de fonctions – sauf quand vous surchargez un membre de base de la fonction dans une classe dérivée. C'est donc une mauvaise explication de l'rationnels derrière la règle.
    • L'exemple de la réponse n'a pas B::foo(int), de sorte que votre analyse de la valeur de la réponse n'est pas correcte.
    • comment les gens connaissent tous cette info .. incroyable réponse !
    • alors d'après vous que peut-être la bonne explication de la raison d'être derrière ce nom se cachant la règle ?
    • Oh, l'explication est juste ce que AnT dit. Stroustrup a dit à plusieurs reprises. (Si vous voulez des réponses à ces questions, vous devriez lire son Conception et l'Évolution de C++ livre. Une excellente lecture.) Seulement l'exemple n'est pas très utile, et c'est la règle est discutable en général. (Notez, s'il vous plaît, comment je l'ai dit "douteuse", pas "mauvais". Je ne suis pas sûr et je ne suis pas prêt à mettre le temps requis pour trouver. Mais je trouve qu'il vaut la peine de questionnement.)
    • C'est pourquoi nullptr a été créée pour peut-être un exemple réel qui n'a pas été résolu?

    InformationsquelleAutor AnT
  2. 43

    Les règles de résolution de noms de dire que la recherche d'un nom, s'arrête dans le premier domaine dans lequel un nom correspondant est trouvé. À ce point, la résolution de surcharge règles de coup de pied dans le pour trouver la meilleure correspondance entre les fonctions disponibles.

    Dans ce cas, gogo(int*) est trouvé (seul) dans la classe Dérivée de la portée, et comme il n'y a pas de standard de conversion de int int*, la recherche échoue.

    La solution est d'importer la Base de déclarations par l'intermédiaire d'une aide de la déclaration dans la classe Dérivée:

    using Base::gogo;

    ...permettrait au nom de règles de recherche pour trouver tous les candidats et donc la résolution de surcharge, de procéder comme vous l'avez prévu.

    • Mais whyyyy?????
    • OP: "Pourquoi un substituée fonction dans la classe dérivée cacher d'autres surcharges de la classe de base?" Cette réponse: "Parce qu'il n'".
    InformationsquelleAutor Drew Hall
  3. 13

    C'est "By Design". En C++ résolution de surcharge pour ce type de méthode fonctionne comme suit.

    • De départ à la catégorie de référence, puis d'aller au type de base, trouver le premier type qui a une méthode nommée "gogo"
    • En considérant seulement les méthodes nommées "gogo" sur ce type de trouver un correspondant de surcharge

    Depuis Dérivé ne pas correspondre une fonction nommée "gogo", résolution de surcharge échoue.

    • Malheureux, mais vrai.
    InformationsquelleAutor JaredPar
  4. 2

    Nom de cacher un sens, car il empêche les ambiguïtés de la résolution de nom.

    Considérer ce code:

    class Base
{
public:
    void func (float x) { ... }
}

class Derived: public Base
{
public:
    void func (double x) { ... }
}

Derived dobj;

    Si Base::func(float) n'était pas cachée par Derived::func(double) dans la Dérivée, on pourrait appeler la classe de base de la fonction lors de l'appel de dobj.func(0.f), même si un flotteur peut être promu à un double.

    Référence: http://bastian.rieck.ru/blog/posts/2016/name_hiding_cxx/

    • ses conneries. Si vous avez une base de catégorie B, et vous defrive C et D de B et vous avez là Un de C et D, vous avez le même problème. Mais ils ne se cassent de la merde pour fixer la merde. aucun montant de la préoccupation de ce qui pourrait arriver jamais remplace comon depuis ou de programmation.
    InformationsquelleAutor Sandeep Singh