探索系列：深入辨析 ReadOnly，Const

      Last time ，when I was asked what is the diff between Readonly and Const，I was really ashamed that I said don’t know on explaining the exact difference between this two simple key word…

过后，特意研究了下这两个关键字究竟有何不同：

 

首先，从CLI中对CTS的Type的规定说起。在第四版本的ECMA-355的CLI标准中，规定的对于每一个Type，都可以包含很多成员。所有的成员（members），一共可以有三种：第一种叫做fields，它是定义的和这个类型相关的存储单元。第二中成员类型就是我们熟悉的方法（Method）。第三中，叫做nested type。也就是嵌套类型，对于每一个type里面，都可以包含对于别的type的声明和使用。

对于所有的成员，又可以分为两种：per-type member，per-instance member。顾名思义，前一种，是对于每一个type只有一个的成员，譬如static修饰的field。后一种，是对于每一个运行时候的实例，都保持一个不同的实现版本。

对于其他的类型的成员，包括我们熟知的Properties，Events之类，这些反编译成为IL语言之后可以看到，全部直接的，或者是间接的转换成为了方法。

 

有的时候，我们需要一个field在它的整个生命周期里面，它所包含的这个值是不改变的。这个时候，根据这个变量被赋值的不同的情况，CLR为提供了两种技术来实现这种要求：

第一种，field里面包含的值，可以在编译的时候被计算出来。就是const关键字声明的变量。这种方法的实现效率是最高的。这个值，是作为一个字面上的固定的值，保存在包含这个type的module文件的metadata里面。Const定义的这个值，可以是一个表达式，但是这个表达式的结果，必须是编译的时候可以计算出来的。这样，在编译的时候，就可以植入到其余的指令里面去。

Const定义的field，必须在定义的时候，就给初始化了，而且，一旦初始化了之后，就不能再改变它的值。同时，不能声明一个const的field为static，因为，const定义的field就表明这个field是一个static的。

任何对const定义的常量的修改，都会抛出一个编译时错误。

我们可以把const修饰的field，归类到member的per-type member里面去。

第二种，是被readonly修饰的field。Readonly修饰的常量，可能是因为，有的时候，我们需要一些field，它的值是不应该改变的，但是，在运行之前，是不知道这个值的，这个时候，就可以用readonly来修饰这个field。

这个readonly修饰的field，就为常量这个名词提供了另外一种灵活得多的解决方案了。首先，它的值，是可以在运行的时候，根据别的变量动态计算出来的，而const修饰的常量的值就不能这样了。同时，不同于const，它是一个per-instance member。也就是说，对于每一个实例，它都可以保存一个不同的实现版本，而const就不行了。对于某一个type的所有的实现实例，const定义的field，只能有一个不变的值。

 

写到这里，从原理的角度已经阐述的比较清楚了，接着用一个实例来分析下：

    class Program

    {

        public const int conField=122*1119;

        public readonly int roField;

        private int _property;

        public int Property

        {

            get

            {

                return _property;

            }

            set

            {

                _property = value;

            }

        }

 

        static void Main(string[] args)

        {

            (new Program()).Method();

        }

}

Diassemble之后，得到下面的显示结果：

.namespace TestConcoleApp

{

  .class private auto ansi beforefieldinit Program

       extends [mscorlib]System.Object

  {

       //这里可以看到，一个const定义的一个field，是literal，并且被static关键字来修饰。同时，在编译的时候，就计算得到了这个field的值。

    .field public static literal int32 conField = int32(136518)

       //readonly关键字修饰的field，只是被用initonly来修饰，per-instance类型。

    .field public initonly int32 roField

    .field private int32 _property

       //在程序的属性里面定义的get关键字，最终在这里被转换成为了一个方法来处理。

    .method public hidebysig specialname instance int32 get_Property() cil managed

    {

      .maxstack 1

      .locals init (int32)

 

      IL_0000:  nop       

      IL_0001:  ldarg.0   

      IL_0002:  ldfld      int32 TestConcoleApp.Program::_property

      IL_0007:  stloc.0   

      IL_0008:  br.s       IL_000a

      IL_000a:  ldloc.0   

      IL_000b:  ret       

    }

       //对上面的一个Property的set动作，最终在这里转化成为了一个方法

    .method public hidebysig specialname instance void set_Property(int32 'value') cil managed

    {

      .maxstack 8

     

      IL_0000:  nop        

      IL_0001:  ldarg.0   

      IL_0002:  ldarg.1   

      IL_0003:  stfld      int32 TestConcoleApp.Program::_property

      IL_0008:  ret       

    }

 

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

    {

      .entrypoint

      .maxstack 8

     

      IL_0000:  nop       

      IL_0001:  newobj     instance void TestConcoleApp.Program::.ctor()

      IL_000b:  nop       

      IL_000c:  ret       

    }

 

    .method public hidebysig specialname rtspecialname instance void .ctor() cil managed

    {

      .maxstack 8

     

      IL_0000:  ldarg.0   

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

      IL_0006:  ret       

    }

       //这里用property来表示一个属性，实际上是转换成为了两个方法来操作一个private修饰的field

    .property instance int32 Property()

    {

      .get instance int32 TestConcoleApp.Program::get_Property()

      .set instance void TestConcoleApp.Program::set_Property(int32)

    }

  }

}

 

再看了readonly和const被编译成为IL的代码之后，对这两个关键字到底是如何运作，有什么区别和相同的地方，又有了进一步的确认和了解。

 

后记：

其实，我还想验证一下，public const int conField=122*1119；这一句中122*1119的结果，在作为一个module的时候，是计算好了保存在一个扩展了的DotNet下的PE文件的Metadata里面，然后在验证一下，运行的时候，一个type有多个实例，而const定义的field只有一个的。

不过动用了一大批调试工具和托管模块结构查看工具，把PE格式文件里面的元数据表狠狠的都刨了一遍，也没找到这个值。在这个文件执行的时候，windbg attach到这个进程，把这个模块在的内存刨了一个遍，还是没找到这个常量具体的location….郁闷坏了

先就整理到这里吧，改天好好的分析下PE文件格式里面的元数据表和托管进程的内存布局。

      

后记补记：

今天，又把metadata的几种表结构的reference看了看，把上面生成的那个托管模块里里外外又刨了一次，用dumpbin+ildasm，在查看元数据表的时候，终于找到了上面用readonly和const定义的两个字段在元数据里面的表示：

       Field #1 (04000001)

       -------------------------------------------------------

              Field Name: conField (04000001)

              Flags     : [Public] [Static] [Literal] [HasDefault]  (00008056)

       DefltValue: (I4) 136518

              CallCnvntn: [FIELD]

              Field type:  I4

 

       Field #2 (04000002)

       -------------------------------------------------------

              Field Name: roField (04000002)

              Flags     : [Public] [InitOnly]  (00000026)

              CallCnvntn: [FIELD]

              Field type:  I4

       可以看到，在编译成为托管模块的时候，这个const定义的变量就被计算了出来，把值136518已经保存到了托管PE文件的元数据表里面。并且，还有static，literal，hasdefault这几个关键字来修饰。而readonly修饰的field，只有一个initonly来修饰。

       到这里，终于给这段刨根问底readonly和const关键字的文章画上了一个比较完整的句号吧。