我们应该使用Generic Collection来提高安全性和性能吗?

时间:2022-09-10 23:10:14

Should we use Generic Collection to improve safety and performance?

我们应该使用Generic Collection来提高安全性和性能吗?

3 个解决方案

#1


5  

Of course. Why wouldn't you? More important than the performance, IMO, is the fact that generic APIs are more expressive. That goes for generic APIs in general, not just collections.

当然。你为什么不呢?比IMO更重要的是,通用API更具表现力。这通常适用于通用API,而不仅仅是集合。

EDIT: Just to clarify these a bit:

编辑:只是澄清这些:

  • Performance characteristics are slightly different between the generic and nongeneric collections for reasons of "they're different implementation" as well as the whole generic/nongeneric side. Obviously the generic version avoids boxing/unboxing and (in most use cases) an execution time cast when fetching. In practice this is only likely to be significant for value types, where the boxing comes into play. For large collections, it's the difference in memory usage which is likely to be more significant than the execution speed difference.

    由于“它们是不同的实现”以及整个通用/非通用方面的原因,通用和非通用集合之间的性能特征略有不同。显然,通用版本避免了装箱/拆箱和(在大多数使用情况下)获取时的执行时间。在实践中,这对于拳击发挥作用的价值类型来说可能很重要。对于大型集合,内存使用的差异可能比执行速度差异更大。

  • I'm slightly less bothered by the actual type-safety aspect. It's certainly a good thing, but I can't remember ever actually seeing a bug when using the nongeneric collections due to putting the wrong type in (or fetching it as the wrong type). It's certainly a benefit though.

    我对实际的类型安全方面的困扰略微减少。这当然是一件好事,但我记不起在使用非通用集合时实际上看到了一个错误,因为它输入了错误的类型(或者将其作为错误的类型获取)。这当然是一个好处。

  • I view the expressiveness as very important. I can glance at the declaration of a method and know what to expect from the return value - I don't need to read the documentation quite as closely, or give variables quite as unwieldy names or docs. In addition you get all the benefits of Intellisense etc. One of the questions to ask about a language is "what can I express in it?" and generics allows much richer concepts to be expressed than before.

    我认为表达非常重要。我可以浏览一下方法的声明并知道返回值的期望 - 我不需要非常仔细地阅读文档,或者给变量提供非常笨拙的名称或文档。此外,您还可以获得Intellisense等的所有好处。有关语言的一个问题是“我能在其中表达什么?”和泛型允许表达比以前更丰富的概念。

#2


2  

Absolutely.

A conventional collection, such as the ArrayList, implicitly stores objects.

传统的集合(例如ArrayList)隐式存储对象。

This means, that doing this:

这意味着,这样做:

ArrayList list = new ArrayList();
list.Add(5);
list.Add("FooBar");

Is legitimate code. This introduces a handful of issues.

是合法的代码。这引入了一些问题。

  • Normally, you don't want to store different types in the same collection, and having compile time checking for this is nice.
  • 通常,您不希望在同一个集合中存储不同的类型,并且对此进行编译时检查是很好的。

  • When you store a value type (such as the integer 5 above), it must be boxed into a reference type before it can be stored in the collection.
  • 存储值类型(例如上面的整数5)时,必须先将其装入引用类型,然后才能将其存储在集合中。

  • When reading a value, you must cast it back from Object to the desired type.
  • 读取值时,必须将其从Object转换回所需的类型。

However, you eliminate all of these issues by using a generic collection:

但是,您通过使用泛型集合消除了所有这些问题:

List<int> list = new List();
list.Add(5);
// Compile Time Error.
list.Add("FooBar")

You also gain intellisense support when working directly with indices of the collection, instead of just generic "object" intellisense.

在直接处理集合的索引时,您也可以获得智能感知支持,而不仅仅是通用的“对象”智能感知。

#3


1  

Short answer: yes

简短回答:是的

Longer answer: There are really no downsides to using generic collections. Compile-time type checking eliminates the posibility of runtime errors from casting. Performance will be greater for built-in types such as integers, since boxing and unboxing are not needed (in contrast to Java generic collections, by the way)

更长的答案:使用通用集合确实没有缺点。编译时类型检查消除了转换时运行时错误的可能性。内置类型(如整数)的性能会更高,因为不需要装箱和拆箱(顺便说一下,与Java通用集合相比)

#1


5  

Of course. Why wouldn't you? More important than the performance, IMO, is the fact that generic APIs are more expressive. That goes for generic APIs in general, not just collections.

当然。你为什么不呢?比IMO更重要的是,通用API更具表现力。这通常适用于通用API,而不仅仅是集合。

EDIT: Just to clarify these a bit:

编辑:只是澄清这些:

  • Performance characteristics are slightly different between the generic and nongeneric collections for reasons of "they're different implementation" as well as the whole generic/nongeneric side. Obviously the generic version avoids boxing/unboxing and (in most use cases) an execution time cast when fetching. In practice this is only likely to be significant for value types, where the boxing comes into play. For large collections, it's the difference in memory usage which is likely to be more significant than the execution speed difference.

    由于“它们是不同的实现”以及整个通用/非通用方面的原因,通用和非通用集合之间的性能特征略有不同。显然,通用版本避免了装箱/拆箱和(在大多数使用情况下)获取时的执行时间。在实践中,这对于拳击发挥作用的价值类型来说可能很重要。对于大型集合,内存使用的差异可能比执行速度差异更大。

  • I'm slightly less bothered by the actual type-safety aspect. It's certainly a good thing, but I can't remember ever actually seeing a bug when using the nongeneric collections due to putting the wrong type in (or fetching it as the wrong type). It's certainly a benefit though.

    我对实际的类型安全方面的困扰略微减少。这当然是一件好事,但我记不起在使用非通用集合时实际上看到了一个错误,因为它输入了错误的类型(或者将其作为错误的类型获取)。这当然是一个好处。

  • I view the expressiveness as very important. I can glance at the declaration of a method and know what to expect from the return value - I don't need to read the documentation quite as closely, or give variables quite as unwieldy names or docs. In addition you get all the benefits of Intellisense etc. One of the questions to ask about a language is "what can I express in it?" and generics allows much richer concepts to be expressed than before.

    我认为表达非常重要。我可以浏览一下方法的声明并知道返回值的期望 - 我不需要非常仔细地阅读文档,或者给变量提供非常笨拙的名称或文档。此外,您还可以获得Intellisense等的所有好处。有关语言的一个问题是“我能在其中表达什么?”和泛型允许表达比以前更丰富的概念。

#2


2  

Absolutely.

A conventional collection, such as the ArrayList, implicitly stores objects.

传统的集合(例如ArrayList)隐式存储对象。

This means, that doing this:

这意味着,这样做:

ArrayList list = new ArrayList();
list.Add(5);
list.Add("FooBar");

Is legitimate code. This introduces a handful of issues.

是合法的代码。这引入了一些问题。

  • Normally, you don't want to store different types in the same collection, and having compile time checking for this is nice.
  • 通常,您不希望在同一个集合中存储不同的类型,并且对此进行编译时检查是很好的。

  • When you store a value type (such as the integer 5 above), it must be boxed into a reference type before it can be stored in the collection.
  • 存储值类型(例如上面的整数5)时,必须先将其装入引用类型,然后才能将其存储在集合中。

  • When reading a value, you must cast it back from Object to the desired type.
  • 读取值时,必须将其从Object转换回所需的类型。

However, you eliminate all of these issues by using a generic collection:

但是,您通过使用泛型集合消除了所有这些问题:

List<int> list = new List();
list.Add(5);
// Compile Time Error.
list.Add("FooBar")

You also gain intellisense support when working directly with indices of the collection, instead of just generic "object" intellisense.

在直接处理集合的索引时,您也可以获得智能感知支持,而不仅仅是通用的“对象”智能感知。

#3


1  

Short answer: yes

简短回答:是的

Longer answer: There are really no downsides to using generic collections. Compile-time type checking eliminates the posibility of runtime errors from casting. Performance will be greater for built-in types such as integers, since boxing and unboxing are not needed (in contrast to Java generic collections, by the way)

更长的答案:使用通用集合确实没有缺点。编译时类型检查消除了转换时运行时错误的可能性。内置类型(如整数)的性能会更高,因为不需要装箱和拆箱(顺便说一下,与Java通用集合相比)