Visual Studio 2005 Experience generics programming

Visual Studio 2005 brings a type-parameterized model of generic programming to the Microsoft. NET Framework. Of course, type parameterization is a matter for C + + programmers. So, for those of you who are not familiar with them, I'll make a brief introduction to generic programming in this article.

The basic idea of generic programming is to deliver a fixed code base that supports a potential collection of infinite types. There are two general models for generic programming: The generic type container model (Universal type Container MODEL,UTCM) and the type parameterized model (type Parameter MODEL,TPM).

In UTCM, the type information associated with the object has been stripped. Because it is reversible, it is easy to implement. All objects are stored in a uniform, non-transparent manner. In a single type system such as the CTS (Common type System), the generic type container is the object; All CTS types derive directly or indirectly from object. For example, in the C language, void * is the common type.

In the TPM, the binding of type information associated with an object has been refined and deferred. From one call to another, values vary in variety and are refined as parameters. That's why this implementation model is called a parameterized type-it's more complex, but powerful.

For example, you are implementing a IEnumerator interface for a system::collections namespace. As long as it provides two methods and one property, it seems simple. However, in strongly typed languages, it is difficult to imagine the difficulty of providing a single interface that is available to all users. It is difficult in our implementation can no longer use the "???";

Interface class IEnumerator
{
Property??? Current {??? Get ();}
BOOL MoveNext ();
void Reset ();
};

The type system requires that you statically identify the type of memory backfill associated with the attribute and obtain the return type of the accessor (accessor), but this is of course impossible. The user needs to enumerate the potential types without counting. What are you going to do?

A simpler conventional solution is UTCM, where objects are used as containers.
Interface class IEnumerator
{
Property object^ Current {object^ get ();}
BOOL MoveNext ();
void Reset ();
};

This provides some degree of isolation. It allows the use of a single immutable code base to support potentially infinitely many types. And for passive storage and reference type Object acquisition, its performance is quite impressive.

Once you need to get and process the object like the concrete type, things get a little less elegant. This requires casting down to the original object type. Unfortunately, the compiler does not have the necessary type information to guarantee the correctness of the coercion type conversion, causing the programmer to manually explicitly convert downward, as shown in the following example:

extern void F (object^ anytypeworks);
object^ o = "A string of all things";

No downcast ... passive storage
f (o);

Downcast. We need to manipulate
string^ s = safe_cast (o);

There are more problems implementing the collection because a collection cannot be statically constrained to accommodate only a single type of object under the generic type container model. This can only be provided from the program level, and is slightly more complex and error-prone. Also, because it is a program solution, it can only be used during runtime. You don't get the compiler support again.

In addition to security and complexity, it involves mass storage and the performance issues of getting value types under the generic type container model. With the help of type parameterization, these three problems are solved.