C # v2.0 extension characteristics (2)

zhaozj2021-02-16  107

Generic Type Instantiations

Fan model

Similar to a non-generic type, the compiled representation of a generic type is intermediate language (IL) instructions and metadata. The representation of the generic type of course also encodes the existence and use of type parameters.

Similar to non-floats, generics are compiled into intermediate code instructions and metadata. The generic representation is of course also encoding the existing and use type parameters.

The first time an application creates an instance of a constructed generic type, such as Stack , the just-in-time (JIT) compiler of the .NET Common Language Runtime converts the generic IL and metadata to native code, substituting actual types for type parameters in the process. Subsequent references to that constructed generic type then use the same native code. The process of creating a specific constructed type from a generic type is known as a generic type instantiation.

When the application creates a newly constructed generic, such as stack , jit when the NET public runtime is used to transform generic intermediate code and metadata into this local code, replaced in the process in the process. Type parameters. Later, the local code is running in the generics that has been constructed. Creating a generic instantiation called genericity based on the specified build type.

The .NET Common Language Runtime creates a specialized copy of the native code for each generic type instantiation with a value type, but shares a single copy of the native code for all reference types (since, at the native code level, references are just pointers WITH THE SAME REPRESENTATION.

To create a special local code copy for generics for each value type. But share a separate local code copy for all reference types. (Because, in the local code level, reference and pointer are the same indication)

19.1.2 Constraints

constraint

Commonly, a generic class will do more than just store data based on a type parameter. Often, the generic class will want to invoke methods on objects whose type is given by a type parameter. For example, an Add method in a Dictionary Class Might NEED TO Compare Keys Using a Compareto Method:

In general, a generic class can not only store data on the type parameters, but also do more. Typically, generic classes attempt to call methods on the specified type object. For example, an Add method in Dictionary may need to be a keyword with a CompareTo method. Public Class Dictionary {Public Void Add (K Key, V Value) {... IF (Key.Compareto (x) <0) {...} // error, no compareto method ...} } Since the type argument specified for K could be any type, the only members that can be assumed to exist on the key parameter are those declared by type object, such as Equals, GetHashCode, and ToString; a compile-time error therefore occurs in It is of course Possible to cast the key parameter to cast the key parameter to a Type That Contains a Compareto Method. for Example, The Key Parameter Could Be Cast To iComparable:

However, type parameter k may be any type, and the only member variable that is assumed to be in the Key parameter is declared by the object type, such as Equal, GetHashCode, and Tostring; the above code will trigger a compile time error. Of course, you can also put the key.

The parameter is converted into a type containing the Compareto method. For example, the Key parameter may be converted into an IComparable interface.

Public Class Dictionary {public void add (k Key, V Value) {... IF ((iComparable) key) .compareto (x) <0) {...} ...}} while this solution works, it requires a dynamic type check at run-time, which adds overhead. It furthermore defers error reporting to run-time, throwing an InvalidCastException if a key does not implement IComparable.

When the above solution runs, add a dynamic type check at the above code requirements. And it reports an error when running and throws an InvalidCastException when Key does not support IComparable interface.

To provide stronger compile-time type checking and reduce type casts, C # permits an optional list of constraints to be supplied for each type parameter. A type parameter constraint specifies a requirement that a type must fulfill in order to be used as an argument for that type parameter. Constraints are declared using the word where, followed by the name of a type parameter, followed by a list of class or interface types, or the constructor constraint new (). in order to provide stronger compile-time type checking and reduction type Conversion, C # allows an optional constraint list to provide each type of parameters. As a type of parameter constraint, a type parameter constraint specifies a type that must be fully fulfilled. Constrained via the keyword where declaration, followed by the name of the type parameters, follow up a string or interface, or a constraint constructor new ()

In Order for the Dictionary Class To Ensure That Keys Always Implement ICFE, The Class Declaration Can Specify A ConsTRAINT for the Type Parameter K:

In order to ensure the KEY of Dictionary class supports the IComparable interface, the category declaration specifies a constraint of a type parameter.

Public Class Dictionary WHERE K: IComparable {public Void Add (K Key, V Value) {... IF (Key.Compareto (x) <0) {...} ...}} given this declaration the compiler will ensure that any type argument supplied for K is a type that implements IComparable Furthermore, it is no longer necessary to explicitly cast the key parameter to IComparable before calling the CompareTo method;. all members of a type given as a constraint for A Type Parameter Are Directly Available on Values ​​of That Type Parameter Type.

After specifying, the compiler will ensure that any type of parameters supplied to K must support the IComparable interface. Moreover, before calling the CompareTo method, it no longer needs to explicitly support the key parameter to support the IComparable interface. All members given by a type of parameters are visible directly on the type value.

For a given type parameter, it is possible to specify any number of interfaces as constraints, but no more than one class. Each constrained type parameter has a separate where clause. In the example below, the type parameter K has two interface constraints, while The Type Parameter E HAS A Class Constraint and a Constructor Constraint: As a given type parameter, but a class may specify any number of interfaces as constraints. Each constraint type parameter has a WHERE clause separation. In the following example, the type parameter k has two interface constraints, however the type parameter E has a class constraint and a build constraint.

Public Class EntityTable WHERE K: IPMPARABLE , IPERSISTABLEWHERE E: ENTITY, New () {public void add (k Key, E Entity) {... IF (key.compareto (x) <0) {...} ...}} the constructor constraint, new (), in the example Above en Sures That a type used as a type argument for e HAS a public, parameterless constructor, and it permits the generic class to use new e .

Construction constraints in the above example () ensure that the type of type E has a public, non-parameter build function, and it allows generic classes to create instances of this type using new e ().

Type parameter constrains should be used with care. While they provide stronger compile-time type checking and in some cases improve performance, they also restrict the possible uses of a generic type. For example, a generic class List might constrain T to implement IComparable such that the list's Sort method can compare items. However, doing so would preclude use of List for types that do not implement IComparable, even if the Sort method is never actually called in those cases.

Type parameter constraints should be careful. They offer stronger compile time type checks and can improve performance in some examples, and can constrain generic usage possibilities. For example, a List generic may constrain T to implement the IComparable interface, so that the Sort method of the List can compare items. However, this will make the type that does not support ICOMPARABLE interfaces cannot use List , even if the SORT method is not called in the case.

转载请注明原文地址:https://www.9cbs.com/read-14097.html

New Post(0)