3

ソースの互換性が失われているにもかかわらず、バイナリの互換性が維持されていることを示す例を歓迎します。

4

3 に答える 3

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);

唯一の違いは構造体の名前であり、内部の構造体の型名はコンパイル中に消去されるため、バイナリの非互換性はありません。

于 2009-08-03T01:12:31.650 に答える
0

関数パラメーターの型が、実際のサイズや基になる型を変更せずに変更することを想像してください(たとえば、ある列挙型から別の列挙型へ、またはlongからintへ)。型チェックのためにソースコードが壊れますが、バイナリ互換性には影響しない可能性があります。(正確な環境によって異なります。.NETは煩わしいですが、C / C ++は煩わしくありません。)

于 2009-08-03T00:55:26.000 に答える
0

さまざまなマシンでスタティック リンク ライブラリのバージョンが異なると、マシン A でコンパイルされたバイナリがマシン B で正しく動作する可能性がありますが、マシン B でソースからコンパイルしようとすると失敗します。しかし、それは別として、ソースの非互換性は一般的にバイナリの非互換性を意味します。

于 2009-08-03T00:55:16.840 に答える