問題タブ [library-design]

IList<T>は継承IListしません。IEnumerable<out T>IEnumerable

out修飾子が唯一の理由である場合、 IList<T>(たとえばCollection<T>、List<T>)の実装のほとんどがIListインターフェイスを実装する理由です。

したがって、そのステートメントが のすべての実装に当てはまる場合は、必要に応じIList<T>て直接キャストすることができIListます。ただし、問題はIList<T>継承しないIListため、すべてのIList<T>オブジェクトがIList.

さらに、修飾子がないとジェネリックを継承の少ないクラスに割り当てることができないIList<object>ため、使用は明らかに解決策ではありません。outList の新しいインスタンスを作成することは、ここでは解決策ではありません。これは、ポインターIList<T>としての実際の参照が必要な場合があるためです。IListuse List<T>insteed ofIList<T>は、実際には悪いプログラミング手法であり、すべての目的に役立つわけではありません。

IList<T>.NET が、すべての実装に非ジェネリック実装のコントラクト (つまり) を持たないという柔軟性を与えたい場合IList、なぜジェネリック バージョンと非ジェネリック バージョンの両方を実装する別のインターフェイスを保持せず、すべてが具体的であることを示唆しなかったのかジェネリックおよび非ジェネティック アイテムの契約を希望するクラスは、そのインターフェイスを介して契約する必要があります。

とICollection<T>へのキャストでも同じ問題が発生します。ICollectionIDictionary<TKey, TValue>IDictionary

std::this_thread 名前空間に技術的な理由はありますか? この名前空間のメンバーが std::thread クラスの静的メンバーとして実装されていないのはなぜですか?

私は現在、カプセル化の標準的な手法として不透明なポインターを使用していますが、OpenGL API を見ると、id 番号を使用する方が良い選択である可能性があると思います。ベテランの C プログラマーからのアドバイスをお願いします (この言語を積極的に使用してから 2 年ほどしか経っていません)。

確認または修正したい私の最初の考えは次のとおりです。

ID 番号の考えられる利点:

• ID番号を使用する場合、実装でオブジェクト/メモリプールを使用するのはかなり簡単です

• ID 番号はシステム メモリにマップする必要はありません (GL の場合はグラフィックス メモリを参照できます)。

ID 番号の考えられる短所:

• 実装が少し複雑になります

共有ライブラリを使用する状況を考慮した同様の質問があります: 不透明なオブジェクトに整数 ID またはポインターを使用する必要がありますか? 私の質問は共有ライブラリに関するものではなく、ユーザー コードから実装の詳細を隠す一般的なケースに関するものです。

MyObjectHandle を typedef して、ライブラリが ID 番号と不透明なポインターを切り替えることができると思います。

問題は 、不透明なポインターと C プログラミング言語を使用した ID 番号の長所と短所は何ですか?

C# .NET Framework 4.0 ライブラリを開発しています。

私はこのコードを持っています:

cmd.ExecuteScalar();null を返すこともできますが、Convert.ToByte(o);0 を返します。

cmd.ExecuteScalar();探している値はデータベース上にある必要があるため、 null を返す場合はエラーです。その値がデータベースにない場合はエラーです。

ここで何をしますか？null を返すか、例外をスローしますか?

現在ヘッダーのみのC++ ライブラリをいくつか作成しました。私のクラスのインターフェースと実装の両方が同じ.hppファイルに書かれています。

私は最近、この種のデザインはあまり良くないと考え始めました。

1. ユーザーがライブラリをコンパイルして動的にリンクしたい場合、それはできません。
2. コードの 1 行を変更するには、ライブラリに依存する既存のプロジェクトを完全に再コンパイルする必要があります。

私はヘッダーのみのライブラリの側面を本当に楽しんでいます#include.

両方の長所を活かすことは可能ですか? つまり、ユーザーがライブラリをどのように使用したいかを選択できるようにします。ばかげたコンパイル時間を避けるために「動的リンク モード」でライブラリに取り組み、パフォーマンスを最大化するために完成品を「ヘッダーのみモード」でリリースするので、開発もスピードアップします。

論理的な最初のステップは、インターフェイスと実装.hppを.inlファイルに分割することです。

とはいえ、先に進む方法はわかりません。多くのライブラリLIBRARY_APIが関数/クラス宣言の先頭にマクロを追加するのを見てきました.ユーザーが選択できるようにするために、おそらく同様のものが必要でしょうか?

「...の複数定義」エラーを回避するために、すべてのライブラリ関数にinlineキーワードのプレフィックスが付けられています。キーワードはファイル内のマクロに置き換えられると思いますか? マクロは、「ヘッダーのみモード」の場合は解決され、「動的リンク モード」の場合は何も解決されません。LIBRARY_INLINE.inlinline