C与C++中结构体适用的ODR规则差异澄清问询

问题1：上述代码是合法C++程序吗？ #

不合法，属于明确的ODR（单一定义规则）违规，程序行为未定义。
C++标准要求，拥有外部链接的类类型如果在多个翻译单元（TU）中出现定义，所有定义的token序列、名称绑定结果必须完全一致。你示例中全局命名空间下的struct foo_t、Foo属于具有外部链接的类型，两个翻译单元中定义完全不同，直接违反ODR。编译器不需要强制诊断这类跨翻译单元的ODR违规，所以编译无报错不代表程序合法。
你提到的匿名命名空间是正确的修复方案：将结构体定义放入匿名命名空间后，该类型仅对当前翻译单元可见，属于内部链接，两个翻译单元的类型互不干扰，符合ODR要求。

问题2：上述代码是合法C程序吗？ #

完全合法，符合C11标准要求。
C语言的规则和C++有本质差异：C标准仅规定对象、函数、枚举常量具备链接性，类型（包括结构体标签、typedef名）本身没有链接性，跨翻译单元的同名类型不会产生冲突，只要单个翻译单元内部的类型定义自洽即可。你看到的“C语言类型默认是static”的说法是对该特性的不准确表述，实际是类型本身不存在链接属性，自然不会跨TU冲突。

问题3：C库头文件冲突的兼容性问题 #

是否触发ODR？ #

会。如果C库的公开头文件在全局作用域定义了同名结构体，C++不同翻译单元分别引入后，和问题1的场景完全一致，属于ODR违规，行为未定义。

如何规避？ #

1. 最优方案：可控的C库代码遵循命名约定，给公开类型加库专属前缀，比如liba_foo_t、libb_foo_t，从根源避免命名冲突。
2. 不可控第三方库的场景：C++侧引入头文件时包裹独立命名空间，示例如下：

// 引入第一个C库头文件
namespace liba {
#include "liba.h"
}
// 引入第二个C库头文件
namespace libb {
#include "libb.h"
}

此时两个库的同名类型会被划分到不同C++命名空间下，不存在冲突，符合ODR要求。如果头文件包含函数声明，需要额外将函数声明放入extern "C"块保证链接符号正确。

extern "C"是否发挥作用？ #

完全不发挥作用。extern "C"仅修改函数、变量的链接符号生成规则，适配C的ABI，不影响C++的类型系统和ODR规则，无法解决类型命名冲突问题。

内容的提问来源于stack exchange，提问作者Quimby