源不兼容是否总是意味着二进制不兼容？答案

【问题标题】：Does source incompatibility always imply binary incompatibility?源不兼容是否总是意味着二进制不兼容？
【发布时间】：2009-08-03 00:51:23
【问题描述】：

欢迎提供任何说明源代码兼容性被破坏但二进制兼容性保持不变的示例。

【问题讨论】：

【解决方案1】：

旧版本：

struct inner {
  int bar;
}

struct foo {
  struct inner i;
};

void quux(struct foo *p);

新版本：

struct inner2 {
  int bar;
};

struct foo {
  struct inner2 i;
};

void quux(struct foo *p);

破码：

struct foo x;
struct inner *i = &x.i;
i->bar = 42;
quux(&x);

由于唯一的区别是结构的名称，并且内部结构的类型名称在编译过程中被删除，因此不存在二进制不兼容问题。

【讨论】：

【解决方案2】：

不同机器上不同版本的静态链接库可能会导致在机器 A 上编译的二进制文件在机器 B 上正常工作，但尝试从机器 B 上的源代码编译它失败。但除此之外，源不兼容通常意味着二进制不兼容。

【讨论】：

【解决方案3】：

想象一个函数参数的类型发生变化，而实际大小或基础类型没有变化（例如，从一个枚举到另一个枚举，或者从 long 到 int）。由于类型检查，这会破坏源代码，但可能不会影响二进制兼容性。（取决于具体的环境——.NET 会被惹恼，但 C/C++ 不会。）

【讨论】：