Array versus List<T>: When to use which?
It is rare, in reality, that you would want to use an array. Definitely use a List<T>
any time you want to add/remove data, since resizing arrays is expensive. If you know the data is fixed length, and you want to micro-optimise for some very specific reason (after benchmarking), then an array may be useful.
List<T>
offers a lot more functionality than an array (although LINQ evens it up a bit), and is almost always the right choice. Except for params
arguments, of course. ;-p
As a counter - List<T>
is one-dimensional; where-as you have have rectangular (etc) arrays like int[,]
or string[,,]
- but there are other ways of modelling such data (if you need) in an object model.
See also:
- How/When to abandon the use of Arrays in c#.net?
- Arrays, What's the point?
That said, I make a lot of use of arrays in my protobuf-net project; entirely for performance:
- it does a lot of bit-shifting, so a
byte[]
is pretty much essential for encoding; - I use a local rolling
byte[]
buffer which I fill before sending down to the underlying stream (and v.v.); quicker thanBufferedStream
etc; - it internally uses an array-based model of objects (
Foo[]
rather thanList<Foo>
), since the size is fixed once built, and needs to be very fast.
But this is definitely an exception; for general line-of-business processing, a List<T>
wins every time.
Really just answering to add a link which I'm surprised hasn't been mentioned yet: Eric's Lippert's blog entry on "Arrays considered somewhat harmful."
You can judge from the title that it's suggesting using collections wherever practical - but as Marc rightly points out, there are plenty of places where an array really is the only practical solution.
Notwithstanding the other answers recommending List<T>
, you'll want to use arrays when handling:
- image bitmap data
- other low-level data-structures (i.e. network protocols)