Matriz versus Lista <T>: Quando usar qual?

MyClass[] array;
List<MyClass> list;

Quais são os cenários em que um é preferível ao outro? E porque?

É raro, na realidade, que você queira usar uma matriz. Definitivamente, use a List<T>qualquer momento que desejar adicionar / remover dados, pois o redimensionamento de matrizes é caro. Se você sabe que os dados são de tamanho fixo e deseja otimizar por algum motivo muito específico (após o benchmarking), uma matriz pode ser útil.

List<T>oferece muito mais funcionalidade do que uma matriz (embora o LINQ aumente um pouco) e é quase sempre a escolha certa. Exceto pelos paramsargumentos, é claro. ;-p

Como um contador - List<T>é unidimensional; onde você tem matrizes retangulares (etc) como int[,]ou string[,,]- mas existem outras maneiras de modelar esses dados (se necessário) em um modelo de objeto.

Veja também:

• Como / quando abandonar o uso de matrizes em c # .net?
• Matrizes, qual é o objetivo?

Dito isto, faço muito uso de matrizes no meu projeto protobuf-net ; inteiramente para desempenho:

• faz muitas mudanças de bits; portanto, a byte[]é praticamente essencial para a codificação;
• Eu uso um byte[]buffer local rotativo que preencho antes de enviar para o fluxo subjacente (e vv); mais rápido que BufferedStreametc;
• ele usa internamente um modelo de objetos baseado em matriz (em Foo[]vez de List<Foo>), pois o tamanho é fixo depois de criado e precisa ser muito rápido.

Mas isso é definitivamente uma exceção; para o processamento geral da linha de negócios, a List<T>vence sempre.

Realmente, apenas responder para adicionar um link que me surpreende ainda não foi mencionado: a entrada de Eric Lippert no blog "Arrays considerados um tanto prejudiciais".

Você pode julgar pelo título que está sugerindo o uso de coleções sempre que possível - mas, como Marc indica corretamente, há muitos lugares em que uma matriz realmente é a única solução prática.

Não obstante as outras respostas recomendadas List<T>, você desejará usar matrizes ao manipular:

• dados de bitmap da imagem
• outras estruturas de dados de baixo nível (isto é, protocolos de rede)

A menos que você esteja realmente preocupado com o desempenho, e com isso quero dizer: "Por que você está usando .Net em vez de C ++?" você deve ficar com a lista <>. É mais fácil de manter e faz todo o trabalho sujo de redimensionar uma matriz nos bastidores para você. (Se necessário, a List <> é bastante inteligente sobre a escolha de tamanhos de matriz, portanto, não é necessário normalmente.)

As matrizes devem ser usadas preferencialmente à lista quando a imutabilidade da coleção em si faz parte do contrato entre o código do cliente e do provedor (não necessariamente imutabilidade dos itens da coleção) E quando IEnumerable não é adequado.

Por exemplo,

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

É claro que a modificação de "strChars" não altera o objeto "str" ​​original, independentemente do conhecimento no nível de implementação do tipo subjacente de "str".

Mas suponha que

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

Nesse caso, não está claro apenas esse trecho de código se o método insert irá ou não alterar o objeto "str" ​​original. Ele requer conhecimento em nível de implementação de String para fazer essa determinação, o que quebra a abordagem Design por Contrato. No caso de String, não é grande coisa, mas pode ser grande em quase todos os outros casos. Definir a lista como somente leitura ajuda, mas resulta em erros em tempo de execução, não em tempo de compilação.

Se eu sei exatamente quantos elementos Vou necessidade, digo que preciso de 5 elementos e apenas nunca 5 elementos, então eu usar uma matriz. Caso contrário, eu apenas uso uma lista <T>.

Na maioria das vezes, usar a Listseria suficiente. A Listusa uma matriz interna para manipular seus dados e redimensiona automaticamente a matriz ao adicionar mais elementos à Listsua capacidade atual, o que facilita a utilização do que uma matriz, na qual você precisa conhecer a capacidade com antecedência.

Consulte http://msdn.microsoft.com/en-us/library/ms379570(v=vs.80).aspx#datastructures20_1_topic5 para obter mais informações sobre listas em C # ou apenas descompilar System.Collections.Generic.List<T>.

Se você precisar de dados multidimensionais (por exemplo, usando uma matriz ou em programação gráfica), provavelmente deverá usar um array.

Como sempre, se a memória ou o desempenho são um problema, meça-o! Caso contrário, você pode estar fazendo suposições falsas sobre o código.

Matrizes vs. Listas é um problema clássico de manutenção versus desempenho. A regra geral que quase todos os desenvolvedores seguem é que você deve atirar nos dois, mas quando eles entrarem em conflito, escolha a manutenção em vez do desempenho. A exceção a essa regra é quando o desempenho já provou ser um problema. Se você levar esse princípio para Arrays vs. Listas, então o que você recebe é o seguinte:

Use listas fortemente digitadas até encontrar problemas de desempenho. Se você encontrar um problema de desempenho, tome uma decisão sobre se descartar as matrizes beneficiará sua solução com desempenho mais do que prejudicá-la em termos de manutenção.

Outra situação ainda não mencionada é quando alguém terá um grande número de itens, cada um dos quais consiste em um conjunto fixo de variáveis ​​relacionadas, mas independentes, coladas (por exemplo, as coordenadas de um ponto ou os vértices de um triângulo 3d). Uma matriz de estruturas de campo exposto permitirá que seus elementos sejam eficientemente modificados "no lugar" - algo que não é possível em nenhum outro tipo de coleção. Como uma matriz de estruturas mantém seus elementos consecutivamente na RAM, os acessos sequenciais aos elementos da matriz podem ser muito rápidos. Nas situações em que o código precisará fazer muitas passagens seqüenciais através de uma matriz, uma matriz de estruturas pode superar uma matriz ou outra coleção de referências a objetos de classe por um fator de 2: 1; mais longe,

Embora as matrizes não sejam redimensionáveis, não é difícil fazer com que o código armazene uma referência de matriz junto com o número de elementos em uso e substitua a matriz por uma maior, conforme necessário. Como alternativa, pode-se facilmente escrever código para um tipo que se comporte de maneira semelhante a um, List<T>mas exponha seu repositório, permitindo assim que se diga um MyPoints.Add(nextPoint);ou outro MyPoints.Items[23].X += 5;. Observe que o último não lançaria necessariamente uma exceção se o código tentasse acessar além do final da lista, mas o uso seria conceitualmente bastante semelhante ao List<T>.

As listas no .NET são wrappers sobre matrizes e usam uma matriz internamente. A complexidade de tempo das operações nas listas é a mesma que seria com as matrizes, no entanto, há um pouco mais de sobrecarga com toda a funcionalidade / facilidade de uso das listas (como redimensionamento automático e os métodos que acompanham a classe da lista). Basicamente, eu recomendaria o uso de listas em todos os casos, a menos que haja um motivo convincente para não fazê-lo, como se você precisar escrever um código extremamente otimizado ou se estiver trabalhando com outro código criado em torno de matrizes.

Em vez de fazer uma comparação dos recursos de cada tipo de dados, acho que a resposta mais pragmática é "as diferenças provavelmente não são tão importantes para o que você precisa realizar, principalmente porque as duas implementam IEnumerable, siga as convenções populares e use um Listaté que você tenha um motivo para não fazê-lo, nesse momento você provavelmente terá seu motivo para usar uma matriz sobre a List. "

Na maioria das vezes, no código gerenciado, você prefere que as coleções sejam o mais fácil de trabalhar, ao invés de se preocupar com as otimizações.

Eles podem ser impopulares, mas eu sou fã de Arrays em projetos de jogos. - A velocidade de iteração pode ser importante em alguns casos, pois cada matriz tem uma sobrecarga significativamente menor se você não estiver fazendo muito por elemento - Adicionar e remover não é tão difícil com as funções auxiliares - É mais lento, mas nos casos em que você a constrói apenas uma vez pode não importar - Na maioria dos casos, menos memória extra é desperdiçada (apenas realmente significativa com matrizes de estruturas) - Pouco menos lixo e ponteiros e perseguição de ponteiros

Dito isto, eu uso a List com muito mais frequência do que Arrays na prática, mas cada um tem seu lugar.

Seria bom se List fosse um tipo incorporado, para que eles pudessem otimizar a sobrecarga do wrapper e da enumeração.

Preencher uma lista é mais fácil que uma matriz. Para matrizes, é necessário saber o tamanho exato dos dados, mas para listas, o tamanho dos dados pode ser qualquer. E você pode converter uma lista em uma matriz.

List<URLDTO> urls = new List<URLDTO>();

urls.Add(new URLDTO() {
    key = "wiki",
    url = "https://...",
});

urls.Add(new URLDTO()
{
    key = "url",
    url = "http://...",
});

urls.Add(new URLDTO()
{
    key = "dir",
    url = "https://...",
});

// convert a list into an array: URLDTO[]
return urls.ToArray();

Como ninguém menciona: em C #, uma matriz é uma lista. MyClass[]e List<MyClass>ambos implementam IList<MyClass>. (por exemplo, void Foo(IList<int> foo)pode ser chamado como Foo(new[] { 1, 2, 3 })ouFoo(new List<int> { 1, 2, 3 }) )

Portanto, se você estiver escrevendo um método que aceite a List<MyClass>como argumento, mas use apenas um subconjunto de recursos, poderá declarar comoIList<MyClass> para conveniência dos chamadores.

Detalhes:

• Por que array implementa IList?
• Como matrizes em C # implementam parcialmente IList <T>?

Depende completamente dos contextos em que a estrutura de dados é necessária. Por exemplo, se você estiver criando itens para serem usados ​​por outras funções ou serviços usando a Lista, é a maneira perfeita de realizá-lo.

Agora, se você possui uma lista de itens e deseja apenas exibi-los, digamos que, em uma matriz de páginas da Web, é o contêiner que você precisa usar.

Vale a pena mencionar sobre a capacidade de fazer casting no local.

interface IWork { }
class Foo : IWork { }

void Test( )
{
    List<Foo> bb = new List<Foo>( );
    // Error: CS0029 Cannot implicitly convert type 'System.Collections.Generic.List<Foo>' to 'System.Collections.Generic.List<IWork>'
    List<IWork> cc = bb; 

    Foo[] bbb = new Foo[4];
    // Fine
    IWork[] ccc = bbb;
}

Portanto, a matriz oferece um pouco mais de flexibilidade quando usada no tipo ou argumento de retorno para funções.

IWork[] GetAllWorks( )
{
    List<Foo> fooWorks = new List<Foo>( );
    return fooWorks.ToArray( ); // Fine
}

void ExecuteWorks( IWork[] works ) { } // Also accept Foo[]