2010-08-23 25 views
6
struct B1{ 
    int d; 
    void fb(){}; 
}; 

struct B2 : B1{ 
    using B1::d; 
    using B1::fb; 

    int d;    // why this gives error? 
    void fb(){}   // and this does not? 
}; 

int main(){} 

Est-ce parce que, B1::fb() est traité comme B1::fb(B1*)and B2::fb() traité comme B2::fb(B2*)? Autrement dit, le paramètre implicite aide-t-il à les distinguer?déclaration utilisant (classe dérivée)

$ 13.3.1/4-

Pour les fonctions introduites par la non-conversion en utilisant une déclaration dans un dérivé classe, la fonction est considérée comme être membre de la classe dérivée pour le but de définir le type de le paramètre d'objet implicite.

Répondre

9

La norme C++ (C++ 03 §7.3.3/12) explique:

Lorsqu'un à l'aide-déclaration porte les noms d'une classe de base dans un champ de classe dérivée, les fonctions membres dans la classe dérivée remplacer et/ou masquer les fonctions membres avec le même nom et les mêmes types de paramètres dans une classe de base (plutôt que d'être en conflit).

Dans votre exemple, B2::fb() masque le B1::fb() introduit par la déclaration using.

Quant à savoir pourquoi il est mal formé pour avoir à la fois using B1::d; et int d; dans la définition de B2, le C++ standard (03 §7.3.3/10 C++) explique:

Depuis un using-declaration est une déclaration, les restrictions sur les déclarations du même nom dans la même région déclarative s'appliquent également à using-declarations.

Ainsi, il est mal formé pour la même raison que ce qui suit est mal formé: il en résulte deux objets avec le même nom dans une seule région déclarative:

struct S { int d; int d; }; 
+0

et int d en conflit avec la déclaration précédente de l'utilisation ... – diverscuba23

+0

quelle est la réelle implicaation de 13.3.1/4 $ dans ce cas? – Chubsdad

+1

@chubsdad: Puisque 'B2 :: fb()' cache 'B1 :: fb()', 'B1 :: fb()' n'est pas considéré comme une fonction candidate pendant la résolution de surcharge, donc le §13.3.1/4 fait ne s'applique pas. –