古詩詞大全網 - 藝術簽名 - c#中的泛型究竟是什麽東西了

c#中的泛型究竟是什麽東西了

泛型:通過參數化類型來實現在同壹份代碼上操作多種數據類型。利用“參數化類型”將類型抽象化,從而實現靈活的復用。

例子代碼:

class Program

{

static void Main(string[] args)

{

int obj = 2;

Test<int> test = new Test<int>(obj);

Console.WriteLine("int:" + test.obj);

string obj2 = "hello world";

Test<string> test1 = new Test<string>(obj2);

Console.WriteLine("String:" + test1.obj);

Console.Read();

}

}

class Test<T>

{

public T obj;

public Test(T obj)

{

this.obj = obj;

}

}

輸出結果是:

int:2

String:hello world

程序分析:

1、 Test是壹個泛型類。T是要實例化的範型類型。如果T被實例化為int型,那麽成員變量obj就是int型的,如果T被實例化為string型,那麽obj就是string類型的。

2、 根據不同的類型,上面的程序顯示出不同的值。

C#泛型機制:

C#泛型能力有CLR在運行時支持:C#泛型代碼在編譯為IL代碼和元數據時,采用特殊的占位符來表示範型類型,並用專有的IL指令支持泛型操作。而真正的泛型實例化工作以“on-demand”的方式,發生在JIT編譯時。

看看剛才的代碼中Main函數的元數據

.method private hidebysig static void Main(string[] args) cil managed

{

.entrypoint

// Code size 79 (0x4f)

.maxstack 2

.locals init ([0] int32 obj,

[1] class CSharpStudy1.Test`1<int32> test,

[2] string obj2,

[3] class CSharpStudy1.Test`1<string> test1)

IL_0000: nop

IL_0001: ldc.i4.2

IL_0002: stloc.0

IL_0003: ldloc.0

IL_0004: newobj instance void class CSharpStudy1.Test`1<int32>::.ctor(!0)

IL_0009: stloc.1

IL_000a: ldstr "int:"

IL_000f: ldloc.1

IL_0010: ldfld !0 class CSharpStudy1.Test`1<int32>::obj

IL_0015: box [mscorlib]System.Int32

IL_001a: call string [mscorlib]System.String::Concat(object,

object)

IL_001f: call void [mscorlib]System.Console::WriteLine(string)

IL_0024: nop

IL_0025: ldstr "hello world"

IL_002a: stloc.2

IL_002b: ldloc.2

IL_002c: newobj instance void class CSharpStudy1.Test`1<string>::.ctor(!0)

IL_0031: stloc.3

IL_0032: ldstr "String:"

IL_0037: ldloc.3

IL_0038: ldfld !0 class CSharpStudy1.Test`1<string>::obj

IL_003d: call string [mscorlib]System.String::Concat(string,

string)

IL_0042: call void [mscorlib]System.Console::WriteLine(string)

IL_0047: nop

IL_0048: call int32 [mscorlib]System.Console::Read()

IL_004d: pop

IL_004e: ret

} // end of method Program::Main

再來看看Test類中構造函數的元數據

.method public hidebysig specialname rtspecialname

instance void .ctor(!T obj) cil managed

{

// Code size 17 (0x11)

.maxstack 8

IL_0000: ldarg.0

IL_0001: call instance void [mscorlib]System.Object::.ctor()

IL_0006: nop

IL_0007: nop

IL_0008: ldarg.0

IL_0009: ldarg.1

IL_000a: stfld !0 class ConsoleCSharpTest1.Test`1<!T>::obj

IL_000f: nop

IL_0010: ret

} // end of method Test`1::.ctor

1、第壹輪編譯時,編譯器只為Test<T>類型產生“泛型版”的IL代碼與元數據——並不進行泛型的實例化,T在中間只充當占位符。例如:Test類型元數據中顯示的<!T>

2、JIT編譯時,當JIT編譯器第壹次遇到Test<int>時,將用int替換“範型版”IL代碼與元數據中的T——進行泛型類型的實例化。例如:Main函數中顯示的<int>

3、CLR為所有類型參數為“引用類型”的泛型類型產生同壹份代碼;但是如果類型參數為“值類型”,對每壹個不同的“值類型”,CLR將為其產生壹份獨立的代碼。因為實例化壹個引用類型的泛型,它在內存中分配的大小是壹樣的,但是當實例化壹個值類型的時候,在內存中分配的大小是不壹樣的。

C#泛型特點:

1、如果實例化泛型類型的參數相同,那麽JIT編輯器會重復使用該類型,因此C#的動態泛型能力避免了C++靜態模板可能導致的代碼膨脹的問題。

2、C#泛型類型攜帶有豐富的元數據,因此C#的泛型類型可以應用於強大的反射技術。

3、C#的泛型采用“基類、接口、構造器,值類型/引用類型”的約束方式來實現對類型參數的“顯示約束”,提高了類型安全的同時,也喪失了C++模板基於“簽名”的隱式約束所具有的高靈活性

C#泛型繼承:

C#除了可以單獨聲明泛型類型(包括類與結構)外,也可以在基類中包含泛型類型的聲明。但基類如果是泛型類,它的類型要麽以實例化,要麽來源於子類(同樣是泛型類型)聲明的類型參數,看如下類型

class C<U,V>

class D:C<string,int>

class E<U,V>:C<U,V>

class F<U,V>:C<string,int>

class G:C<U,V> //非法

E類型為C類型提供了U、V,也就是上面說的來源於子類

F類型繼承於C<string,int>,個人認為可以看成F繼承壹個非泛型的類

G類型為非法的,因為G類型不是泛型,C是泛型,G無法給C提供泛型的實例化

泛型類型的成員:

泛型類型的成員可以使用泛型類型聲明中的類型參數。但類型參數如果沒有任何約束,則只能在該類型上使用從System.Object繼承的公有成員。如下圖:

泛型接口:

泛型接口的類型參數要麽已實例化,要麽來源於實現類聲明的類型參數

泛型委托:

泛型委托支持在委托返回值和參數上應用參數類型,這些參數類型同樣可以附帶合法的約束

delegate bool MyDelegate<T>(T value);

class MyClass

{

static bool F(int i){...}

static bool G(string s){...}

static void Main()

{

MyDelegate<string> p2 = G;

MyDelegate<int> p1 = new MyDelegate<int>(F);

}

}

泛型方法:

1、C#泛型機制只支持“在方法聲明上包含類型參數”——即泛型方法。

2、C#泛型機制不支持在除方法外的其他成員(包括屬性、事件、索引器、構造器、析構器)的聲明上包含類型參數,但這些成員本身可以包含在泛型類型中,並使用泛型類型的類型參數。

3、泛型方法既可以包含在泛型類型中,也可以包含在非泛型類型中。

泛型方法聲明:如下

public static int FunctionName<T>(T value){...}

泛型方法的重載:

public void Function1<T>(T a);

public void Function1<U>(U a);

這樣是不能構成泛型方法的重載。因為編譯器無法確定泛型類型T和U是否不同,也就無法確定這兩個方法是否不同

public void Function1<T>(int x);

public void Function1(int x);

這樣可以構成重載

public void Function1<T>(T t) where T:A;

public void Function1<T>(T t) where T:B;

這樣不能構成泛型方法的重載。因為編譯器無法確定約束條件中的A和B是否不同,也就無法確定這兩個方法是否不同

泛型方法重寫:

在重寫的過程中,抽象類中的抽象方法的約束是被默認繼承的。如下:

abstract class Base

{

public abstract T F<T,U>(T t,U u) where U:T;

public abstract T G<T>(T t) where T:IComparable;

}

class MyClass:Base

{

public override X F<X,Y>(X x,Y y){...}

public override T G<T>(T t) where T:IComparable{}

}

對於MyClass中兩個重寫的方法來說

F方法是合法的,約束被默認繼承

G方法是非法的,指定任何約束都是多余的

泛型約束:

1、C#泛型要求對“所有泛型類型或泛型方法的類型參數”的任何假定,都要基於“顯式的約束”,以維護C#所要求的類型安全。

2、“顯式約束”由where子句表達,可以指定“基類約束”,“接口約束”,“構造器約束”,“值類型/引用類型約束”***四種約束。

3、“顯式約束”並非必須,如果沒有指定“顯式約束”,範型類型參數將只能訪問System.Object類型中的公有方法。例如:在開始的例子中,定義的那個obj成員變量。比如我們在開始的那個例子中加入壹個Test1類,在它當中定義兩個公***方法Func1、Func2,如下圖:

基類約束:

class A

{

public void Func1()

{ }

}

class B

{

public void Func2()

{ }

}

class C<S, T>

where S : A

where T : B

{

public C(S s,T t)

{

//S的變量可以調用Func1方法

s.Func1();

//T的變量可以調用Func2方法

t.Func2();

}

}

接口約束:

interface IA<T>

{

T Func1();

}

interface IB

{

void Func2();

}

interface IC<T>

{

T Func3();

}

class MyClass<T, V>

where T : IA<T>

where V : IB, IC<V>

{

public MyClass(T t,V v)

{

//T的對象可以調用Func1

t.Func1();

//V的對象可以調用Func2和Func3

v.Func2();

v.Func3();

}

}

構造器約束:

class A

{

public A()

{ }

}

class B

{

public B(int i)

{ }

}

class C<T> where T : new()

{

T t;

public C()

{

t = new T();

}

}

class D

{

public void Func()

{

C<A> c = new C<A>();

C<B> d = new C<B>();

}

}

d對象在編譯時報錯:The type B must have a public parameterless constructor in order to use it as parameter 'T' in the generic type or method C<T>

註意:C#現在只支持無參的構造器約束

此時由於我們為B類型寫入了壹個有參構造器,使得系統不會再為B自動創建壹個無參的構造器,但是如果我們將B類型中加壹個無參構造器,那麽對象d的實例化就不會報錯了。B類型定義如下:

class B

{

public B()

{ }

public B(int i)

{ }

}

值類型/引用類型:

public struct A { }

public class B { }

public class C<T> where T : struct

{

}

C<A> c1 = new C<A>();

C<B> c2 = new C<B>();

c2對象在編譯時報錯:The type 'B' must be a non-nullable value type in order to use it as parameter 'T' in the generic type or methor 'C<T>'.............

/Static/CC/SuanFa/2010-07/157.htm