For every situation that warrants the use of an array ... there is an awesome collection with benefits. Is there any specific use case for Arrays any more in .NET?
+32
A:
Sending/Receiving data with a specific length comes to mind, ie. Serial Port, Web Request, FTP Request. Basically stuff that works on a lower level in the system. Also, most Collections are using an array for storage (Noteable exception: LinkedList<T>). Collections are just another abstraction layer.
Femaref
2010-09-11 18:17:05
TCP/IP socket also comes to mind, but these can be much more elegantly handled by a stream.
Eric Mickelsen
2010-09-11 18:18:28
Streams also involve a `byte[]`.
Femaref
2010-09-11 18:18:59
I'd say *almost* any collection uses an array for storage. Not a `LinkedList<T>`, for example.
Dan Tao
2010-09-11 18:19:23
+1 for "just another abstraction layer" - It puts it perfectly.
Kyle Rozendo
2010-09-11 18:23:47
+1: There are many cases where a fixed block of values is the most efficient and appropriate data structure to use - comms is a typical and very common example. Just because high level data structures hide arrays internally does not mean arrays are not useful - you just don't "see" them as much but they're still there.
Jason Williams
2010-09-11 18:29:00
@Dan: The main data structures not to use arrays are linked lists and trees, but the overhead of a single memory structure is pretty high and arrays are a great way of reducing the cost. There are even tree interfaces that use arrays on the back end (though I can't be bothered to look them up right now…)
Donal Fellows
2010-09-11 20:00:28
@Donal: Sure, nobody's disputing that (as far as I can tell). I was just pointing out that not *all* collections use arrays internally (as the answer was originally worded).
Dan Tao
2010-09-11 20:20:35
+2
A:
Yes? Anytime I have a type which internally maintains a fixed-size collection of items, I use an array as it's the fastest to iterate and requires the least memory. No sense using a List<T>, Queue<T>, etc. if you don't need those features.
Dan Tao
2010-09-11 18:17:18
+4
A:
Yes, there certainly still is a use for arrays. Some methods still needs arrays.
For example:
string[] items = "a,b;c:d".Split(new char[]{',',';',':'});
It's still the simplest way to keep a bunch of items, and the number one choice until you need some specific feature, like for example dynamic growth.
Guffa
2010-09-11 18:19:04
+6
A:
Arrays are useful because they are always linear in memory and are fast to work with. For example I can take a byte[] and marshal directly into a structure without any problems but a List<T> would have to be converted to an array first as far as I know.
Chris T
2010-09-11 18:19:27
+1
A:
It's a fair question, but the answer is definitely that they're still useful. Speed is one reason, simplicity for fixed sizes is another. But I think the most important one is flexibility. It gives you a nice base to design your own collection, backed by a simple array, if you ever needed it.
Mike
2010-09-11 18:20:02
+5
A:
No they still have their uses and should always be considered.
Remember arrays are very basic representations of a fixed length so they are very fast and most languages understand them depending on the type used in the array.
You need to define an array size at the time that it is created and cannot change its size later. Lists and other things can grow as needed which adds overhead with respect to memory allocation.
Lists and other types are useful because they can do a lot but sometimes you don't need all that extra overhead so an array is all you need.
It's like driving a 4x4 because you think one day you might need to go off roading even though there is 99.9% of a chance you will be on normal roads. Array would be the basic car and a List for example would be a 4x4... it does everything else a car can do (an under the hood might use most of the same parts) but at the expense of gas, cost, might not fit in certain parking stalls, etc...
Arrays = performance and compatability
Lists (or other representations) = ease of use at a cost of performance and compatability
Kelsey
2010-09-11 18:20:51
I would reverse the analogy; Array is the 4x4 Car or a F1 with lots of horse power which also kills you much easier when you're not experienced handling them; while List is a Family Car or City Car which provides many safety features at the cost of less flexibility (e.g. not being able to go offroad conveniently).
Lie Ryan
2010-09-11 19:36:22
@Lie Ryan it's an analogy so I guess you could spin it more ways that one :) I agree with your take as well.
Kelsey
2010-09-11 19:40:23
@Lie: In production code, linked lists tend to be less common than that. If you're ever writing your own container type, start with an array and only add in linked list features if you really need them. (I've done hybrid versions which used a linked list of array elements; the algorithm needed the combination, but the data structure wasn't very reusable for other things. Blazing fast and efficient for what I was doing though, and it nailed the critical bottleneck in the program perfectly. :-))
Donal Fellows
2010-09-11 20:05:35
@Lie: Hmm, I think that was less clear than I wanted. My point was that as an analogy, linked lists aren't the family/city car, but rather something much less common. Trouble is, there's no real good fit with car analogies; data structures just aren't cars. ;-)
Donal Fellows
2010-09-11 20:07:37
@Donal Fellows: IMHO, Linked List is a very specialized data structure, it's great for certain thing, but sucks for nearly anything else. Linked List is a bit like a train; it's perfect for carrying lots of people safely (train is safer and more scalable than cars), but it's bad for nearly everything else. Though I agree, the analogy breaks here; data structure really isn't vehicles.
Lie Ryan
2010-09-11 20:31:19
@Kelsey: Remember that List<T> is just a wrapper around an array T[]. They are not *that* different.
Douglas
2010-09-12 22:19:49
+1
A:
No , Array will not loose its importance.
As when you know about the no of items in advance , you can go for array which gives you very fast access.
2- In Graph theroy , still when you store information about link between vertex , you can implment using arrays which are more fast than LinkList implementation.
3- Some methods like string.split returns array.
you can use this wonderful static placeholder of items in a verity of computer problems
saurabh
2010-09-11 18:24:53
+2
A:
Two cases where I work daily with arrays:
- Image analysis. Images are almost always byte[] or int[] arrays.
- External hardware communication. Most devices require perfectly structured arrays to send/receive messages.
bufferz
2010-09-11 19:51:47
+3
A:
Quite apart from everything else, many of those great collection classes you refer to are implemented using arrays. You might not be using them explicitly, but you're using loads of them and your program is better for it. That means that arrays must be in the language (or that the collections are implemented directly using lots of native code, which would be suckier).
Donal Fellows
2010-09-11 20:11:45
+1
A:
One thing I must tell you Arrays are the building blocks for any programming language. If you want to declare a storage having more than one element, Arrays are the basic option for you.
Say for instance a List.
If you see the definition of List, it actually holds
T[] items
Just use Reflector and find the definition of List, you will be surprised to find out List to be actually an Array. In .NET most of the collection other than LinkedList are basically an Array implementation. They used Array because of its fast storage and retrieval.
I agree that Array has limitation of Update or Remove, if your main emphasis is in storage than speed, you might go for Linked List.
abhishek
2010-09-11 20:14:22
+3
A:
Have arrays lost (some) significance?
Yes. For many tasks requiring a 'table' of items there now are more flexible and useful solutions like List<> and IEnumerable<>.
Have arrays lost their importance?
No. They are the fastest form of storage and they are used 'under the hood' in most of the collection classes, System.String etc.
So, arrays have become more low-level, and an application programmer will be using them directly less often.
Henk Holterman
2010-09-12 08:07:31
+1
A:
What do you think the backing field behind many of those fancy collections is?
FlySwat
2010-09-12 22:14:05