APIを設計するとき、詳細（実行中のプロセスなど）を自分のカスタム構造体に保持したい場合があります。ただし、これを複数のプロセスに対して行う場合、つまり複数の構造体が必要な場合は、構造体の配列、または各プロパティ（startTime、processName、その他のプロセスプロパティなど）の配列を持つ1つの構造体が必要です。に興味がある）。
パフォーマンスとAPI/クラスライブラリのどちらが優れていますか？
ありがとう
4 に答える
2
私見では、すべての構造体をインスタンス化するためにパフォーマンスが低下したにもかかわらず、一連の構造体を実行する必要があります。1つの構造体に格納されている1つの状態の組織的な意味は、パフォーマンスの低下をはるかに上回ります。1つの構造体を多数の配列で使用し、各プロセスに複数の配列のインデックスを割り当てるだけでは、非常に面倒で、デバッグが非常に困難になる可能性があります。 。
于 2010-02-18T16:17:24.317 に答える
1
classではなくを使用することを検討してくださいstruct。クラスのリストを使用します。
于 2010-02-18T16:15:46.143 に答える
0
Eric Lippertは、APIで配列を使用することに反対するいくつかの議論をしています。私にとってより魅力的なのは、コレクションのサイズを固定したまま、コンシューマーがコンテンツを変更できるようにする理由です。あなたはここでもっと見ることができます。
最終的には、配列を使用してそれらを内部的に保存することもできますが、APIを介してこれを公開することは避けます。列挙する必要がある場合は、代わりにIEnumerable<T>を使用してください。
于 2010-02-18T16:20:15.053 に答える
0
データストレージの観点から、連続するアイテムのグループから特定の部分にアクセスするよりも頻繁にアイテムのすべての部分にアクセスする場合は、構造体の配列を使用するとキャッシュ動作が向上します。
さらに興味深い質問は、データを公開する方法です。構造体をインデクサーとして公開する場合、構造体のフィールドを変更したい人は、構造体を読み取り、一時コピーのフィールドを変更して、書き戻す必要があります。メソッドを公開して個々のプロパティを読み書きすることもできますが、「foo.setBar（100、23）」は「foo（100）.Bar=23」よりも自然ではないようです。後者の構文を許可しすぎると、インデクサーが2つのプライベートフィールド「root」と「index」、および構造体の各フィールドのプロパティを持つ構造体を返すようにすることをお勧めします。たとえば、インデクサーのBarプロパティのセッターroot.setBar（index、value）を実行します。インデクサーには、構造体全体を取得/設定するための「asWhateverStructType」プロパティも必要です。
于 2011-01-25T17:09:09.843 に答える