Ambiguïté possible avec des «C» externes, une surcharge et des pointeurs de fonction

Avec des fonctions normales, on peut écrire

extern "C" int Frotz(int); // in a header int Frotz(int x) { return x; } 

Avec les pointeurs de fonction, cependant, cela semble avoir été implémenté de manière incohérente entre les compilateurs.

 extern "C" int Klutz(int (*)(int), int); int Klutz(int (*fptr)(int), int x) { return (*fptr)(x); } 

Dans la déclaration, l’argument est aussi extern "C" . Dans la définition, la plupart des compilateurs semblent correspondre à ces fonctions et font de Klutz une fonction extern "C" . Les compilateurs Sun et Cray, toutefois, interprètent ces fonctions comme étant différentes, ce qui produit un int Klutz(int (*fptr)(int), int x) surchargé int Klutz(int (*fptr)(int), int x) , ce qui génère ensuite une erreur de temps de lien.

Bien que les sections 7.5.5 de C ++ 98 et C ++ 11 garantissent l’interprétation de Frotz , je ne peux pas dire si la norme est ambiguë sur le sharepoint savoir si la correspondance extern "C" doit avoir lieu avant ou après le contrôle de surcharge.

• En C ++ 11 et au-delà, std :: ssortingng :: operator vérifie-t-il les limites?
• Comment initialiser un vecteur de pointeurs
• C ++ – L’instruction ne peut pas résoudre l’adresse d’une fonction surchargée
• Obtenir la taille d’un object Qt
• La fonction de modèle variadique simple ne peut pas être instanciée

Klutz ci-dessus doit-il générer un symbole mutilé (C ++) ou un symbole extern "C" ?

EDIT 1

Je pourrais utiliser un typedef pour lever l’ambiguïté du pointeur de fonction sur ABI C ou C ++, mais je voudrais savoir si le code ici (a) définit Klutz comme ayant une liaison C ++, (b) le définit comme ayant une liaison C, ou (c ) est ambigu selon la norme, de sorte que les compilateurs sont libres de choisir comment l’interpréter.

EDIT 2

Cela semble être un problème connu, du moins par les compilateurs dotés de suiveurs de bogues interrogeables. Dans mes tests, GCC, Clang, Intel, MSVC, IBM XL, PathScale, PGI et Open64 ne parviennent pas à distinguer les types de fonctions identiques à l’exception du couplage de langue, comme le requirejs explicitement le standard (voir la section 7.5.1, citée dans la réponse acceptée). Résoudre ce problème casserait beaucoup de code existant et nécessiterait une modification de ABI. Je ne suis au courant d’aucun compilateur utilisant une convention d’appel différente pour le couplage de langage C à C ++.

• Bug GCC : “Trouver des raisons de demander le retrait de cette fonctionnalité de la norme suivante est en quelque sorte pertinent ;-)” … “Et nous pourrions même choisir un WONTFIX officiel.”

• Clang bug : “Je suis vraiment terrifié à l’idée de faire appliquer cette règle, car le faire correctement signifie intégrer le couplage linguistique au type canonique, ce qui va casser une tonne de code.”

• Pourquoi puis-je convertir implicitement un littéral int en un int * en C mais pas en C ++?
• Comment copier un fichier d’un répertoire à un autre dans c / c ++
• Pourquoi la taille n’est-elle pas un argument de modèle de std :: initializer_list?
• Quels sont tous les problèmes de syntaxe introduits par l’utilisation des chevrons dans les modèles C ++?
• Revenons-nous à la langue source lisible par l’homme?

 extern "C" { typedef int (*KlutzFuncType)(int); int Klutz (KlutzFuncType, int); } int Klutz (KlutzFuncType fptr, int x) { return (*fptr)(x); } 

 typedef int (*KlutzCxxFuncType)(int); extern "C" { typedef int (*KlutzCFuncType)(int); int Klutz (KlutzCFuncType, int); } int Klutz (KlutzCxxFuncType fptr, int x) { return (*fptr)(x); } int Klutz (KlutzCFuncType fptr, int x) { return (*fptr)(x); } 

 prog.cpp: In function 'int Klutz(KlutzCFuncType, int)': prog.cpp:9:5: error: redefinition of 'int Klutz(KlutzCFuncType, int)' prog.cpp:8:5: error: 'int Klutz(KlutzCxxFuncType, int)' previously defined here