c# – 在其静态构造函数中创建类的实例 – 为什么允许它?

前端之家收集整理的这篇文章主要介绍了c# – 在其静态构造函数中创建类的实例 – 为什么允许它?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
关于SO的另一个问题激发了我在C#中尝试这个代码
class Program
{
    static Program() 
    {
        new Program().Run();
    }

    static void Main(string[] args) { }

    void Run()
    {
        System.Console.WriteLine("Running");
    }
}

这会在运行时打印“正在运行”.

我实际上期望编译器抱怨这个.毕竟,如果该类尚未被静态构造函数初始化;我们怎样才能确定在它上面调用方法是否有效?

那么为什么编译器不会限制我们这样做呢?这有什么重要的使用场景吗?

编辑

我知道Singleton模式;问题的关键是为什么我可以在静态构造函数完成之前调用实例上的方法.到目前为止,JaredPar的答案对此有一些很好的推理.

解决方法

这是允许的,因为不允许它会更糟糕.像这样的代码会严重陷入僵局:
class A {
    public static readonly A a;
    public static readonly B b;
    static A() {
        b = new B();
        a = B.a;
    }
}

class B {
    public static readonly A a;
    public static readonly B b;
    static B() {
        a = new A();
        b = A.b;
    }
}

你当然是指着一把装满枪的脚.

CLI规范(Ecma 335)分区II,章节10.5.3.2“宽松保证”中记录了此行为:

可以使用属性beforefieldinit(第10.1.6节)标记类型,以指示§10.5.3.1中指定的保证不一定是必需的.特别是,不需要提供上面的最终要求:在调用或引用静态方法之前,不需要执行类型初始化程序.

[基本原理:当代码可以在多个应用程序域中执行时,确保最终保证变得特别昂贵.同时,对大量托管代码的检查表明,很少需要这种最终保证,因为类型初始化器几乎总是简单的初始化方法
静态字段.将其留给CIL发生器(因此,可能还有程序员)来决定是否需要这种保证因此在需要时以一致性保证为代价提供效率.
最终理由]

C#编译器确实在类上发出了beforefieldinit属性

.class private auto ansi beforefieldinit ConsoleApplication2.Program
       extends [mscorlib]System.Object
{
   // etc...
}
原文链接:https://www.f2er.com/csharp/244182.html

猜你在找的C#相关文章