.net - type - Array versus List<T>: ¿Cuándo usar cuál?

list add c# (14)

MyClass[] array; List<MyClass> list;

¿Cuáles son los escenarios cuando uno es preferible sobre el otro? ¿Y por qué?

A menos que esté realmente preocupado por el rendimiento, y con eso quiero decir, "¿Por qué usa .Net en lugar de C ++?" usted debe atenerse a la Lista <>. Es más fácil de mantener y hace todo el trabajo sucio de cambiar el tamaño de una matriz entre bastidores. (Si es necesario, la Lista <> es bastante inteligente en cuanto a la elección de tamaños de matriz, por lo que generalmente no es necesario).

A pesar de las otras respuestas que recomiendan la List<T> , querrá utilizar matrices al manejar:

imagen de mapa de bits de datos
otras estructuras de datos de bajo nivel (es decir, protocolos de red)

Como nadie menciona: MyClass[] y List<MyClass> implementan IList<MyClass> . Si está considerando cuál aceptar como argumento, puede declararlo como IList<MyClass> para conveniencia de las personas que llaman. (por ejemplo, Foo(IList<int> foo) puede llamarse como Foo(new[] { 1, 2, 3 }) o Foo(new List<int> { 1, 2, 3 }) )

Depende completamente de los contextos en los que se necesita la estructura de datos. Por ejemplo, si está creando elementos para ser utilizados por otras funciones o servicios, utilizar la Lista es la manera perfecta de lograrlo.

Ahora, si tiene una lista de elementos y solo desea mostrarlos, digamos que en una matriz de páginas web es el contenedor que necesita usar.

En lugar de comparar las características de cada tipo de datos, creo que la respuesta más pragmática es "las diferencias probablemente no sean tan importantes para lo que necesita lograr, especialmente porque ambas implementan IEnumerable , así que siga la convención y el uso populares. una List hasta que tenga una razón para no hacerlo, en ese momento probablemente tendrá su razón para usar una matriz sobre una List ".

La mayoría de las veces, en el código administrado, querrá favorecer que las colecciones sean tan fáciles de trabajar como sea posible en lugar de preocuparse por las microoptimizaciones.

Es raro, en realidad, que quieras usar una matriz. Definitivamente use una List<T> cada vez que desee agregar / eliminar datos, ya que cambiar el tamaño de las matrices es costoso. Si sabe que los datos tienen una longitud fija y desea micro-optimizar por alguna razón muy específica (después de la evaluación comparativa), entonces una matriz puede ser útil.

List<T> ofrece mucha más funcionalidad que una matriz (aunque LINQ lo iguala un poco), y casi siempre es la elección correcta. Excepto por los argumentos de los params , por supuesto. ;-pag

Como un contador - List<T> es unidimensional; donde, como tiene arrays rectangulares (etc.) como int[,] o string[,,] , pero hay otras formas de modelar tales datos (si es necesario) en un modelo de objeto.

Ver también:

Dicho esto, uso mucho los arreglos en mi proyecto protobuf-net ; enteramente para el rendimiento:

hace muchos cambios de bits, por lo que un byte[] es bastante esencial para la codificación;
Utilizo un búfer local de byte[] que relleno antes de enviarlo al flujo subyacente (y vv); más rápido que BufferedStream etc;
utiliza internamente un modelo de objetos basado en matrices ( Foo[] lugar de List<Foo> ), ya que el tamaño se fija una vez construido y debe ser muy rápido.

Pero esto es definitivamente una excepción; para el procesamiento general de la línea de negocios, una List<T> gana cada vez.

La mayoría de las veces, usar una List sería suficiente. Una List utiliza una matriz interna para manejar sus datos, y redimensiona automáticamente la matriz cuando agrega más elementos a la List que su capacidad actual, lo que hace que sea más fácil de usar que una matriz, donde debe conocer la capacidad de antemano.

Consulte http://msdn.microsoft.com/en-us/library/ms379570(v=vs.80).aspx#datastructures20_1_topic5 para obtener más información sobre Listas en C # o simplemente descompile System.Collections.Generic.List<T> .

Si necesita datos multidimensionales (por ejemplo, mediante una matriz o en la programación de gráficos), probablemente opte por una array .

Como siempre, si la memoria o el rendimiento son un problema, ¡mídelo! De lo contrario, podría estar haciendo suposiciones falsas sobre el código.

Las listas en .NET son envolturas sobre matrices y usan una matriz internamente. La complejidad en el tiempo de las operaciones en las listas es la misma que con las matrices, sin embargo, hay un poco más de sobrecarga con toda la funcionalidad agregada / facilidad de uso de las listas (como el cambio de tamaño automático y los métodos que vienen con la clase de lista). Más o menos, recomendaría el uso de listas en todos los casos, a menos que exista una razón convincente para no hacerlo, como por ejemplo, si necesita escribir código extremadamente optimizado, o si está trabajando con otro código que se basa en matrices.

Las matrices deben usarse con preferencia a la Lista cuando la inmutabilidad de la colección en sí es parte del contrato entre el código del cliente y el proveedor (no necesariamente la inmutabilidad de los elementos dentro de la colección) Y cuando IEnumerable no es adecuado.

Por ejemplo,

var str = "This is a string"; var strChars = str.ToCharArray(); // returns array

Está claro que la modificación de "strChars" no mutará el objeto "str" original, independientemente del nivel de implementación del conocimiento del tipo subyacente de "str".

Pero supongamos que

var str = "This is a string"; var strChars = str.ToCharList(); // returns List<char> strChars.Insert(0, ''X'');

En este caso, no queda claro a partir de ese fragmento de código solo si el método de inserción mutará o no mutará el objeto "str" original. Requiere un nivel de implementación de conocimientos de Cadena para tomar esa determinación, lo que rompe el enfoque de Diseño por Contrato. En el caso de String, no es un gran problema, pero puede ser un gran problema en casi todos los demás casos. Establecer la Lista en solo lectura ayuda, pero produce errores en tiempo de ejecución, no tiempo de compilación.

Otra situación que aún no se menciona es cuando uno tendrá una gran cantidad de elementos, cada uno de los cuales consiste en un conjunto fijo de variables relacionadas pero independientes pegadas (por ejemplo, las coordenadas de un punto o los vértices de un triángulo 3d). Un conjunto de estructuras de campo expuesto permitirá que sus elementos se modifiquen eficientemente "en su lugar", algo que no es posible con ningún otro tipo de colección. Debido a que una matriz de estructuras mantiene sus elementos consecutivamente en la RAM, los accesos secuenciales a los elementos de la matriz pueden ser muy rápidos. En situaciones donde el código necesitará realizar muchos pases secuenciales a través de una matriz, una matriz de estructuras puede superar a una matriz u otra colección de referencias de objetos de clase por un factor de 2: 1; Además, la capacidad de actualizar elementos en su lugar puede permitir que un conjunto de estructuras supere cualquier otro tipo de colección de estructuras.

Aunque las matrices no son redimensionables, no es difícil que el código almacene una referencia de matriz junto con el número de elementos que están en uso, y reemplace la matriz por una más grande según sea necesario. Alternativamente, uno podría escribir fácilmente el código para un tipo que se comportó de manera muy similar a una List<T> pero expuso su almacén de respaldo, lo que le permite a uno decir cualquiera de MyPoints.Add(nextPoint); o MyPoints.Items[23].X += 5; . Tenga en cuenta que este último no necesariamente arrojaría una excepción si el código intentara acceder más allá del final de la lista, pero el uso sería conceptualmente bastante similar a la List<T> .

Pueden ser impopulares, pero soy un fanático de Arrays en proyectos de juegos. - La velocidad de iteración puede ser importante en algunos casos. Foreach en un Array tiene un costo significativamente menor si no está haciendo mucho por elemento. Agregar y eliminar no es tan difícil con las funciones de ayuda. Es más lento, pero en los casos en los que solo lo construye una vez. puede que no importe. En la mayoría de los casos, se desperdicia menos memoria adicional (solo realmente significativa con Arrays of structs) - Un poco menos de basura y punteros y punteros

Dicho esto, uso List mucho más a menudo que Arrays en la práctica, pero cada uno tiene su lugar.

Sería bueno si la lista estuviera en un tipo integrado para que pudieran optimizar el envoltorio y la sobrecarga de enumeración.

Realmente solo respondiendo para agregar un enlace que me sorprende aún no se ha mencionado: la entrada del blog de Eric''s Lippert sobre "Arrays considerado algo dañino".

Se puede juzgar por el título que sugiere usar colecciones siempre que sea práctico, pero como señala Marc con razón, hay un montón de lugares donde una matriz es realmente la única solución práctica.

Si sé exactamente cuántos elementos voy a necesitar, digamos que necesito 5 elementos y solo 5 elementos, entonces uso una matriz. De lo contrario solo uso una lista <T>.

Use una matriz cuando esté tratando con datos que son:

De tamaño fijo, o poco probable que crezca mucho.
adecuadamente grande (más de 10, 50, 100 elementos, dependiendo del algoritmo)
estará haciendo un montón de indexación en él, es decir, sabe que a menudo querrá el tercer elemento, o el quinto, o lo que sea.

Use una lista para:

listas de datos de longitud variable
que se utilizan principalmente como una pila o una cola o deben ser iterados en su totalidad
cuando no desea escribir una expresión para derivar el tamaño de matriz final para la declaración y no desea seleccionar un gran número

Usa un mapa de hash para:

listas de datos de longitud variable
que necesitan ser indexados como lo haría una matriz

En realidad, querrás una lista o un hashmap casi todo el tiempo. La próxima vez que elija una estructura de datos, piense en lo que debe hacer bien para usted (o su código, de todos modos). Entonces elige algo basado en eso. En caso de duda, elija algo lo más general posible, es decir, una interfaz a la que pueda reemplazar la implementación con bastante facilidad. Algunos buenos enlaces en las otras respuestas también.