使用普通功能,可以编写
extern "C" int Frotz(int); // in a header
int Frotz(int x) { return x; }
但是,对于函数指针,这似乎在编译器之间不一致地实现.
extern "C" int Klutz(int (*)(int), int);
int Klutz(int (*fptr)(int), int x) { return (*fptr)(x); }
在声明中,论点也是extern "C".在定义中,大多数编译器似乎满足这些功能,使Klutz的extern "C"功能.但是,Sun和Cray编译器会将这些函数解释为不同,从而产生过载int Klutz(int (*fptr)(int), int x),从而产生链接时错误.
虽然C++ 98和C++ 11的7.5.5节保证了解释Frotz,但我无法判断标准是否extern "C"在检查重载之前或之后是否应该进行匹配时是不明确的.
Klutz上面应该生成一个受损的(C++)符号或extern "C"符号吗？
我可以使用typedef消除函数指针的歧义,使其具有C或C++ ABI,但我感兴趣的是这里的代码(a)是否定义Klutz了C++链接,(b)将其定义为具有C链接,或者(c)根据标准是模糊的,因此编译器可以自由选择如何解释它.
这似乎是一个已知问题,至少是那些具有可搜索错误跟踪器的编译器.在我的测试中,GCC,Clang,Intel,MSVC,IBM XL,PathScale,PGI和Open64都无法区分除语言链接之外相同的功能类型,如标准明确要求的那样(参见7.5.1引用的部分)接受的答案).修复此问题会破坏大量现有代码并需要进行ABI更改.我不知道任何编译器实际上使用不同的C语言与C++语言链接的调用约定.
海湾合作委员会的错误:"找到要求从下一个标准中删除此功能的理由是相关的;-)"......"我们甚至可以决定官方的WONTFIX."
Clang bug:"我害怕实际执行这条规则,因为正确地执行它意味着将语言链接作为规范类型的一部分,这将打破大量代码."