探索系列:深入辨析 ReadOnly,Const
2007-12-23 00:38
447 查看
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文件格式里面的元数据表和托管进程的内存布局。
后记补记:[/b]
今天,又把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关键字的文章画上了一个比较完整的句号吧。
相关文章推荐
- 探索系列:深入辨析 ReadOnly,Const
- 深入探索C++对象模型之虚拟函数是否设置为const
- CLR探索系列:深入追踪托管exe加载执行过程
- C#基础知识系列八(const和readonly关键字)
- C#夯实基础系列之const与readonly
- 深入探索 boost::lambda 系列 (一)
- C#基础知识系列八(const和readonly关键字)
- C#基础加强二:const和readonly深入研究
- 《叩开C#之门》系列之五:const、readonly和static
- 深入理解c#中的const 和readonly的区别滴呀;
- C#基础知识系列八(const和readonly关键字)
- 源码探索系列2---深入解析AsyncTask
- C#基础:基于const与readonly的深入研究
- 深入探讨C#中的const、readonly关键字
- C#基础知识系列八const和readonly关键字详细介绍
- CLR探索系列(中):深入追踪托管exe加载执行过程
- CLR探索系列:深入追踪托管exe加载执行过程
- 《深入探究C语言》系列——1.专题简介
- 探索推荐引擎内部的秘密,第 2 部分: 深入推荐引擎相关算法 - 协同过滤
- 深入java集合系列:Vector