好的，问题标题有点像一个钩子。我已经知道没有 C++ 标准 ABI。也就是说，我没有欺骗你们热心的投票收集者。我想知道 C++ ABI 是否有任何限制。例如，至少一个类的名称在 ABI 名称中的某处被破坏似乎很常见。
一个更明确的问题
假设我对所有字符串都有一个无冲突的哈希函数。假设 GCC 在其名称修饰中又增加了一步：将当前修饰名称的散列附加到下划线。这几乎会破坏阳光下的一切，但 GCC 是否仍会像以前一样符合 C++ 标准？
编辑：
好的，显然“明确的问题”位是一个选择不当的小节名称。我真的很想更多地了解人们遵循的任何常见 ABI 标准。这是因为我使用 Mingw32 编译的二进制文件与我使用 MSVC 编译的二进制文件成功链接。
它仍然符合 ISO C++ 标准，该标准甚至没有在规范性文本中提及名称修改，更不用说限制如何完成，但不符合GCC 用于大多数平台的跨供应商ABI 标准。
该标准故意在这个问题上保持沉默：所有与 ABI 和名称修改相关的内容都是特定于实现的。我相信，与该主题的信息最接近的是：
7.5/1 [dcl.link]
所有函数类型、具有外部链接的函数名称和具有外部链接的变量名称都具有语言链接。[注意：与具有语言链接的实体关联的某些属性特定于每个实现，此处不予描述。例如，特定的语言链接可能与表示具有外部链接的对象和函数名称的特定形式相关联，或者与特定的调用约定等相关联。-结束注释]
因此，每个实现都可以自由地做任何关于名称修改的事情，只要修改后的名称在底层操作系统上是有效的。
是的，它当然仍然符合标准。然而，尽管符合标准是一件很棒的事，但它肯定不是万能的。
这样的更改实际上会破坏用 C++ 编写并使用所述版本的 GCC 编译的每个库或应用程序的向后兼容性。向后兼容性对于 GCC 开发人员来说非常重要，他们在邮件列表上花费了相当长的时间（只是看看）讨论在面对这种破坏时即使是非常小的 ABI 更改的相对好处。通常，他们会竭尽全力提供可以保持向后兼容性的解决方法。
有些事情告诉我，如果他们改变了这个政策，大多数发行版都会拒绝升级。甚至可能会让他们中的一些人搬到铿锵声...
至少我们可以放心，他们会添加另一个-f选项来关闭新的“功能”。