MyClass[] array;
List<MyClass> list;
当一个比另一个更可取的情况是什么?,为什么?
MyClass[] array;
List<MyClass> list;
当一个比另一个更可取的情况是什么?,为什么?
当前回答
Lists in .NET are wrappers over arrays, and use an array internally. The time complexity of operations on lists is the same as would be with arrays, however there is a little more overhead with all the added functionality / ease of use of lists (such as automatic resizing and the methods that come with the list class). Pretty much, I would recommend using lists in all cases unless there is a compelling reason not to do so, such as if you need to write extremely optimized code, or are working with other code that is built around arrays.
其他回答
除非你真的关心性能,我的意思是,“你为什么使用。net而不是c++ ?”你应该坚持使用List<>。它更容易维护,并为您在幕后完成调整数组大小的所有繁琐工作。(如果有必要,List<>在选择数组大小方面非常聪明,所以通常不需要这样做。)
它完全取决于需要数据结构的上下文。例如,如果您正在创建供其他函数或服务使用的项,则使用List是完成该任务的最佳方式。
现在,如果你有一个项目列表,你只是想在网页上显示它们,数组是你需要使用的容器。
大多数情况下,使用List就足够了。List使用内部数组来处理其数据,并在向List中添加比当前容量更多的元素时自动调整数组的大小,这使得它比需要事先知道容量的数组更容易使用。
有关c#中的列表的更多信息,请参阅http://msdn.microsoft.com/en-us/library/ms379570(v=vs.80).aspx#datastructures20_1_topic5,或者只是反编译System.Collections.Generic.List<T>。
如果需要多维数据(例如使用矩阵或图形编程),则可能使用数组。
像往常一样,如果内存或性能是一个问题,测量它!否则,您可能会对代码做出错误的假设。
Lists in .NET are wrappers over arrays, and use an array internally. The time complexity of operations on lists is the same as would be with arrays, however there is a little more overhead with all the added functionality / ease of use of lists (such as automatic resizing and the methods that come with the list class). Pretty much, I would recommend using lists in all cases unless there is a compelling reason not to do so, such as if you need to write extremely optimized code, or are working with other code that is built around arrays.
Another situation not yet mentioned is when one will have a large number of items, each of which consists of a fixed bunch of related-but-independent variables stuck together (e.g. the coordinates of a point, or the vertices of a 3d triangle). An array of exposed-field structures will allow the its elements to be efficiently modified "in place"--something which is not possible with any other collection type. Because an array of structures holds its elements consecutively in RAM, sequential accesses to array elements can be very fast. In situations where code will need to make many sequential passes through an array, an array of structures may outperform an array or other collection of class object references by a factor of 2:1; further, the ability to update elements in place may allow an array of structures to outperform any other kind of collection of structures.
Although arrays are not resizable, it is not difficult to have code store an array reference along with the number of elements that are in use, and replace the array with a larger one as required. Alternatively, one could easily write code for a type which behaved much like a List<T> but exposed its backing store, thus allowing one to say either MyPoints.Add(nextPoint); or MyPoints.Items[23].X += 5;. Note that the latter would not necessarily throw an exception if code tried to access beyond the end of the list, but usage would otherwise be conceptually quite similar to List<T>.