Discussion :

[3DArchi]

Soit le code suivant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Davidbrcz]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[JolyLoic]

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

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 ]

[3DArchi]

Merci pour les réponses.

[HanLee]

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.

[3DArchi]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

&A::MaMethode

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

&(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.

[Davidbrcz]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

MethodeSurA  = &A::MaMethode;

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

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.

[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?

[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.

[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..

[3DArchi]

& 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.