gcc vs Visual

Version imprimable

gcc vs Visual

Soit le code suivant

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class A
{
public:
   A(){}
   void MaMethode(){std::cout<<"coucou\n";}
};
 
int main()
{
   A a;
   typedef void (A::*tdMethodeSurA)();
   tdMethodeSurA MethodeSurA;
   MethodeSurA  = &(A::MaMethode);
   (a.*MethodeSurA)();
}

Ca compile avec VC++Express mais pas avec gcc. Pourquoi?
La ligne de commande gcc est:

Code:

1
2
 
g++ -c -o Debug\obj\main.o -g -O0 -mthreads  -W -Wall -DNOPCH   -Wno-ctor-dtor-privacy   -MTDebug\obj\main.o -MFDebug\obj\main.o.d -MD Sources/main.cpp

L'erreur est:

Code:

1
2
3
 
Sources/main.cpp:82: error: invalid use of non-static member function `void A::MaMethode()'
Sources/main.cpp:82: error: parenthesis around 'A::MaMethode' cannot be used to form a pointer-to-member-function

05/08/2008, 18h06
Davidbrcz

Code:

MethodeSurA = &(A::MaMethode);

Tel que le code est fait, tu assigne à MethodeSurA, l'adresse de ce que retourne la fonction statique MaMethode appartenant à la classe A, qui par ailleur est mal appelée (manque les parenthèses).

Pour que ca compile, enlève les parenthèses (comme te le fait remarque gcc).

PS 1: en lisant le titre, je m'attendais à un gros troll bien poilu.
PS 2: Je pense que c'est g++ qui à raison, VS étant assez connu pour sa complaisance façe à la norme, même si dans tous les cas, faut vérifier.
05/08/2008, 22h27
JolyLoic

On dirait bien que Visual C++ est trop laxiste :

Citation:

Envoyé par Le standard (dernier draft) 5.3.1/3

A pointer to member is only formed when an explicit & is used and its operand is a qualified-id not enclosed in parentheses.
[ Note: that is, the expression &(qualified-id), where the qualified-id is enclosed in parentheses, does not form an expression of type “pointer to member.” Neither does qualified-id, because there is no implicit conversion from a qualified-id for a non-static member function to the type “pointer to member function” as there is from an lvalue of function type to the type “pointer to function” (4.3). Nor is &unqualified-id a pointer to member, even within the
scope of the unqualified-id’s class. —end note ]
06/08/2008, 08h31
3DArchi

Merci pour les réponses.
06/08/2008, 09h27
HanLee

Citation:

Envoyé par JolyLoic

On dirait bien que Visual C++ est trop laxiste :

Elle est bizarre la règle quand même, pas très cohérente avec le langage mais bon.
07/08/2008, 08h49
3DArchi

Du coup, je veux bien quelques éclairages. Quelle est la différence sémantique entre

Code:

&A::MaMethode

et

Code:

&(A::MaMethode)

. Pourquoi alors Visual serait trop laxiste et pas plutôt gcc trop restrictif. J'avoue qu'une réponse du type "c'est la norme" me laisserait plutôt sur ma faim.
07/08/2008, 08h59
Davidbrcz

Citation:

Code:

MethodeSurA = &(A::MaMethode);

Tel que le code est fait, tu assigne à MethodeSurA, l'adresse de ce que retourne la fonction statique MaMethode appartenant à la classe A, qui par ailleur est mal appelée (manque les parenthèses)

Code:

MethodeSurA = &A::MaMethode;

Tu prend l'adresse de la fonction membre MaMethode de la classe pour l'assigner à MethodeSurA.

Citation:

Pourquoi alors Visual serait trop laxiste et pas plutôt gcc trop restrictif. J'avoue qu'une réponse du type "c'est la norme" me laisserait plutôt sur ma faim.

Et c'est pourtant la vérité. Loic à cité le passage de la norme qui appuie que c'est bien g++ qui a raison.
07/08/2008, 09h05
3DArchi

J'insiste mais en quoi (A::MaMethode) est évaluée différemment de A::MaMethode? Je comprend l'explication de Davidbrcz si j'écris &(A::MaMethode()). Au quel cas, oui l'expression (A::MaMethode()) vaut le retour de MaMethode. Mais, pourquoi (A::MaMethode) n'est-ce pas évaluée comme A::MaMethode?
07/08/2008, 11h36
JolyLoic

Parce que c'est comme ça...

Il y a probablement une raison plus satisfaisante (genre une ambiguïté que cette règle permet de lever, ou une difficulté à implémenter le cas général), mais je ne la connais pas, et à première vue, je ne vois pas en quoi elle consisterait.

Autoriser &(A::f) signifierait que l'opérateur & appliqué à une expression (et non pas directement un nom de fonction membre) peut retourner un pointeur de fonction membre, ce qui est peut-être trop complexe à gérer.
07/08/2008, 13h36
Jean-Marc.Bourguet

& s'applique a des l-values ou a des identificateurs. Pour accepter &(A::m) ou meme &(f), il faudrait que (A::m) et (f) soient des l-values. Hors le C++ n'a pas de type fonction ou fonction membre..
07/08/2008, 13h55
3DArchi

Citation:

Envoyé par Jean-Marc.Bourguet

& s'applique a des l-values ou a des identificateurs. Pour accepter &(A::m) ou meme &(f), il faudrait que (A::m) et (f) soient des l-values. Hors le C++ n'a pas de type fonction ou fonction membre..

Je chipote mais alors pourquoi accepter &A::m?
En fait au début, j'avais tendance à penser comme JolyLoic: il devait y avoir une ambigüité ou une difficulté pour l'implémentation du compilo, mais je n'arrive pas à voir laquelle.