通用约束如何防止使用隐式实现的接口对值类型进行装箱？

Question

我的问题与此有点相关：显式实现的接口和通用约束。

然而，我的问题是编译器如何启用通用约束来消除对显式实现接口的值类型进行装箱的需要。

我想我的问题可以归结为两部分：

1. 在访问显式实现的接口成员时需要对值类型进行装箱的幕后 CLR 实现发生了什么，以及

2. 消除此要求的泛型约束会发生什么？

一些示例代码：

internal struct TestStruct : IEquatable<TestStruct>
{
    bool IEquatable<TestStruct>.Equals(TestStruct other)
    {
        return true;
    }
}

internal class TesterClass
{
    // Methods
    public static bool AreEqual<T>(T arg1, T arg2) where T: IEquatable<T>
    {
        return arg1.Equals(arg2);
    }

    public static void Run()
    {
        TestStruct t1 = new TestStruct();
        TestStruct t2 = new TestStruct();
        Debug.Assert(((IEquatable<TestStruct>) t1).Equals(t2));
        Debug.Assert(AreEqual<TestStruct>(t1, t2));
    }
}

生成的 IL：

.class private sequential ansi sealed beforefieldinit TestStruct
    extends [mscorlib]System.ValueType
    implements [mscorlib]System.IEquatable`1<valuetype TestStruct>
{
    .method private hidebysig newslot virtual final instance bool System.IEquatable<TestStruct>.Equals(valuetype TestStruct other) cil managed
    {
        .override [mscorlib]System.IEquatable`1<valuetype TestStruct>::Equals
        .maxstack 1
        .locals init (
            [0] bool CS$1$0000)
        L_0000: nop 
        L_0001: ldc.i4.1 
        L_0002: stloc.0 
        L_0003: br.s L_0005
        L_0005: ldloc.0 
        L_0006: ret 
    }

}

.class private auto ansi beforefieldinit TesterClass
    extends [mscorlib]System.Object
{
    .method public hidebysig specialname rtspecialname instance void .ctor() cil managed
    {
        .maxstack 8
        L_0000: ldarg.0 
        L_0001: call instance void [mscorlib]System.Object::.ctor()
        L_0006: ret 
    }

    .method public hidebysig static bool AreEqual<([mscorlib]System.IEquatable`1<!!T>) T>(!!T arg1, !!T arg2) cil managed
    {
        .maxstack 2
        .locals init (
            [0] bool CS$1$0000)
        L_0000: nop 
        L_0001: ldarga.s arg1
        L_0003: ldarg.1 
        L_0004: constrained !!T
        L_000a: callvirt instance bool [mscorlib]System.IEquatable`1<!!T>::Equals(!0)
        L_000f: stloc.0 
        L_0010: br.s L_0012
        L_0012: ldloc.0 
        L_0013: ret 
    }

    .method public hidebysig static void Run() cil managed
    {
        .maxstack 2
        .locals init (
            [0] valuetype TestStruct t1,
            [1] valuetype TestStruct t2,
            [2] bool areEqual)
        L_0000: nop 
        L_0001: ldloca.s t1
        L_0003: initobj TestStruct
        L_0009: ldloca.s t2
        L_000b: initobj TestStruct
        L_0011: ldloc.0 
        L_0012: box TestStruct
        L_0017: ldloc.1 
        L_0018: callvirt instance bool [mscorlib]System.IEquatable`1<valuetype TestStruct>::Equals(!0)
        L_001d: stloc.2 
        L_001e: ldloc.2 
        L_001f: call void [System]System.Diagnostics.Debug::Assert(bool)
        L_0024: nop 
        L_0025: ldloc.0 
        L_0026: ldloc.1 
        L_0027: call bool TesterClass::AreEqual<valuetype TestStruct>(!!0, !!0)
        L_002c: stloc.2 
        L_002d: ldloc.2 
        L_002e: call void [System]System.Diagnostics.Debug::Assert(bool)
        L_0033: nop 
        L_0034: ret 
    }

}

关键调用是 constrained !!T 而不是 box TestStruct，但后续调用仍然是 callvirt在这两种情况下。

因此，我不知道进行虚拟调用所需的装箱是什么，而且我特别不明白如何使用受限于值类型的泛型来消除装箱操作的需要。

我提前感谢大家...

Answer 1

但是，我的问题是编译器如何启用通用约束来消除对显式实现接口的值类型进行装箱的需要。

不清楚“编译器”是指抖动还是 C# 编译器。 C# 编译器通过在虚拟调用上发出约束前缀来实现此目的。请参阅约束前缀的文档了解详情。

在访问显式实现的接口成员时需要对值类型进行装箱的幕后 CLR 实现发生了什么

调用的方法是否是显式实现的接口成员并不特别相关。一个更普遍的问题是为什么任何虚拟调用都需要对值类型进行装箱？

传统上，人们认为虚拟调用是对虚拟函数表中方法指针的间接调用。这并不完全是接口调用在 CLR 中的工作方式，但对于本次讨论来说，这是一个合理的思维模型。

如果这就是调用虚拟方法的方式，那么 vtable 从何而来？值类型中没有 vtable。值类型仅在其存储中具有其值。装箱创建对对象的引用，该对象具有设置为指向所有值类型的虚拟方法的 vtable。 （我再次提醒您，这并不完全是接口调用的工作方式，但这是一个很好的思考方式。）

消除此要求的通用约束会发生什么？

抖动将为通用方法的每个不同值类型参数构造生成新鲜代码。如果您要为每种不同的值类型生成新的代码，那么您可以根据该特定的值类型定制该代码。这意味着您不必构建 vtable，然后查找 vtable 的内容是什么！您知道 vtable 的内容是什么，因此只需生成代码来直接调用该方法即可。

Answer 2

最终的目标是获得类的方法表的指针，以便调用正确的方法。这不能直接发生在值类型上，它只是一个字节块。有两种方法可以实现：

• Opcodes.Box，实现装箱转换，将值类型值转换为对象。该对象的方法表指针位于偏移量 0 处。Opcodes.Contrained
• ，直接将抖动传递给方法表指针，无需装箱。由通用约束启用。

后者显然效率更高。

Answer 3

当将值类型对象传递给期望接收类类型对象的例程时，装箱是必要的。像 string ReadAndAdvanceEnumerator(ref T thing) 这样的方法声明，其中 T:IEnumerator 实际上声明了一整套函数，每个函数都需要不同的类型 T。如果 T 恰好是值类型（例如 List.Enumerator），则即时编译器实际上会专门生成机器代码来执行 ReadAndAdvanceEnumerator.Enumerator>()。顺便说一句，请注意 ref 的使用；如果 T 是类类型（除了约束之外的任何上下文中使用的接口类型都算作类类型），则没有必要使用 ref效率的障碍。但是，如果 T 可能是 this 变异结构（例如 List.Enumerator），则使用ref 对于确保在执行 ReadAndAdvanceEnumerator 期间由结构执行的 this 突变将在调用者的副本上执行是必要的。

Answer 4

泛型约束仅提供编译时检查，以确保正确的类型被传递到方法中。最终结果始终是编译器生成接受运行时类型的适当方法：

public struct Foo : IFoo { }

public void DoSomething<TFoo>(TFoo foo) where TFoo : IFoo
{
  // No boxing will occur here because the compiler has generated a
  // statically typed DoSomething(Foo foo) method.
}

从这个意义上说，它绕过了对值类型装箱的需要，因为创建了直接接受该值类型的显式方法实例。

而当值类型转换为实现的接口时，实例是引用类型，位于堆上。因为我们在这个意义上没有利用泛型，所以如果运行时类型是值类型，我们将强制转换为接口（以及随后的装箱）。

public void DoSomething(IFoo foo)
{
  // Boxing occurs here as Foo is cast to a reference type of IFoo.
}

删除泛型约束只会停止编译时检查您是否将正确的类型传递到方法中。

Answer 5

我认为你需要使用

• 反射器
• ildasm / monodis

才能真正得到你想要的答案

你当然可以查看 CLR (ECMA) 的规范和/或 C# 编译器的源代码 (单声道)