Is there ever a reason to use an array when lists are available? [closed]

Question

It seems like List<T> in C# can do everything an array can do and more, and seems also just as efficient in memory and performance as an array.

So why would I ever want to use an array?

I'm obviously not asking about cases where an API or other external constraint (i.e. the Main function) requires me to use an array... I'm only asking about creating new data structures in my own code.

Answer 1

The same reason I don't drive a truck when going to work. I don't use something that I won't use the features of.

First of all an array is a primitive construct so an array is faster and more efficient than a List<> for sure, so your argument is not true. Array is also available everywhere and known by developers using different languages and platforms.

The most important reason I use an array instead of a List<> is to imply that the data is fixed length. If I won't add or remove any items from that data collection, I want to make sure that the type reflects that.

Another thing is let's say you are implementing a new data structure and you've read some papers about it. Now while implementing specific algorithms, you can't always rely on someone else's implementation of a type that is general purpose. It changes from .NET to Mono and even between different versions of the framework.

And it is sometimes easier to port a piece of code that uses an array instead of a framework dependent type.

Answer 2

You need arrays to manage your collection of mutable structs, of course, and what would we do without those.

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

(note that there may be some cases where an array of mutable struct is desireable, but usually this differing behavior of mutable structs within arrays versus other collections is a source of errors that should be avoided)

---

More seriously, you need an array if you want to pass an element by reference. i.e.

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

That can be useful for lock-free threadsafe code.

---

You need an array if you quickly and efficiently want to initialize your fixed-size collection with the default value.

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

(note that it would be possible to implement a constructor for List that does the same, it's just that c# does not offer this feature)

---

you need an array if you want to efficiently copy parts of the collection

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

(again, this is something that could be implemented for List as well, but this feature does not exist in c#)

Answer 3

So why would I ever want to use an array?

Rarely, you will have a scenario where you know that you need a fixed number of elements. From a design perspective, this should be avoided. If you need 3 things, the nature of business means that you'll very often need 4 in the next release.

Still, when this rare scenario actually occurs, using an array to enforce that fixed size invariant is useful. It provides a signal to other programmers that it is a fixed size, and helps prevent misuse where someone adds or removes an element - breaking expectations elsewhere in code.

Answer 4

Your question has actually already been answered before.

and seems also just as efficient in memory and performance as an array.

It isn't. From the question I linked:

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

Arrays are twice as fast in certain important cases. I am certain the memory usage also differs non-trivially.

Since the main premise of your question is thus defeated, I'm assuming this answers your question. In addition to this, sometimes arrays are forced on you by Win32 API, or your GPU's shader, or some other non-DotNet library.

Even within DotNet, some methods consume and/or return arrays (such as String.Split). Which means either you must now eat the cost of calling ToList and ToArray all the time, or you must conform and use array, possibly continuing the cycle by propagating this to poor downstream users of your code.

More questions and answers on Stack Overflow on this topic:

• Array versus List<T>: When to use which?
• Why do we use arrays instead of other data structures?
• Which is better to use array or List<>?

Answer 5

In addition to reasons listed in other answers, array literal takes fewer characters to declare:

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

Using array instead of List makes the code a bit shorter and just a bit more readable in cases when (1) you need to pass any IEnumerable<T> literal, or (2) where other functionality of List doesn't matter and you need to use some list-like literal.

I've done this occasionally in unit tests.

Answer 6

This is strictly from an OO perspective.

While I can't think of a reason to pass just an array around, I can certainly see situations where an array representation internal to the class is probably the best choice.

While there are other options that give similar characteristics, none seem as intuitive as an array for problems dealing with processing permutations, nested for loops, matrix representation, bitmaps and data interleaving algorithms.

There's a substantial number of scientific fields that rely on matrix math extensively. (e.g. image processing, data error correction, digital signal processing, a ream of applied mathematics problems). Most of the algorithms in those fields are written in terms of using multidimensional arrays/matrixes. So it would be more natural to implement the algorithms as they are defined rather than make them more "software" friendly at the expense of losing the direct tie-ins to the papers the algorithms are based upon.

Like I said, in these cases you can probably get away with using lists but that adds yet another layer of complexity on top of what are already complex algorithms.

Answer 7

This actually goes for other languages which have lists as well (such as Java or Visual Basic). There are cases where you need to use an array because a method returns an array instead of a List.

In an actual program, I don't think an array will be used very often, but sometimes you know the data will be a fixed size and you like the small performance gain you get from using an array. Micro-optimisation would be a valid reason, just as a method returning a list, or the need for a multidimensional datastructure.

Answer 8

Well, I found a use for arrays in a game I have been writing. I used it for creating an inventory system with a fixed number of slots. This had several benefits:

1. I knew exactly how many open inventory slots the game object had by looking and seeing which slots were null.
2. I knew exactly what index each item was in.
3. It was still a "typed" array (Item[] Inventory), so I could add/remove the objects of type "Item".

I figured that if I ever needed to "increase" the size of the inventory, I could do so by transferring the old items into the new array, but since the inventory was fixed by screen space and I had no need to dynamically make it larger/smaller, it worked well for the purpose I was using it for.

Answer 9

If you're traversing all elements of a list, then no, an array is not necessary, 'next' or arbitrary 'selection without replacement' will do fine.

But if your algorithm needs random access to the elements in the collection, then, yes, an array is necessary.

This is somewhat analogous to "is goto necessary?". In a reasonable modern language it is not needed at all. But if you peel away the abstractions, at some point, that's all that is actually available to you, that is, the only way to implement these abstractions is with the 'unnecessary' feature. (Of course, the analogy isn't perfect, I don't think anyone says that arrays are poor programming practice; they are easy to understand and think about).

Answer 10

Legacy compatibility.

All form personal experience:

Legacy programmers - my colleague uses arrays everywhere, has done for 30+ years, good luck changing his mind with your new fangled ideas.

Legacy code - foo(array bar[]) sure you can use a list/vector/collection toarray function but if you not using any of there additional features its easier to use an array to begin with, often more readable without the type switching.

Legacy boss - my boss was a good programmer before she went into management many years ago and still thinks she's up to date, "were using arrays" can end a meeting, explaining what a collection is can cost everyone lunch.

Answer 11

1) There is no multi-dimensional version of List. If your data has more than one dimension it will be very inefficient to use lists.

2) When you are dealing with a large number of small data types (say, a map where all you have is one byte for the terrain type) there can be considerable performance differences due to caching. The array version loads several items per memory read, the list version loads only one. Furthermore, the array version holds several times as many cells in the cache as the list version--if you're repeatedly processing the data this can make a big difference if the array version fits in cache but the list version does not.

For an extreme case, consider Minecraft. (Yeah, it's not written in C#. The same reason applies.)

Answer 12

A 100-element array of some type T encapsulates 100 independent variables of type T. If T happens to be a value type which has a mutable public field of type Q and one of type R, then each element of the array will encapsulate independent variables of types Q and R. The array as a whole will thus encapsulate 100 independent variables of type Q and 100 independent variables of type R; any of those variables may be accessed individually without affecting any other. No collection type other than arrays can allow the fields of structures to be used as independent variables.

If T happened instead to be a class type with public mutable fields of type Q and R, each element of the array holds the only reference, anywhere in the universe, to an instance of T, and if none of the elements of the array will ever be modified to identify an object to which any outside reference exists, then the array will effectively encapsulate 100 independent variables of type Q and 100 independent variables of type R. Other collection types can mimic the behavior of such an array, but if the only purpose of the array is to encapsulate 100 variables of type Q and 100 of type R, encapsulating each pair of variables in its own class object is an expensive way of doing that. Further, using an array or collection of mutable class type creates the possibility that the variables identified by array elements may not be independent.

If a type is supposed to behave like some kind of object, then it should either be a class type or a private-field structure which provides no means of mutation other than replacement. If, however, a type is supposed to behave like a bunch of related-but-independent variables stuck together with duct tape, then one should use a type which is a bunch of variables stuck together with duct tape--an exposed-field struct. Arrays of such types are very efficient to work with, and have very clean semantics. Use of any other type will lead to muddled semantics, inferior performance, or both.

Answer 13

One important different is memory allocation. For example, traversing a linked list could result in a lot of cache misses and slower performance, whereas an array represents a contiguous chunk of memory holding multiple instances of some particular data type, and do traversing it in order is more likely to hit the CPU cache.

Of course, an array of object references may not benefit as much from cache hits, since dereferencing could still take you anywhere in memory.

Then there are list implementations such as ArrayList, which implement a list using an array. They're useful primitives to have.

Answer 14

Here's some guidance you can use on when to select Array and when to select List.

• Use Array when returning from a method.
• Use List as the variable when you are constructing the return value (inside the method). Then use .ToArray() when returning from the method.

In general, use an Array when you don't intend the consumer to add items to the collection. Use List when you intend the consumer to add items to the collection.

Array is meant for dealing with "static" collections while List is meant for dealing with "dynamic" collections.