由于破坏方案没有标准化，因此这个问题没有单一的答案；最接近实际答案的方法是查看由最常见的损坏方案生成的损坏名称。据我所知，这些是 GCC 和 MSVC 方案，按字母顺序排列，所以......
GCC:
为了测试这一点，我们可以使用一个简单的程序。
#include <string>
#include <cstdlib>
std::string foo(int x) { return "hello"; }
//int foo(int x) { return x; }
int main() {
// Assuming executable file named "a.out".
system("nm a.out");
}
使用 GCC 或 Clang 编译并运行，它会列出它包含的符号。根据取消注释的函数，结果将是：
// GCC:
// ----
std::string foo(int x) { return "hello"; } // _Z3fooB5cxx11i
// foo[abi:cxx11](int)
int foo(int x) { return x; } // _Z3fooi
// foo(int)
// Clang:
// ------
std::string foo(int x) { return "hello"; } // _Z3fooi
// foo(int)
int foo(int x) { return x; } // _Z3fooi
// foo(int)
GCC方案包含的信息相对较少，不包括返回类型：
- 符号类型：
_Z为“功能”。
- Name:
3foo for ::foo.
- 参数：
i for int.
然而，尽管如此，当用 GCC 编译时它们是不同的（但用 Clang 则不然），因为 GCC 表明std::string版本使用cxx11 ABI.
请注意，它仍然跟踪返回类型，并确保签名匹配；它只是不使用函数的损坏名称来执行此操作。
MSVC:
为了测试这一点，我们可以使用一个简单的程序，如上所述。
#include <string>
#include <cstdlib>
std::string foo(int x) { return "hello"; }
//int foo(int x) { return x; }
int main() {
// Assuming object file named "a.obj".
// Pipe to file, because there are a lot of symbols when <string> is included.
system("dumpbin/symbols a.obj > a.txt");
}
使用 Visual Studio 编译并运行，以及a.txt将列出它包含的符号。根据取消注释的函数，结果将是：
std::string foo(int x) { return "hello"; }
// ?foo@@YA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@H@Z
// class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl foo(int)
int foo(int x) { return x; }
// ?foo@@YAHH@Z
// int __cdecl foo(int)
MSVC 方案包含整个声明，包括未明确指定的内容：
- Name:
foo@ for ::foo， 其次是@终止。
- 符号类型：名称终止后的所有内容
@.
- 类型和会员状态：
Y对于“非成员函数”。
- 调用约定：
A for __cdecl.
- Return type:
-
H for int.
-
?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@（其次是@终止）对于std::basic_string<char, std::char_traits<char>, std::allocator<char>> (std::string简称）。
- 参数表：
H for int（其次是@终止）。
- 异常说明符：
Z for throw(...);除非是其他名称，否则该名称会从分解名称中省略，可能是因为 MSVC 无论如何都会忽略它。
如果每个编译单元的声明不相同，它就会向您抱怨。
一般来说，大多数编译器在分别针对 *nix 或 Windows 时会使用这些方案之一（有时是其变体），但这并不能保证。例如...
- 据我所知，Clang 将使用 *nix 的 GCC 方案，或 Windows 的 MSVC 方案。
- Intel C++ 对 Linux 和 Mac 使用 GCC 方案，对 Windows 使用 MSVC 方案（有一些细微的变化）。
- Borland 和 Watcom 编译器有自己的方案。
- Symantec和Digital Mars编译器通常使用MSVC方案，有一些小的变化。
- 旧版本的 GCC 和许多 UNIX 工具使用 cfront 的重整方案的修改版本。
- 等等...
Schemes used by other compilers are thanks to Agner Fog's PDF.
Note:
检查生成的符号，很明显 GCC 的损坏方案无法提供与 MSVC 相同级别的针对马基雅维利的保护。考虑以下：
// foo.cpp
#include <string>
// Simple wrapper class, to avoid encoding `cxx11 ABI` into the GCC name.
class MyString {
std::string data;
public:
MyString(const char* const d) : data(d) {}
operator std::string() { return data; }
};
// Evil.
MyString foo(int i) { return "hello"; }
// -----
// main.cpp
#include <iostream>
// Evil.
int foo(int);
int main() {
std::cout << foo(3) << '\n';
}
如果我们单独编译每个源文件，然后尝试将目标文件链接在一起......
- GCC:
MyString，由于不属于cxx11ABI，原因MyString foo(int)被毁坏为_Z3fooi， 就像int foo(int)。这允许链接目标文件，并生成可执行文件。尝试运行它会导致段错误。
- MSVC：链接器将寻找
?foo@@YAHH@Z;因为我们提供了?foo@@YA?AVMyString@@H@Z，链接将会失败。
考虑到这一点，包含返回类型的重整方案更安全，即使函数不能仅根据返回类型的差异进行重载。
