リストが利用可能なときに配列を使用する理由はありますか？[閉まっている]

List<T>C＃では、配列でできることはすべて実行できるように思われます。また、配列と同じくらいメモリとパフォーマンスが効率的であるようです。

それでは、なぜ配列を使用したいのでしょうか？

APIや他の外部制約（メイン関数など）で配列を使用する必要がある場合については明らかに質問していません...自分のコードで新しいデータ構造を作成することについてのみ質問しています。

仕事に行くときにトラックを運転しないのと同じ理由。機能を使用しないものは使用しません。

まず、配列はプリミティブな構造であるため、配列は確かにList <>よりも高速で効率的であるため、引数は正しくありません。配列はどこでも利用でき、さまざまな言語とプラットフォームを使用する開発者に知られています。

List <>の代わりに配列を使用する最も重要な理由は、データが固定長であることを意味するためです。そのデータコレクションにアイテムを追加または削除しない場合は、タイプがそれを反映していることを確認する必要があります。

もう1つは、新しいデータ構造を実装していて、それに関するいくつかの論文を読んだとしましょう。現在、特定のアルゴリズムを実装している間、他の誰かの汎用タイプの実装に常に頼ることはできません。.NETからMonoに変更され、フレームワークの異なるバージョン間でも変更されます。

また、フレームワーク依存型の代わりに配列を使用するコードを移植する方が簡単な場合があります。

もちろん、可変構造体のコレクションを管理するには配列が必要であり、それらがなければ何をするでしょうか。

struct EvilMutableStruct { public double X; } // don't do this

EvilMutableStruct[] myArray = new EvilMutableStruct[1];
myArray[0] = new EvilMutableStruct()
myArray[0].X = 1; // works, this modifies the original struct

List<EvilMutableStruct> myList = new List<EvilMutableStruct>();
myList.Add(new EvilMutableStruct());
myList[0].X = 1; // does not work, the List will return a *copy* of the struct

（可変構造体の配列が望ましい場合もありますが、通常、配列内の可変構造体と他のコレクションのこの異なる動作は、回避すべきエラーの原因です）

さらに深刻なのは、参照によって要素を渡したい場合、配列が必要なことです。すなわち

Interlocked.Increment(ref myArray[i]);  // works
Interlocked.Increment(ref myList[i]);   // does not work, you can't pass a property by reference

これは、ロックフリーのスレッドセーフコードに役立ちます。

固定サイズのコレクションをデフォルト値で迅速かつ効率的に初期化するには、配列が必要です。

double[] myArray = new double[1000]; // contains 1000 '0' values
                                     // without further initialisation

List<double> myList = new List<double>(1000) // internally contains 1000 '0' values, 
                                             // since List uses an array as backing storage, 
                                             // but you cannot access those
for (int i =0; i<1000; i++) myList.Add(0);   // slow and inelegant

（同じことを行うListのコンストラクターを実装することも可能です。c＃がこの機能を提供していないだけです）

コレクションの一部を効率的にコピーする場合は配列が必要です

Array.Copy(array1, index1, array2, index2, length) // can't get any faster than this

double[,] array2d = new double[10,100];
double[] arraySerialized = new double[10*100];
Array.Copy(array2d, 0, arraySerialized, 0, arraySerialized.Length);
// even works for different dimensions

（これもListに実装できるものですが、この機能はc＃には存在しません）

それでは、なぜ配列を使用したいのでしょうか？

まれに、一定数の要素が必要なことがわかっているシナリオがあります。設計の観点から、これは避けるべきです。3つのものが必要な場合、ビジネスの性質上、次のリリースでは4つが必要になることが非常に多くあります。

それでも、このまれなシナリオが実際に発生する場合、配列を使用してその固定サイズの不変条件を強制すると便利です。固定サイズであるというシグナルを他のプログラマーに提供し、誰かが要素を追加または削除する誤用を防止するのに役立ちます-コードの他の部分の期待を破ります。

あなたの質問は実際に以前にすでに答えられました。

また、メモリやパフォーマンスにおいてもアレイと同じくらい効率的です。

そうではありません。私がリンクした質問から：

List/foreach:  3054ms (589725196)
Array/foreach: 1860ms (589725196)

特定の重要なケースでは、配列の速度は2倍です。私は、メモリ使用量も重要な違いがあると確信しています。

あなたの質問の主な前提はこのように破られているので、私はこれがあなたの質問に答えると仮定しています。これに加えて、Win32 API、GPUのシェーダー、またはその他の非DotNetライブラリによって配列が強制される場合があります。

DotNet内でも、一部のメソッドは配列（などString.Split）を消費したり返したりします。どの手段あなたが今、呼び出しのコストを食べる必要がありますどちらかToListとToArrayすべての時間を、またはあなたはおそらくの貧しい下流のユーザーにこれを伝播させることによって、サイクルを続け、配列に適合して使用する必要がありますあなたのコード。

このトピックのスタックオーバーフローに関するその他の質問と回答：

• 配列対List<T>：どちらを使用するか
• なぜ他のデータ構造の代わりに配列を使用するのですか？
• 配列を使用する方が良いList<>ですか？

他の回答に記載されている理由に加えて、配列リテラルは宣言するのに必要な文字が少なくなります。

var array = new [] { "A", "B", "C" };
var list = new List<string>() { "A", "B", "C" };

代わりに配列を使用Listすると、（1）IEnumerable<T>リテラルを渡す必要がある場合、または（2）のその他の機能がList重要ではなく、リストのようなものを使用する必要がある場合に、コードを少し短くして読みやすくしますリテラル。

私は時々単体テストでこれを行いました。

これは厳密にオブジェクト指向の観点からです。

配列だけを渡す理由は考えられませんが、おそらくクラス内部の配列表現がおそらく最良の選択である状況を見ることができます。

同様の特性を提供する他のオプションがありますが、処理順列、ネストされたforループ、マトリックス表現、ビットマップ、データインターリーブアルゴリズムを処理する問題の配列ほど直感的ではありません。

マトリックス数学に広範囲に依存している科学分野が相当数あります。（例えば、画像処理、データ誤り訂正、デジタル信号処理、一連の応用数学問題）。これらのフィールドのほとんどのアルゴリズムは、多次元配列/マトリックスの使用に関して記述されています。そのため、アルゴリズムのベースとなっている論文との直接的な結び付きを失うことを犠牲にして、アルゴリズムをより「ソフトウェア」にフレンドリーにするのではなく、定義されたアルゴリズムを実装する方が自然です。

私が言ったように、これらのケースではおそらくリストの使用を回避できますが、それはすでに複雑なアルゴリズムの上にさらに別の複雑さの層を追加します。

これは、実際にはリストを持つ他の言語（JavaやVisual Basicなど）にも当てはまります。メソッドがリストではなく配列を返すため、配列を使用する必要がある場合があります。

実際のプログラムでは、配列が頻繁に使用されるとは思いませんが、データが固定サイズであることがわかっていて、配列を使用することで得られる小さなパフォーマンスの向上が好きな場合があります。リストを返すメソッド、または多次元データ構造の必要性と同様に、マイクロ最適化は正当な理由です。

まあ、私は書いているゲームで配列の使用を見つけました。固定数のスロットを持つインベントリシステムの作成に使用しました。これにはいくつかの利点がありました。

1. どのスロットがnullであるかを見て、ゲームオブジェクトに開いているインベントリスロットの数を正確に知っていました。
2. 各アイテムがどのインデックスに含まれているかを正確に知っていました。
3. まだ「型付き」配列（Item [] Inventory）であったため、「Item」型のオブジェクトを追加/削除できました。

インベントリのサイズを「増やす」必要がある場合、古いアイテムを新しいアレイに転送することでそれができると考えましたが、インベントリは画面スペースによって固定されており、動的に大きくする必要はありませんでした/より小さい、それは私がそれを使用していた目的のためにうまくいきました。

リストのすべての要素をトラバースする場合、いいえ、配列は不要です。「次」または任意の「置換なしの選択」で問題ありません。

ただし、アルゴリズムがコレクション内の要素へのランダムアクセスを必要とする場合は、はい、配列が必要です。

これは、「gotoが必要ですか？」にやや似ています。合理的な現代言語では、まったく必要ありません。しかし、ある時点で抽象化を剥がすと、実際に利用できるのはそれだけです。つまり、これらの抽象化を実装する唯一の方法は「不要な」機能を使用することです。（もちろん、アナロジーは完璧ではありません。配列はプログラミングの実践が貧弱だと言う人はいないと思います。それらは理解し、考えるのは簡単です）。

レガシー互換性。

すべてが個人的な経験を形成します：

レガシープログラマ-私の同僚はあらゆる場所でアレイを使用しており、30年以上にわたって行ってきました。

レガシーコード-foo（array bar []）list / vector / collection toarray関数を使用できることを確認しますが、追加機能を使用しない場合は、最初に配列を使用する方が簡単で、多くの場合、タイプ切り替えなしで読みやすくなります。

レガシーボス-私のボスは何年も前に管理職に就く前は優れたプログラマーでしたが、「アレイを使用している」ことで会議が終了し、コレクションが誰にとっても昼食にかかることを説明できると考えています。

1）多次元バージョンのリストはありません。データに複数のディメンションがある場合、リストを使用するのは非常に非効率的です。

2）多数の小さなデータタイプ（たとえば、地形タイプの1バイトだけのマップ）を処理している場合、キャッシュによりパフォーマンスにかなりの違いが生じる可能性があります。配列バージョンは、読み込まれたメモリごとに複数のアイテムをロードし、リストバージョンは1つだけロードします。さらに、配列バージョンはキャッシュにリストバージョンの数倍のセルを保持します。データを繰り返し処理している場合、配列バージョンがキャッシュに収まるがリストバージョンが収まらない場合、これは大きな違いを生む可能性があります。

極端な場合は、Minecraftを検討してください。（ええ、C＃では書かれていません。同じ理由が当てはまります。）

タイプTの100要素配列は、タイプTの100個の独立変数をカプセル化します。TがタイプQの可変パブリックフィールドとタイプRの1つを持つ値タイプである場合、配列の各要素は独立変数をカプセル化しますしたがって、配列全体では、タイプQの100個の独立変数とタイプRの100個の独立変数がカプセル化されます。これらの変数は、他に影響を与えることなく個別にアクセスできます。 配列以外のコレクションタイプでは、構造体のフィールドを独立変数として使用できません。

代わりにTがタイプQおよびRのパブリック可変フィールドを持つクラスタイプである場合、配列の各要素は、ユニバースの任意の場所でのインスタンスへの唯一の参照を保持し、配列Tの要素がまったくない場合外部参照が存在するオブジェクトを識別するように変更すると、配列はタイプQの100個の独立変数とタイプRの100個の独立変数を効果的にカプセル化します。他のコレクション型は、このような配列の動作を模倣できますが、配列の例は、タイプQの100個の変数とタイプRの100個の変数をカプセル化することです。変数の各ペアを独自のクラスオブジェクトにカプセル化することは、それを行う高価な方法です。さらに、配列または可変クラス型のコレクションを使用すると、配列要素で識別される変数が独立していない可能性があります。

型が何らかのオブジェクトのように振る舞うことになっている場合、それはクラス型か、置換以外の変更の手段を提供しないプライベートフィールド構造のいずれかでなければなりません。しかし、型が独立した関連-はなく、変数の束のようにダクトテープで貼り合わせ動作するようになっている場合には、1型使用する必要がありますされて露出フィールドの構造体-変数の束がダクトテープで貼り合わせを。このような型の配列は、非常に効率的に機能し、非常にクリーンなセマンティクスを備えています。他のタイプを使用すると、セマンティクスが混乱したり、パフォーマンスが低下したり、またはその両方になります。

1つの重要な違いは、メモリの割り当てです。たとえば、リンクリストを走査すると、多くのキャッシュミスが発生し、パフォーマンスが低下する可能性がありますが、配列は特定のデータ型の複数のインスタンスを保持する連続したメモリチャンクを表し、順番に走査するとCPUにヒットする可能性が高くなりますキャッシュ。

もちろん、オブジェクト参照の配列は、キャッシュ参照の恩恵をあまり受けない場合があります。これは、逆参照によってメモリ内のどこにでも移動できるためです。

次に、配列を使用してリストを実装するArrayListなどのリスト実装があります。それらは便利なプリミティブです。

選択するタイミングと選択するタイミングについて使用できるガイダンスを次に示しArrayますList。

• Arrayメソッドから戻るときに使用します。
• List（メソッド内で）戻り値を構築するときに変数として使用します。次に.ToArray()、メソッドから戻るときに使用します。

一般に、Arrayコンシューマーがコレクションにアイテムを追加するつもりがない場合に使用します。List消費者がコレクションにアイテムを追加するときに使用します。

Array「静的」コレクションをList扱うためのものですが、「動的」コレクションを扱うためのものです。