欢迎使用任何示例来证明源兼容性已被破坏但二进制兼容性仍然存在。
答案 0 :(得分:5)
旧版本:
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);
由于唯一的区别是结构的名称,并且内部结构的类型名称在编译期间被擦除,因此没有二进制不兼容。
答案 1 :(得分:0)
各种机器上的不同版本的静态链接库可能导致在机器A上编译的二进制文件在机器B上正常工作,但是尝试从机器B上的源代码编译它失败。但除此之外,源不兼容通常意味着二进制不兼容。
答案 2 :(得分:0)
想象一下,函数参数的类型在没有实际大小或基础类型更改的情况下更改(例如,从一个枚举到另一个枚举或从long到int)。由于类型检查,这会破坏源代码,但可能不会影响二进制兼容性。 (取决于确切的环境 - .NET会烦恼,但C / C ++不会。)