MyClass[] array;
List<MyClass> list;

当一个比另一个更可取的情况是什么?,为什么?


当前回答

当集合本身的不可变性是客户端和提供者代码之间契约的一部分时(不一定是集合中项目的不可变性)以及当IEnumerable不合适时,应该优先使用数组而不是List。

例如,

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

很明显,对"strChars"的修改不会改变原始的"str"对象,无论实现级是否了解"str"的底层类型。

但是假设

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

在这种情况下,仅仅从代码片段中还不清楚insert方法是否会改变原始的“str”对象。它需要String的实现级知识来做出判断,这打破了契约式设计方法。在String的情况下,这不是一个大问题,但在几乎所有其他情况下,这可能是一个大问题。将List设置为只读确实有帮助,但会导致运行时错误,而不是编译时错误。

其他回答

填充列表比填充数组更容易。对于数组,您需要知道数据的确切长度,但对于列表,数据大小可以是任何大小。你可以把一个列表转换成一个数组。

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();

尽管其他答案推荐List<T>,但在处理以下问题时,您将希望使用数组:

图像位图数据 其他底层数据结构(如网络协议)

除非你真的关心性能,我的意思是,“你为什么使用。net而不是c++ ?”你应该坚持使用List<>。它更容易维护,并为您在幕后完成调整数组大小的所有繁琐工作。(如果有必要,List<>在选择数组大小方面非常聪明,所以通常不需要这样做。)

数组Vs.列表是典型的可维护性Vs.性能问题。几乎所有开发人员都遵循的经验法则是,您应该兼顾两者,但当两者发生冲突时,请选择可维护性而不是性能。该规则的例外情况是当性能已经被证明是一个问题时。如果你把这个原则应用到数组Vs.列表中,你会得到这样的结果:

使用强类型列表,直到遇到性能问题。如果遇到性能问题,请决定是否使用数组对解决方案的性能更有利,而不是在维护方面对解决方案造成损害。

它们可能不受欢迎,但我是游戏项目中的数组的粉丝。 -迭代速度在某些情况下是很重要的,如果你对每个元素不做太多操作,数组上的foreach的开销就会大大减少 -添加和删除helper函数并不难 -速度比较慢,但如果你只建了一次,那就无所谓了 -在大多数情况下,更少的额外内存被浪费(只有数组结构才真正重要) -稍微少一点垃圾和指针和指针追逐

话虽如此,在实践中,我使用列表的次数远多于数组,但它们都有各自的位置。

如果List是内置类型,那么他们就可以优化包装器和枚举开销。