Generics provide a solution to this limitation in earlier versions of the common language runtime and the C # language, which were implemented by casting between types and universal base type <xref:System.Object>. By creating a generic class, you can create a collection that is type-safe at compile-time.
Limitations of using Non-generic collection classes can be demonstrated by writing a small program that uses the <xref:System.Collections.ArrayList> collection classes in the. NET Framework class Library. <xref:System.Collections.ArrayList> is a very handy collection class that can be used to store any reference or value type without modification. C # Replication
The. NET Framework 1.1 Way to create a list:
System.Collections.ArrayList list1 = new System.Collections.ArrayList ( );
List1. ADD (3);
List1. Add (a);
System.Collections.ArrayList list2 = new System.Collections.ArrayList ();
List2. ADD ("It is raining in Redmond.");
List2. ADD ("It is snowing in the mountains");
But this convenience comes with a price to pay. Any reference or value type added to <xref:System.Collections.ArrayList> will be implicitly cast up to <xref:System.Object>. If the item is a value type, the boxing operation must be done when it is added to the list, and the unboxing operation is done when it is retrieved. Casting and boxing and unboxing operations degrade performance, and the effect of boxing and unboxing is obvious in cases where large collections must be cycled.
Another limitation is the lack of compile-time type checking, because <xref:System.Collections.ArrayList> will cast all items to <xref:system.object> Therefore, it is not possible at compile time to prevent client code from performing operations similar to the following: C # replication
System.Collections.ArrayList list = new System.Collections.ArrayList ();
Add an integer to the list.
List. ADD (3);
Add a string to the list. This is compile, but may cause the error later.
List. ADD ("It is raining in Redmond.");
int t = 0;
This causes a InvalidCastException to be returned.
foreach (int x in list)
{
T + = x;
}
Although the practice of combining strings and ints in one <xref:System.Collections.ArrayList> is perfectly acceptable when creating heterogeneous collections, and sometimes intentional, it is likely to generate programming errors, And this error cannot be detected until run time.
In versions 1.0 and 1.1 of the C # language, it is only possible to avoid the dangers of common code in the. NET Framework base Class Library collection class by writing your own type-specific collections. Of course, because this class cannot be reused for multiple data types, the benefits of generalization are lost, and you must rewrite the class for each type that you want to store.
The real need for <xref:System.Collections.ArrayList> and other similar classes is that the client code specifies, on a per-instance basis, the specific data types to use for these classes. This will no longer require an upward cast to T:System.Object and, at the same time, allow the compiler to perform type checking. In other words,<xref:system.collections.arraylist> requires a type parameter. This is what generics can provide. In the generics <xref:System.Collections.Generic.List%601> collection of the N:System.Collections.Generic namespace, adding items to the collection is similar to the following: C # replication
The. NET Framework 2.0 Way to create a list
list<int> list1 = new list<int> ();
No boxing, no casting:
List1. ADD (3);
Compile-time Error:
//List1. ADD ("It is raining in Redmond.");
For client-side code, compare with <xref:System.Collections.ArrayList>, use <xref:System.Collections.Generic.List%601> The only syntax you add is the type parameter in the declaration and instantiation. While this approach increases the complexity of coding slightly, the advantage is that you can create a more secure and faster list than <xref:System.Collections.ArrayList>, especially for list items that are value types.