8
votes

Espace de noms d'affichage en C ++

Je ne peux pas comprendre pourquoi ce morceau de code ne compile pas: xxx pré>

J'utilise gcc 4.3.3 code>, et l'erreur est: p>

s3.cpp: In function ‘void B::G(A::H)’:
s3.cpp:2: error: ‘class A::F’ is not a function,
s3.cpp:7: error:   conflict with ‘void B::F(A::H)’
s3.cpp:9: error:   in call to ‘F’


0 commentaires

4 Réponses :


12
votes

C'est parce que le compilateur recherchera la fonction dans le même espace de noms ses arguments. Compilateur trouvé là-bas a :: f identifiant mais ce n'est pas une fonction. En résultat, vous obtiendrez l'erreur.

C'est un comportement standard aussi loin que je pourrai vous en souvenir.

3.4.2 Nom de l'argument-dépendant de la recherche Lorsqu'un nom non qualifié est utilisé comme l'expression postfix dans un appel de la fonction (5.2.2), d'autres espaces de noms non pris en compte lors de la recherche habituelle non qualifiée (3.4.1) peuvent être recherchés et des déclarations de fonctions d'ami d'espace de noms (11.4) non sinon visible peut être trouvé. Ces modifications apportées à la recherche dépendent des types des arguments (et des arguments de modèle de modèle, l'espace de noms de l'argument de modèle).

Pour chaque argument Type T Dans l'appel de la fonction, il existe un ensemble d'espaces de noms zéro ou plus associés et un ensemble de classes zéro ou plus associées à prendre en compte. Les ensembles d'espaces de noms et de classes sont entièrement déterminés par les types d'arguments de la fonction (et l'espace de noms de tout argument de modèle de modèle). Noms TypeDEF et Utilisation de déclarations utilisées pour spécifier les types ne contribuent pas à cet ensemble. Les ensembles d'espaces de noms et de classes sont déterminés de la manière suivante ...

Cette règle vous permet d'écrire le code suivant: xxx

et enfin: à cause de Numéro de base 218 Certains compilateurs compileraient le code en question sans erreur.


4 commentaires

Doit appelé Koenig Recherche, décrite en fait à la section 3.4.2 de la norme C ++.


Ensuite, si vs compile cela, c'est un bug?


Pourriez-vous trouver une référence à cette déclaration? Je n'ai jamais entendu parler de règle comme ça ...


@Liori, vs compile ceci à cause du problème de base 218.



5
votes

Avez-vous déjà essayé d'utiliser d'autres compilateurs? Il y a un rapport de bogue GCC ici qui est suspendu ( Quoi que cela signifie).

Edit: Après quelques recherches, j'ai trouvé ce Plus Bug officiel .


6 commentaires

C'est un exemple minimal de mon propre code qui compile sur le VS2005 de mon ami. Je n'ai pas testé cette pièce exacte cependant. Et ... Deusaduro semble avoir aucun problème le compilant sur VS2005.


Le rapport de bogue ressemble à cela, bien qu'il s'agisse de modèles, qui ont un schéma de recherche encore différent (en deux phases).


Remarque: D'autres rapportent VS2005 pour compiler ce code comme prévu. J'ai essayé le test de test de Comeau -> succès. Seul GCC semble en souffrir, semble-t-il.


Si la réponse de Jia3ep est correcte et que je crois que c'est, alors GCC n'est pas "souffrance", mais comme d'habitude, vs est non conforme.


@xtofl: au moins le bogue que j'ai mentionné d'abord est disponible ici: GCC.GNU. org / bugzilla / show_bug.cgi? id = 25980 et a marqué un duplicata de ce bogue.


@RMEADOR, semble être vs est complètement conforme à la dernière version.



1
votes

Très étrange, j'ai copié et collé directement à VS 2005 et je reçois une erreur, que je m'attendais à:

Erreur 1 erreur LNK2001: Symbole externe non résolu "Void __cdecl B :: F (classe A :: H)"

Parce que nous n'avons pas vraiment défini f (x) dans la nom d'espace de noms ... Je ne sais pas pourquoi GCC donne cette erreur.


0 commentaires

0
votes

Je viens d'essayer de la compiler sur Visual Studio 2005 et cela a fonctionné bien. Je me demande s'il s'agit d'une mise en œuvre brisée de la recherche dépendante de l'argumentation où l'espace de noms des arguments a été intégré accidentellement?


0 commentaires