MyClass[] array;
List<MyClass> list;
当一个比另一个更可取的情况是什么?,为什么?
MyClass[] array;
List<MyClass> list;
当一个比另一个更可取的情况是什么?,为什么?
当前回答
它们可能不受欢迎,但我是游戏项目中的数组的粉丝。 -迭代速度在某些情况下是很重要的,如果你对每个元素不做太多操作,数组上的foreach的开销就会大大减少 -添加和删除helper函数并不难 -速度比较慢,但如果你只建了一次,那就无所谓了 -在大多数情况下,更少的额外内存被浪费(只有数组结构才真正重要) -稍微少一点垃圾和指针和指针追逐
话虽如此,在实践中,我使用列表的次数远多于数组,但它们都有各自的位置。
如果List是内置类型,那么他们就可以优化包装器和枚举开销。
其他回答
在现实中,很少需要使用数组。当您想添加/删除数据时,一定要使用List<T>,因为调整数组的大小是非常昂贵的。如果您知道数据是固定长度的,并且由于某些非常特定的原因(在基准测试之后)想要进行微观优化,那么数组可能会很有用。
List<T>提供了比数组更多的功能(尽管LINQ稍微均衡了一点),并且几乎总是正确的选择。当然,除了参数参数。- p;
当counter - List<T时,>是一维的;比如你已经有了int[,]或string[,,]这样的矩形数组,但是在对象模型中还有其他方法来建模这样的数据(如果你需要的话)。
参见:
如何/何时在c#.net中放弃使用数组? 数组,重点是什么?
也就是说,我在我的protobuf-net项目中大量使用数组;完全为了性能:
它做了很多位移动,所以字节[]对于编码非常重要; 我使用一个本地滚动字节[]缓冲区,我在发送到底层流(和v.v v.)之前填充;比BufferedStream等更快; 它在内部使用基于数组的对象模型(Foo[]而不是List<Foo>),因为大小一旦构建就固定了,并且需要非常快。
但这绝对是个例外;对于一般业务线处理,List<T>每次都胜出。
填充列表比填充数组更容易。对于数组,您需要知道数据的确切长度,但对于列表,数据大小可以是任何大小。你可以把一个列表转换成一个数组。
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是完成该任务的最佳方式。
现在,如果你有一个项目列表,你只是想在网页上显示它们,数组是你需要使用的容器。
与其对每种数据类型的特性进行比较,我认为最实用的答案是“对于您需要完成的任务来说,差异可能并不那么重要,特别是因为它们都实现了IEnumerable,所以遵循流行的惯例,使用List,直到您有理由不使用List,此时您可能会有理由使用数组而不是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.