問題タブ [binary-compatibility]

コンパイラが生成するデフォルトのコンストラクタとデストラクタがインラインであるかどうかに興味があります。どちらの方法でも正当化できるからです。一方では、デフォルトのコンストラクタ/デストラクタをインラインにしないで、後で追加してもABIが破損しないようにします（デフォルトのみが存在するときにコンパイルされたオブジェクトファイルは、定義したものではなく、生成された定義をインライン化するため）。一方、C ++コンパイラがCコンパイラでコンパイルした場合と同様に実行するCコードをコンパイルする場合、割り当てられたすべての構造に対してコンストラクタ/デストラクタ呼び出しを追加することはできません。C++では、クラス間の機能の違いはstructはデフォルトのアクセス保護であると想定されています。たぶんリンカーはこれにどういうわけか対処しますか？たぶん答えはコンパイラによって異なりますか？

この質問の結果：C ++でPOD構造体を使用している場合、デフォルトの代わりに空のインラインコンストラクタ/デストラクタを自分で定義することで、理論的には一部のコンパイラでメリットがありますか？

次のC++コードについて考えてみます。

ここで、このコードがサードパーティアプリケーションによって使用される共有ライブラリに配置されていると仮定します。

私の質問は次のとおりです。X（たとえばint c）の最後に別のメンバーを追加し、で初期化するとfoobar()、を呼び出す既存のアプリケーションはfoobar()壊れますか？これは、ソースの互換性ではなく、バイナリの互換性に関するものであることに注意してください。

私は現在、DLL として配布される Windows 用の C++ ライブラリを開発しています。私の目標は、バイナリの相互運用性を最大化することです。より正確には、DLL の関数は、DLL を再コンパイルすることなく、MSVC++ と MinGW の複数のバージョンでコンパイルされたコードから使用できる必要があります。ただし、どの呼び出し規約が最適か、cdeclまたはstdcall.

「C の呼び出し規則は、コンパイラ間で同じであることが保証されている唯一の規則です」などのステートメントを時々耳にしcdeclます。これは、特定のライブラリ開発者 ( libsndfileなど) が配布する DLL で C 呼び出し規則を使用することを止めるようには見えませんが、目に見える問題はありません。

一方、stdcall呼び出し規約は明確に定義されているようです。私が聞いたところによると、これは Win32 と COM で使用される規則であるため、すべての Windows コンパイラは基本的にそれに従う必要があります。これは、Win32/COM をサポートしない Windows コンパイラはあまり役に立たないという前提に基づいています。フォーラムに投稿された多くのコード スニペットは関数を として宣言していますが、その理由stdcallを明確に説明している 1 つの投稿が見つからないようです。

矛盾する情報が多すぎて、検索を実行するたびに異なる答えが得られます。どちらか一方を選択する必要がある理由 (または 2 つが同等である理由) について、明確で詳細な議論のある説明を探しています。

この質問は、「クラシック」関数だけでなく、仮想メンバー関数呼び出しにも適用されることに注意してください。ほとんどのクライアント コードは、純粋な仮想クラスの「インターフェイス」を介して DLL とやり取りするためです (たとえば、 hereおよびthere で説明されているパターンに従います)。

最初にいくつか紹介します。現在、C++ との互換性に取り組んでいます。これは、異なるコンパイラ オプションを使用してプロジェクトを相互に実行できるようにすることを意味します。したがって、リリース DLL と、その他のプロジェクトにリンクするデバッグ アプリケーションでテストします。問題のほとんどは STL を使用するときに発生するため、両方のプロジェクトが独自のバージョンの STL のみを使用するようにする必要があります。そのため、std::vectors、std::lists などから構築できるが、完全に互換性のある配列のみを含むラッパー クラスがあります。これで、値を配列にラップし、反対側でそれらを有効な STL オブジェクトにアンパックできます。

質問にもう少し近づくために、STL を含むが配列にラップする必要があるクラスがいくつかあります。そのため、内側の STL オブジェクトもラップする必要があります。つまり、タグを追加して、関連する配列要素のすぐ隣に保存します。

このラッパー クラスを構築することはまったく問題ありませんが、展開すると、ここにあるベクター クラスでアクセス違反が発生してクラッシュします。

その時点で実行中のコードは次のとおりです。

それについての奇妙なことは、私は std::list を解凍していますが、std::vector でクラッシュします。std::vector に含まれるクラスがあり、このクラスには STL のないいくつかの基本クラスの std::list が含まれています。したがって、アンパックとは、外側の配列を std::vector にコピーし、すべての内側の配列を std::list にコピーすることを意味します。

このエラーは、さまざまなコンパイラ オプションを使用した場合にのみ発生します。まったく同じプロジェクトでのパックとアンパックは正常に機能します。

何もわからないので、誰かが私を助けてくれることを本当に願っています。

よろしく

j2me Polish を使用して、複数のハンドセットで実行される jar ファイルを 1 つだけ持つことは可能ですか?

基本的に、バイナリ互換性が必要であり、ハンドセットごとに異なるビルドは必要ありません。同時に、優れた UI が必要です。

3 つの optino 1. lwuit、2. 研磨、3. カスタム開発があり、研磨を使用したかったのですが、最初のハックが示されているため、別のデバイス用にビルドする必要があります。

手がかり/ポインターはありますか？

ラクシット

バイナリ互換性の問題が発生することなく、純粋仮想関数（基本クラス内）を非純粋になるように変更できますか？（Linux、GCC 4.1）

ありがとう

疑問に思っていることを検証する必要があります。共有ライブラリ (.dll) が C で記述され、C99 標準を使用し、コンパイラでコンパイルされている場合。MinGwと言います。次に、私の経験では、バイナリ互換性があるため、他のコンパイラから使用できます。MS Visual Studio と言います。私はそれを何度も成功させたので、私の経験で言います。しかし、これが規則であるかどうかを確認する必要があります。

さらに、それが本当にそうであるかどうかを尋ねたいのですが、たとえば openCV のように完全に C で記述されたライブラリが、さまざまな OS ごとにコンパイルされたバイナリを提供しないのはなぜですか? 明らかな理由は、すべてのコンパイル時のパラメーターを設定することであることは知っていますが、それ以外には何もありませんか?

編集：元の論理的な拡張として私が見る追加の質問を追加しています。これは、クローズド ソース ライブラリを作成する方法ではありませんか? ソースを提供するという選択肢はありえないので、バイナリを提供することが唯一の選択肢です。その場合、できるだけ多くのアーキテクチャーにバイナリーを提供することが望ましい結果であり、システムとコンパイラーの間で最高の移植性を得るには C が当然の選択です。右？

.NETにプラグインシステムを実装しました。ベースライブラリは、プラグインに公開された基本的なクラスとインターフェイスを実装します。プラグインライブラリは、公開されたクラスとインターフェイスを使用するためにベースライブラリをリンクします。

私が直面している問題は、ベースライブラリの（単純な）再コンパイル（変更の有無にかかわらず）により、プラグインをロードできず、例外メッセージが表示されることです。

この問題は、ベースライブラリとプラグインライブラリを一度にコンパイルすることで解決されますが、このフェーズではベースライブラリを頻繁に変更するため、開発中はあまり快適ではありません。

バイナリマッチングを「緩和」する方法はありますか？

ベースライブラリアセンブリ情報（以下に引用）が問題の原因である可能性はありますか？

アセンブリが署名されていることを忘れました。

アセンブリは、次のルーチンを使用してロードされます

私はCライブラリを作成した経験がありますが、そのようなライブラリを作成している間、グッドプラクティスを説明する正式なドキュメントを読んだことはありません。私の質問は主に2つのトピックに関係しています。

1. バイナリ互換性を維持する方法は？（pImplイディオム、dポインターについて聞いたことがあります）
2. 下位互換性を維持するインターフェイスを設計するにはどうすればよいですか？

私の研究からわかるバイナリ互換性の主な点は、pImplイディオムを使用してライブラリをバイナリ互換にすることができるということですが、構造を変更したり、新しいデータメンバーを追加したりすると、pImplを使用している場合でもバイナリ互換性に影響を与える可能性があります。また、バイナリ互換性を実際に壊すことなく、ライブラリに新しいメソッド/関数を追加する方法はありますか？これらを追加すると、ライブラリのサイズやレイアウトが変更され、互換性が失われると思います。

バイナリ互換性をチェックするツールはありますか？

私はすでにこれらの記事を読みました。他に閲覧できるドキュメントはありますか？

http://en.wikipedia.org/wiki/Opaque_pointer

http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++

また、ライブラリインターフェイスの設計のコンテキストでメモリの所有権の問題を説明する記事があります。一般的な規則は何ですか？誰がどのくらいの期間メモリを所有し、誰がメモリの割り当てを解除する責任がありますか？

共有ライブラリ（またはWindowsのDLL）としてコンパイルできるライブラリがあります。別のライブラリの別のクラスから派生したクラスがあります。基本クラスにはいくつかの仮想メソッドがあり、私のクラスはそれらのいくつかをオーバーライドします。例えば：

ここで、仮想メソッドの1つが私のクラスでは完全に機能しないことがわかりました。現在、このメソッドをオーバーライドしていないので、動作を修正するためにもオーバーライドしたいと思います。

これにより、古いバージョンのライブラリとのバイナリ互換性が失われますか？

私が理解している限りでは、vtable内の仮想メソッドの数と順序は同じままであるため、仮想関数を追加するだけではありません。唯一の違いは、クラスのvtableの特定のエントリに異なる値が含まれるようになることです。これは正しいです？

また、現在私のライブラリを使用しているアプリケーションはどれもそのメソッドを使用していないと確信しています。これは、完全に壊れており、機能しないためです。したがって、基本メソッドの実装に対する既存の呼び出しを壊すことについて心配する必要はありません。他に何も壊さないようにしたいと思います。