C＃リストに追加するときにエントリの最大数が2 ^ 31-1（？）に達していないことを明示的にチェック/処理することは、狂気です。
（これは、リストの平均サイズが100未満のアプリであると想定しています。）
1372 次
8 に答える
4
1.メモリ制限
さて、プロパティのないSystem.Objectのサイズは8バイト（2x32ビットポインタ）、または64ビットシステムでは16バイトです。[編集：]実際、WinDbgをチェックインしたところ、サイズはx86（32ビット）で12バイトです。
したがって、32ビットシステムでは、24Gb RAMが必要になります（32ビットシステムでは使用できません）。
2.プログラム設計
私は、そのような大きなリストをメモリに保持するのではなく、他の記憶媒体に保持する必要があると強く信じています。ただし、その場合は、リストをラップするキャッシュクラスを作成するオプションが常にあります。これにより、実際のストレージが内部で処理されます。したがって、追加する前にサイズをテストすることはテストを行うのに間違った場所です。ある日必要であるとわかった場合は、リストの実装がそれ自体を行う必要があります。
3.安全を確保する
スタックオーバーフローを防ぐために、各メソッド内に再入可能カウンターを追加してみませんか？:)
だから、はい、それをテストするのはクレイジーです。:)
于 2009-04-23T09:56:41.553 に答える
2
過剰なようです。リスト内のオブジェクトのサイズに応じて、最初にマシンのメモリ制限に達しませんか？（このチェックはListクラスのユーザーによって実行され、実装ではチェックされないと思いますか？）
おそらく、同僚が先を考えているのは安心ですか？（皮肉！）
于 2009-04-23T09:50:35.950 に答える
1
そう思われるでしょう、そして私はおそらくチェックを含めないでしょうが、私はこれについて矛盾しています。プログラマーはかつて、コードの予想される寿命には問題がなかったという理由で、日付フィールドの年を表すのに2桁で十分でしたが、この仮定が正しくないことがわかりました。
リスクを見て、努力を見て、判断を下します（そうでなければ、知識に基づいた推測として知られています！:-)）。これには厳しいルールや速いルールがあるとは言えません。
于 2009-04-23T09:51:55.323 に答える
0
上記の答えのように、私はそれについて心配するよりも多くのことがうまくいかないだろうと思います。しかし、コードが輝くまで磨くことができる時間と傾向があれば、そうです！
于 2009-04-23T09:52:12.500 に答える
0
真
（まあ、あなたは本当か間違っているか尋ねました。）
于 2009-04-23T09:55:51.787 に答える
0
このコードを試してみました：
List<int> list = new List<int>();
while (true) list.Add(1);
System.OutOfMemoryExceptionが発生しました。では、これをチェック/処理するにはどうしますか？
于 2009-04-23T09:58:28.380 に答える
0
リストにアイテムを追加し続けると、その制限に達するずっと前にメモリが不足します。「長い」とは、「あなたが思っているよりずっと早く」という意味です。
ラージ オブジェクト ヒープ (LOB)に関するこの説明を参照してください。約 21500 要素 (64 ビット システムの半分) に達すると (オブジェクト参照を格納していると仮定して)、リストは大きなオブジェクトになり始めます。LOB は通常の .NET ヒープと同じ方法で圧縮されないため、最終的には、十分な大きさの連続メモリ領域を割り当てることができないほどひどくフラグメント化されます。
したがって、その制限をまったくチェックする必要はありません。これは実際の制限ではありません。
于 2009-04-23T10:06:14.617 に答える
0
はい、それは狂気です。
これらの数値に到達し始めると、コードの残りの部分がどうなるかを考えてみてください。リストに何百万もの項目がある場合でも、アプリケーションは使用できますか?
アプリケーションがその量のデータに達する可能性がある場合でも、代わりに、リストがそれほど大きくならないように対策を講じる必要があります。おそらく、一度にすべてのデータをメモリに保持するべきではありません。どんなコードでも実際にこれほど多くのデータを利用できるシナリオを想像することはできません。
于 2009-04-23T10:07:08.407 に答える