Posible ambigüedad con extern "C", sobrecarga y punteros de función
Con las funciones normales, uno puede escribir
extern "C" int Frotz(int); // in a header
int Frotz(int x) { return x; }
Sin embargo, con los punteros de función, esto parece haberse implementado de manera inconsistente entre compiladores.
extern "C" int Klutz(int (*)(int), int);
int Klutz(int (*fptr)(int), int x) { return (*fptr)(x); }
En la declaración, el argumento es tambiénextern "C". En la definición, la mayoría de los compiladores parecen coincidir con estas funciones y hacenKlutz unextern "C" función. Los compiladores Sun y Cray, sin embargo, interpretan estas funciones como diferentes, produciendo una sobrecargaint Klutz(int (*fptr)(int), int x), que luego genera un error de tiempo de enlace.
Aunque la Sección 7.5.5 de C ++ 98 y C ++ 11 garantiza la interpretación deFrotz, No puedo decir si el estándar es ambiguo sobre siextern "C" el emparejamiento debe ocurrir antes o después de verificar la sobrecarga.
DeberíaKlutz arriba genera un símbolo mutilado (C ++) o unextern "C" ¿símbolo?
Podría usar typedef para desambiguar el puntero de función para tener C o C ++ ABI, pero me interesa si el código aquí (a) defineKlutz para tener un enlace C ++, (b) define que tiene un enlace C, o (c) es ambiguo según el estándar, de modo que los compiladores tienen la libertad de elegir cómo interpretarlo.
Esto parece ser un problema conocido, al menos por aquellos compiladores con rastreadores de errores de búsqueda. En mis pruebas, GCC, Clang, Intel, MSVC, IBM XL, PathScale, PGI y Open64 no distinguen los tipos de funciones que son idénticos excepto el enlace de idioma, como lo exige explícitamente el estándar (consulte la sección 7.5.1, citado en la respuesta aceptada). Arreglar esto rompería una gran cantidad de código existente y requeriría un cambio de ABI. No tengo conocimiento de ningún compilador que realmente use una convención de llamada diferente para el enlace de lenguaje C versus C ++.
Error GCC: "Encontrar razones para solicitar la eliminación de esta característica de la siguiente norma es algo relevante ;-)" ... "Y es posible que incluso decidamos un WONTFIX oficial".
Clang bug: "Estoy aterrado de hacer cumplir esta regla, porque hacerlo correctamente significa hacer que el enlace del idioma sea parte del tipo canónico, lo que romperá una tonelada de código".