問題タブ [binary-compatibility]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
build - VS2008 Proを実行しているx86プラットフォームからx64バイナリにコンパイルするにはどうすればよいですか?
x64プラットフォーム用にアプリ(サードパーティライブラリを使用)をコンパイルしようとしています。ただし、VS2008ProのBuildConfigurationManagerからx64を選択しても機能しないようです。バイナリは作成されますが、クライアントはx64で実行できませんでした。
サードパーティのDLLが原因である可能性があるのではないかと思います。誰かがこれについて何か考えを持っていますか?
java - 汎用コモンズ コレクション
驚いたことに、Apache Commons Collectionsプロジェクトはまだライブラリをジェネリックに対応させていません。このライブラリが提供する機能はとても気に入っていますが、ジェネリックがサポートされていないことが大きな欠点です。Generics をサポートする Commons Collections の Lavalabs フォークがありますが、これは下位互換性を主張しているようですが、このバージョンに更新しようとすると、Web アプリケーションが (JBoss で) 起動できませんでした。
私の質問は次のとおりです。
- 誰かが Commons Collections から上記のフォークに正常に更新したかどうか
- Commons Collections がジェネリックのサポートを追加する計画がある場合
ところで、私は Google のコレクションを認識していますが、API が安定するまで使用することに消極的です。
乾杯、ドン
c++ - コンパイラ間の DLL の互換性
異なるコンパイラでビルドされた C++ dll を相互に互換性を持たせる方法はありますか? クラスは作成と破棄のためのファクトリ メソッドを持つことができるため、各コンパイラは独自の新規/削除を使用できます (異なるランタイムには独自のヒープがあるため)。
次のコードを試しましたが、最初のメンバー メソッドでクラッシュしました。
インターフェイス.h
VC9 でコンパイルされた test.cpp、test.exe
g++ でコンパイルされた a.cpp g++.exe -shared c.cpp -o c.dll
編集: 次の行を GCC CreateClass メソッドに追加しました。テキストはコンソールに正しく出力されたので、関数呼び出しは間違いなくそれを殺します。
COM は、基本的にすべてのクラスが継承されているため (ただし単一のみ)、したがって仮想関数であるため、言語間でもバイナリ互換性をどのように維持するのか疑問に思っていました。基本的な OOP 要素 (つまり、クラスと単一継承) を維持できる限り、オーバーロードされた演算子/関数を使用できなくても、あまり気にしません。
c++ - 新しいメンバ関数を d ポインタ クラスに追加すると、バイナリ互換性が失われますか?
新しいメンバー関数を d ポインター クラス定義に追加すると、バイナリ互換性が失われますか?
たとえば、以下の新しい定義は、元の定義と比較してバイナリ互換性を壊しますか? (副次的な質問ですが、新しい .so が古い .so と比較してバイナリ互換性を損なうかどうかを教えてくれるツールはありますか? そうでない場合、手動で確認するにはどうすればよいですか?)
オリジナル:
新しい:
参考:ヘッダーではなく、ccファイルでdポインタークラスを指定する必要があることを理解しています。上記の例は、バイナリ互換性の問題に焦点を当てるために考案されました。
java - コンストラクタ パラメータ タイプを変更すると、別の jar でクラスが壊れます
私は共通の瓶に次のクラスを持っています:
次に、次のようにコンストラクターのパラメーターを a から a に変更List
しCollection
ます。
共通の jar を再構築してシステムを実行すると、NoSuchMethodError
そのクラスを再コンパイルするまで、コンストラクターを呼び出すときに、依存するクラスで a が発生します。
依存クラスのバイトコードでコンストラクターがどのようにバインドされているかという行に沿って、これを引き起こしている原因についていくつかのアイデアがありますが、100%確信はありません。
ここで何が起こっているのか、誰かに光を当てることができますか?
アップデート
その後、簡単なテストを行い、バイトコードを調べました。
トムが言ったように、13 行目でわかるように、正確なコンストラクターはコンパイル時にバインドされます。
あなたは毎日何か新しいことを学びます:-)
c# - .NET で標準の EventHandler パターンを放棄すると、何が失われますか?
.NET にはイベントの標準パターンがあります。それらは、delegate
sender と呼ばれるプレーンなオブジェクトを受け取る型を使用し、次に .NET から派生する必要がある 2 番目のパラメーターで実際の「ペイロード」を使用しますEventArgs
。
派生元の 2 番目のパラメーターの理論的根拠EventArgs
は非常に明確です ( .NET Framework Standard Library Annotated Referenceを参照してください)。ソフトウェアの進化に合わせて、イベント シンクとソース間のバイナリ互換性を確保することを目的としています。すべてのイベントに対して、引数が 1 つしかない場合でも、その引数を含む 1 つのプロパティを持つカスタム イベント引数クラスを派生させます。これにより、既存のクライアント コードを壊すことなく、将来のバージョンでさらに多くのプロパティをペイロードに追加する機能を保持できます。 . 独自に開発されたコンポーネントのエコシステムにおいて非常に重要です。
しかし、引数がゼロの場合も同じことがわかります。これは、最初のバージョンで引数のないイベントがあり、次のように書くことを意味します。
……では、やり方が間違っています。将来、デリゲート タイプをペイロードとして新しいクラスに変更すると、次のようになります。
... クライアントとのバイナリ互換性を壊します。add_Click
クライアントは、 を受け取る内部メソッドの特定のオーバーロードにバインドされてしまいEventHandler
、デリゲート タイプを変更すると、そのオーバーロードが見つからないため、MissingMethodException
.
では、便利な汎用バージョンを使用するとどうなるでしょうか。
いいえ、まだ間違っています。なぜなら、 anは anEventHandler<ClickEventArgs>
ではないからEventHandler<EventArgs>
です。
したがって、 の利点を得るには、そのまま使用するのではなく、派生するEventArgs
必要があります。そうでない場合は、それを使用していない可能性があります (私にはそう思われます)。
次に、最初の引数sender
. それは不浄なカップリングのレシピのように私には思えます。イベントの発生は、基本的に関数呼び出しです。一般的に言えば、この関数には、スタックを掘り返して呼び出し元を見つけ出し、それに応じて動作を調整する機能が必要ですか? インターフェイスがこのように見えることを強制する必要がありますか?
結局のところ、の実装者は、追加情報を照会できるように、Bar
誰が誰であるかを知りたいと思うかもしれません! caller
私はあなたが今までに吐いていることを願っています。イベントごとに異なる必要があるのはなぜですか?
したがって、EventArgs
宣言するすべてのイベントに対してスタンドアロンの派生クラスを作成するという苦労を覚悟していたとしても、使用するだけの価値があるようにするためにEventArgs
、オブジェクトの送信者引数を削除することをお勧めします。
Visual Studio のオートコンプリート機能は、イベントに使用するデリゲートを気にしないようです。+=
[hit Space, Return]と入力すると、たまたまデリゲートに一致するハンドラー メソッドが書き込まれます。
では、標準パターンから逸脱すると、どのような価値が失われるのでしょうか?
おまけの質問として、C#/CLR 4.0 は、おそらくデリゲートの反変性を介して、これを変更するために何かを行いますか? これを調査しようとしましたが、別の問題が発生しました。私はもともとこの質問の側面を他の質問に含めていましたが、そこで混乱を引き起こしました。そして、これを全部で 3 つの質問に分割するのは少し多すぎるように思えます...
アップデート:
この問題全体に対する反変性の影響について疑問に思ったのは正しかったことがわかりました!
他の場所で述べたように、新しいコンパイラ ルールは型システムに穴を残し、実行時に爆発します。EventHandler<T>
とは異なる定義を行うことで、穴が効果的に塞がれていAction<T>
ます。
したがって、イベントの場合、そのタイプの穴を避けるために、 を使用しないでくださいAction<T>
。それはあなたが使用しなければならないという意味ではありませんEventHandler<TEventArgs>
; ジェネリック デリゲート型を使用する場合は、反変性が有効になっているものを選択しないでください。
c++ - ソースの非互換性は常にバイナリの非互換性を意味しますか?
ソースの互換性が失われているにもかかわらず、バイナリの互換性が維持されていることを示す例を歓迎します。
java - Java でのリファクタリングされたメソッドとバイナリ互換性
メソッドをリファクタリングする場合、Java では (以前のバージョンのコードとの) バイナリ非互換性を簡単に導入できます。
メソッドを変更して、パラメーターの型を親インターフェイスに拡張することを検討してください。
このメソッドを使用するすべてのコードは変更なしで引き続きコンパイルされますが、再コンパイルが必要になります (古いバイナリは MethodNotFoundError で失敗するため)。
メソッドを親クラスにプルアップするのはどうですか。これには再コンパイルが必要ですか?
メソッドは B から親 A に移動されました。また、可視性が保護されたものからパブリックに変更されました (ただし、これは問題ではありません)。
B で「バイナリ互換ラッパー」を維持する必要がありますか、それとも引き続き機能しますか (親クラスに自動的にディスパッチされます)。
c++ - バイナリ互換性を最大化しながら、複数の POD タイプをサポートするために公開 API に推奨される設計は何ですか?
私は現在、コンパイル済みのバイナリ/DLL (クロスプラットフォーム) を必要とする製品向けに、一般向けの C++ API を設計しています。私たちがサポートする任意の POD (該当する場合) をユーザーが使用できるようにする API を希望しますが、基本的な要件は最大限の柔軟性とバイナリ互換性です。私は CPLEX の API に少し似たようなことをしています (これはいくつかのインスピレーションの 1 つです)。しかし、型情報を指定する方法は、彼らが行った方法よりも優れている可能性があると考えています (IloInt、IloNum、IloAny、Ilo* に関して) Var など、リンクを参照(できれば) IloExtractable ブランチの場合) バイナリ互換性を台無しにすることはありません。私が間違っている?私は何かを考えていますが、それが何であるか思い出せません。または、それが機能する場合でも、ビジターまたはデコレーターのパターンのようなものに似ていると思いますが、タイプについては、誰かが私にこの件について教えてもらえますか? 私の目の前に、GoF によるデザイン パターンの本があります。
注: ここにある可能性のある構文エラーは、当面の問題の一部ではありません。
使用できないと思われるものの例とその理由:
おそらく..しかし、これは式ツリーで物事を複雑にする可能性があります。
今後の展開に影響しそうです。
罪のように醜く、多くの微妙な問題を引き起こす可能性があります。
編集: Mads Elvheim に応えて (そしてこのリンクを見つけた後)、テンプレートを自分の可能性から除外する必要がないことに気付きましたが、それが最善のアイデアであるかどうかはまだ確信が持てません - 少なくとも Constraints クラスについては(概念的には健全ですが)思ったほど明確ではないことを許してください。
API を使いやすくするために、bnf を使用して文法を定義しました (これは私にとってかなり新しい方法です)。これにより、式、制約、および制約と相互作用するその他のクラスの抽象構文ツリーが作成されました。他のクラスは Constraints とやり取りするため、いわば「ギリギリ」まで型情報をできるだけ多く渡すことは避けたいと思います.抽象化のレベルが欠けているように感じます。
CPLEX を研究していると、数値 (整数と実数) のドメイン、線形方程式の表現 (もちろん)、およびそれに応じて何が可能になるかに従って型をモデル化したという印象を受けます。
(どうやら私は新しいユーザーなので、複数のリンクを投稿することはできません。)
編集 2: 最初のステップとしてConstraintExpressionArgument
、Constraint クラスと Expression クラスの間に a を挿入することにしました。これにより、操作する型を意識せずに式ツリー内の制約を識別できるようになります。
私が言及しなかったかもしれないもう 1 つの詳細は、Constraint クラスが単独では使用できない CPLEX とは異なり、私の Constraint クラスは現在使用可能なユーザー クラスですが、CPLEX と同様に、拡張の余地も残しておきたいということです (したがって、入力の問題)。 ..
とにかく、現時点では私は同等のものを持っています
java - コードをクリーンアップすると、バイナリ互換性が失われます
私は、知らない多くの人々によって使用されているプロジェクトに取り組んでいます。私たちは CheckStyle の警告を下げるというかなり良い仕事をしており、バイナリ互換性を壊すことなく得ることができるほど低いものです.
残りの警告の大部分は、定数 (public static final) に final キーワードがないことが原因です。定数の命名は、開発者がそれらを読み取り専用にすることを意図していたことを明らかにしていますが、それらには final が定義されていませんでした。
開発者がこの見落としを利用したかなりひどいコードを書いていない限り、それらを追加してもコードが壊れることはありません。
現在のバージョン番号は 1.2.1 です。変更を適用して 2.0 に移行しますか、それとも適用して 1.3 としてロールアウトしますか。完全な 2.0 を必要とするのはかなり小さな変更のようです。
私は何をすべきか?