問題タブ [binary-compatibility]

タスク:開発者が使用するライブラリを設計しています。

目的:将来のバージョンでの変更が既存の開発者に影響を与えないようにする必要があります。

例：

最初のリリース時の状況:

1クラスあります

2 回目のリリース中の状況:

要件：

methodSample のレスポンスは、複数の値を返すことができます。

methodSample メソッドにはさらにパラメーターが必要です。

解決策: 1 つの方法は、組み込みのデータ型ではなく、新しいパラメーターを持ち、オブジェクトを返す別のオーバーロードされたメソッドを追加することです。

しかし、上記の解決策の問題点は、将来オーバーロードされたメソッドが多すぎて、パラメーターが多すぎてやり過ぎになることです。

変更されたソリューション 1:

各リリースで (明らかに必要な場合)、Request & Response クラスを変更して、値を取得/設定するための新しいメソッドを追加します。この場合、メソッド内で問題が発生します。呼び出し元が Version10 か Version20 かを区別できません。

変更されたソリューション 2:

各リリースでは、Request200 が Request100 が AbstractRequest を拡張するように、派生クラスを拡張できます。これは、応答クラスについても同様です。この場合、インスタンスの型を確認することで、呼び出し元が Version10 か Version20 かをメソッド内で確認できます。

要約すると、変更されたソリューション 2 は私には良さそうですが、あなたの考えはどうですか?

ライブラリは、クラスに仮想関数を提供します。ライブラリに動的にリンクされたバイナリを再コンパイルせずに、このクラスを新しい仮想関数で拡張できますか？

これは標準では不可能だと思います。これを可能にするプラットフォームはありますか？

新しい関数がクラス本体の最後にのみ追加された場合、それは簡単でしょうか？

私はQtdポインターについての詳細を読んでいて、バイナリ互換性の用語に出くわしました。これは下位互換性と同じですか？

C++ で DLL を作成し、std::vector パラメータを取るメソッドをエクスポートしたいとします。異なる STL バージョン間のバイナリ互換性を期待できますか?

c ++プログラムを別のバージョンのVisualStudioで構築されたダイナミックライブラリ（DLL）にリンクすると、バイナリ互換性の問題のために機能しないことを知っています。（私はBoostライブラリとVS 2005および2008でこれを経験しました）

しかし、私の質問は次のとおりです。これは、MSVSのすべてのバージョンに当てはまりますか？これは静的ライブラリ（LIB）にも当てはまりますか？これはGCCとLinuxでも問題ですか？そして最後に、VSでMinGWで構築されたDLLにリンクするのはどうですか？

ちなみに、クロスプラットフォームやクロスコンパイラ以外に、同じコンパイラ（VS）の2つのバージョンが互換性を持たないのはなぜですか？

私は、そのユーザー（同じプロセスに存在する他のライブラリ）がデータバッファーとストリームを交換できるようにするライブラリに取り組んでいます。ライブラリは、MSVCコードとmingwコードの両方から使用できる必要があります（互換性を高めても問題はありませんが、厳密には必要ありません）。これを実現するには、コア機能を小さなコンパイラ互換インターフェイスから提供する必要があります。このインターフェイスは、クライアントコードでコンパイルされるコンビニエンスレイヤーによって後で隠すことができます。

ライブラリの難しい点は、クライアントが独自のバッファとストリームの実装を提供できるように拡張可能である必要があることですが、コアライブラリインターフェイスは、リリースされた後も安定している必要があります。さらに背景に興味がある場合は、フォーラムのスレッドディスカッションでそれについて読むことができます。

コンパイラ間のバイナリ互換性の問題について学ぼうとしましたが、このトピックに慣れていないので、結果についてのコメントに興味があります。私はここで標準で定義された動作には興味がありません（構造体はおそらくそのテストに失敗します）。mingwとMSVC、そして可能であれば他のコンパイラとの互換性にのみ興味があります。

特に、構造体は互換性がありますか？それらは一様に関数ポインタで構成されているので、パディングが問題になることはないと思います。さらに、ここではstdcall規約が必要ですか、それともcdeclも同様に機能しますか？両方のコンパイラがデフォルトでcdeclになるので、指定しないでおくことはできますか？するべきか？これが私が今持っているものです：

編集：これが意図されていたプロジェクトはしばらくの間保留されており、再び棚上げされない場合はおそらく多くの再考が必要です。私はまだ答えに興味があるので、私は質問を残しています。

I am trying to make a DLL file compatible with different compiler configurations (Debug, Release,..). In order to make sure that an object is removed the right way I managed to write a pointer wrapper class that uses a compiled delete operator whenever I take an object of the DLL and run out of scope.

I am perfectly fine with this but my program crashes when I try to delete memory that I allocated in the very same method/program.

Here is some sample code compiled in a standard Release mode:

header

source code

Note: API is defined as export/import.

Now I use this very class in a Debug mode application where I create an instance and delete it right away.

Executing the delete operator gives an access violation at mlock.c line 376.

Here is a copy of the callstack:

I can't jump into that line or anything but I managed to get a look at the Assembler code which proves my observation that it has to do with the destructor.

Is there a general problem with virtual functions/destructors when trying to make a DLL compatible?

少なくとも mingw と msvc++ の間でバイナリ互換でなければならない API を設計しています。これまでのところ、プリミティブ データ型または均一なメンバーを持つ POD 構造体へのポインターを取得して返す関数の使用に制限してきました (つまり、メンバーはすべて同じ型であり、互換性のないパディングのリスクを軽減する必要があります)。

ただし、呼び出し先が一時コピーを保持する必要がないように、構造体を値で返すと便利な場合があります。質問は次のとおりです。呼び出し先が呼び出し元とは異なるコンパイラによってコンパイルされた場合、stdcall 関数との間で値によって構造体を渡すことは安全ですか? これは、msvc と mingw の最近のバージョンよりも古いバージョンでも有効ですか? 私はそうであることに自信を持っていますが、このトピックは、明らかに mingw 4.6 でのみ解決された cdecl 呼び出し規約を使用したこの正確な状況の問題を議論しているのを見つけました。

別のLinuxでコンパイルされたバイナリを実行する方法はありますか？もちろん、それを別のマシンで再構築するのが最も簡単なことは知っていますが、取得できるのはバイナリファイルだけだと仮定しましょう。それで、それは可能かどうか。（おそらくそれは簡単ではないことを私は知っていますが、私はただ興味があります）。

下位互換性 (主にバイナリ互換性) を損なう変更またはコード進化は何ですか? どこでも完全に指定されていますか？

Scala 言語仕様を確認しましたが、 Java 言語仕様 Chのような問題に関するセクションは見当たりませんでした。13 バイナリ互換性。