問題タブ [binary-compatibility]

DLL内のこの列挙型を想像してみてください。

列挙値を追加すると、バイナリ互換性が失われますか？変更した場合、既存のEXEは壊れますか？

私はこの答えを見ましたが、それは値を挿入する場合に対処しているようでした。最後だけに値を追加しても大丈夫ですか？

Debian安定版（x86）専用に特別に開発されたC++アプリケーションがいくつかあります。

現在、これらのアプリケーションの開発もDebian安定版（x86）システムを使用して行われているため、開発者はターゲットシステムと同じライブラリバージョンをすべて使用できます。
ときどき、これらのコンポーネントで作業する必要があり、非常に古いバージョンのKDevelop（4.0.1と最新の4.4.1）で立ち往生していることに悩まされ続けます。開発に最新のシステム（最新のUbuntuやDebianテストなど）を使用したいのですが、ターゲットシステムに適したバイナリを作成するにはどうすればよいですか？
ターゲットプラットフォームでのみ使用可能なライブラリバージョンを使用するようにコンパイラ/リンカーに指示する簡単な方法はありますか？
私はEmdebianを見ましたとそれらのクロスコンパイルパッケージですが、これは私にはうまくいかないと思います。ARMのような他のアーキテクチャをターゲットにするためのパッケージしかないようです。

すぐに行きましょう：

古いコード:

新しいコード:

明らかに、ここで問題はないはずです。古い戻り値の型で行っていたすべてのことは、新しい戻り値の型で引き続き行うことができます。 any is、asまたはキャストは以前と同じように動作する必要があります...

バイナリ互換性を壊したのでしょうか、それともユーザーに迷惑をかけずにマイナー バージョンとしてリリースすることはできますか?

多くの静的メンバーを持つクラスがありますが、ヘッダー ファイルの途中に新しい関数を追加しました。

これはバイナリ互換性を壊しますか? クライアントを再コンパイルする必要がありますか?

編集 (1) : クラスには静的関数のみがあり、他の関数やデータ メンバーはありません

Now, I know it is generally bad to add new virtual functions to non-leaf classes as it breaks binary compatibility for any derived classes which haven't been recompiled. However, I have a slightly different situation:

I have an interface class and implementation class compiled into a shared library, for example:

My main application uses this shared library, and could basically be written as:

In other words, the application doesn't have any classes which derive from Interface, it merely uses it.

Now, say I want to overload Foo( uint16_t arg ) with Foo( uint32_t arg ), am I safe to do:

and recompile my shared library without having to recompile the application?

If so, are there any unusual caveats I need to be aware of? If not, do I have any other options other than to take the hit and up-version the library, thus breaking backwards compatibility?

VB6 DLL の 1 つを再構築しようとすると、次の警告が表示されます。

「バイナリ互換の DLL または EXE に、定義が見つからないパラメーターの型または戻り値の型が含まれています」

選択した DLL でいくつかの変更をリリースする必要があります (メソッド内部の単純な変更 -これによると、互換性を損なうものは何もありません)

私が従った一般的に受け入れられている方法は、古い DLL を別の共有ディレクトリに保持し、新しい DLL を作成している間に、バイナリ互換性を古い DLL セットに設定してコンパイルすることです。これは、新しい DLL を登録するときに GUID を変更しないようにするためです。これらの GUID は、リリース中に干渉しなかった他の DLL の参照として使用されます。

バイナリ互換性ルール (署名、パブリック メソッド、変数などの変更はありません) を破るために何も追加していないと確信しています。なぜこのエラーが発生するのですか?

基本的なことをチェックしないことで、私は初心者ですか？朝から頭をかく。どんな助けでも大歓迎です。

編集:私の署名に変更がある場合、コードを比較せずに知る方法はありますか?

クラス定義のプライベート部分で何かが変更されたという理由だけで、パブリック ヘッダー ファイルを含むすべての再コンパイルを回避したいと考えています。PIMPL以外のオプションを調査しています。

これは私が試したものです：

クラス A を含むライブラリを作成しました。

A_p.hには、クラス A のプライベート部分が含まれています

ああ、公開ヘッダー ファイル:

A.cpp

次に、パブリック ヘッダー (Ah) と .lib ファイルに対するリンクを含む Win32 コンソール プロジェクトを作成しました。

すべてが機能しているように見えますが、途中で落とし穴がないか疑問に思っています。誰でもこれについて詳しく説明できますか？

私の読書std::unique_ptrは、それが（他のスマートポインターとともに）プロジェクト内のポインターにとって間違いなく最良の選択であることを私に確信させました（特に、最適化コンパイラーが std::unique_ptr からすべてのランタイムコストを削除した後）、しかし私はインターフェイスで何をするかについてはまだわかりません。私はさまざまな C++ ABI がどのように機能するかを完全には理解していないので、これがばかげた質問である場合はご容赦ください。ただし、ポインターを取得または返す関数、ポインター メンバーを持つクラス/構造体などは、unique_ptr(たぶんunique_ptrrefsを使用していますか？）再コンパイルを必要とせずに？C コードは、簡単に使用して C++ インターフェイスと対話できますunique_ptrか?