OpCodes.Constrained 欄位
定義
重要
部分資訊涉及發行前產品,在發行之前可能會有大幅修改。 Microsoft 對此處提供的資訊,不做任何明確或隱含的瑕疵擔保。
限制其上可進行虛擬方法呼叫的類型。
public: static initonly System::Reflection::Emit::OpCode Constrained;
public static readonly System.Reflection.Emit.OpCode Constrained;
staticval mutable Constrained : System.Reflection.Emit.OpCode
Public Shared ReadOnly Constrained As OpCode
欄位值
備註
下表列出指令的十六進位和 Microsoft 中繼語言 (MSIL) 元件格式,以及簡短的參考摘要:
格式 | 元件格式 | Description |
---|---|---|
FE 16 <T > |
約束。 thisType |
在受限制的類型上呼叫虛擬方法,以做為 型別 T 。 |
constrained
只有在指令上callvirt
才允許前置詞。
此時 MSIL 堆疊的狀態必須如下所示:
Managed 指標
ptr
會推送至堆疊。 的類型ptr
必須是) 的 Managed 指標 (&
thisType
。 請注意,這與未取代callvirt
的指令案例不同,這需要 的thisType
參考。透過
argN
的方法自變數arg1
會推送至堆疊,就像使用未取代的callvirt
指令一樣。
前置 constrained
詞的設計目的是允許 callvirt
以統一的方式進行指令,而不論是 thisType
實值型別還是參考型別。
callvirt
method
當指令前面加上 constrained
thisType
時,會執行指令,如下所示:
如果
thisType
是參考型別 (,而不是值型別) 則會ptr
取值,並傳遞為 的method
『this』 指標。callvirt
如果
thisType
是實值型別並thisType
實作method
,則會ptr
將未修改為指令的 『this』 指標call
method
傳遞,以供method
實作。thisType
如果
thisType
是實值型別且thisType
未實method
作,則會ptr
取值、Boxed,並傳遞為指令的callvirt
method
『this』 指標。
唯有在、 ValueType或 Enum 上Object定義且未由 覆寫thisType
時method
,才會發生這個最後一個案例。 在此情況下,Boxing 會建立原始對象的複本。 不過,由於、 ValueType和 Enum 任何方法Object都無法修改 物件的狀態,因此無法偵測到這個事實。
前置 constrained
詞支援建立泛型程序代碼的 IL 產生器。 一般而言, callvirt
指令在實值型別上無效。 相反地,IL 編譯程式會根據所呼叫的 ptr
型別和方法,有效地執行上述的 『this』 轉換。 不過,當 ptr
是編譯時期未知的泛型型別時,就無法在編譯時期進行此轉換。
constrained
opcode 可讓 IL 編譯程式以統一的方式呼叫虛擬函式,與實值型別或參考型別無關ptr
。 雖然其適用於泛型類型變數的情況 thisType
,但 constrained
前置詞也適用於非泛型型別,並可減少以語言產生虛擬呼叫的複雜度,以隱藏實值類型和參考型別之間的差異。
使用前置 constrained
詞也會避免實值型別的潛在版本控制問題。 如果未使用前置 constrained
詞,則必須根據實值類型是否覆寫 System.Object 的方法,發出不同的 IL。 例如,如果實值類型V
覆寫 Object.ToString () 方法,V.ToString()
call
則會發出指令;如果沒有,box
則會發出指令和callvirt
Object.ToString()
指令。 如果稍後移除覆寫,則前一個案例中可能會發生版本控制問題,而後者則為新增覆寫時發生。
前置 constrained
詞也可用於實作介面方法的實作實作介面方法的值型別方法,可以使用 來變更 MethodImpl
。 constrained
如果未使用前置詞,編譯程式會強制選擇要在編譯時期系結的實值型別方法。 使用前置 constrained
詞可讓 MSIL 系結至在運行時間實作介面方法的方法,而不是在編譯時期實作。
下列 Emit 方法多載可以使用 constrained
opcode:
適用於
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應