详细介绍C#编译器
本文讲述C#编译器的一些问题，目的是防止错误使用本地变量。但是据我研究，这里面有“Bug”（注意双引号），那么会有什么有趣的“Bug”呢？首先大家看下一个简单的例子：
publicvoidTest()
{
{
inta;
}
{
inta;
}
} 在这个Test函数里面有两对打括号，标明两个互不相属的子范围。这里大家也许看的非常不习惯，因为没有人光秃秃的写这么两对大括号的。我跟大家说：没关系，编译器承认光秃秃的大括号的，这个也是标准C里面的规范之一，作用就是把大括号里面的所有东西认为是“一句话”，准确点讲是逻辑语句，同时内部是一个范围，约束范围内的本地变量不会往外传播。如果大家实在看不习惯了，可以自行加上诸如while(true)之类的前缀，就习惯了。
那么这段代码有什么Bug呢？没有，确实没有Bug，编译顺利通过。当然，显示了两个Warning，说a没有被用到，无伤大雅。我们首先来分析一下，编译器怎么给把这个给弄通过的呢？我们用Reflector来看一下（当然，因为没有切实的代码，所以只能够看IL，而不能够看C#）：
publichidebysiginstancevoidTest()cilmanaged
{
//CodeSize:2byte(s)
.maxstack0
.locals(
int32num1,
int32num2)
L_0000:nop
L_0001:ret
} 哦！原来编译器把内部的变量改名字了！或者说编译器把他们当作完全不同的两个变量来对待。同时我们在这里也可以看出来，实际上在IL里面时不区分范围的，只有本地变量着一个简单的概念。无论你在哪个范围，在什么时候开始声明，实际上都是在函数的一开始用一个.locals这样的伪语句来声明的。这么做是简单省事的办法，因为如果在用户源代码实际声明的地方才在栈上面开辟空间，那么最后函数退出的时候就不知道该释放多少栈空间了。当然这不是不可以解决的，但是那样的话增加了不必要的复杂度。如果我来设计.NET Framework，我也会通过高级语言的编译器来约束范围问题，而不是摆到IL里面去解决。（毕竟IL里面没有这样的功能不影响我们写程序）稍微引申一下，我们就知道，一个函数里面有多少个本地变量，取决于整个函数内部声明了多少本地变量，而与变量所在范围无关。在IL这一层里面暂时我们没有看到这样的优化工作，我们可以看看这样的代码最后被编译器编译成什么了（用Release模式编译）：
publicintTest()
{
intb;
b=newRandom().Next(5);
if(b<5)
{
inta=newRandom().Next(5);
Console.WriteLine(a);
b=a;
}
else
{
inta=newRandom().Next(10);
Console.WriteLine(a);
b=a;
}
returnb;
} Reflector 反编译结果：
publicintTest()
{
intnum1=newRandom().Next(5);
if(num1<5)
{
intnum2=newRandom().Next(5);
Console.WriteLine(num2);
returnnum2;
}
intnum3=newRandom().Next(10);
Console.WriteLine(num3);
returnnum3;
} 大家可以看到num1是b，num2和num3则是分别的两个a。事实上这两个a互相之间是没有任何冲突的，也就是说是完全可以重用的，编译原理里面也有一个变量重用的优化，但是这里看不到有这样的优化，我觉得比较吃惊。虽然说这也可以算是一种Bug（严格说来是也不是），但是我要说的“Bug”不是这个。
分析完上面这些基本知识，我就来劲了：
publicvoidTest()
{
{
inta;
}
{
inta;
}
inta;
} 看，编译出来之后却出现了错误：
error CS0136: A local variable named 'a' cannot be declared in this scope because it would give a different meaning to 'a', which is already used in a 'child' scope to denote something else
哦，原来这个跟声明的顺序还没有关系，只要子范围里面有a了，那就不能够再定义这个变量了。这个难道跟IL里面所有变量都在函数开始部分声明有关系？看起来好像是这么一回事，但是实际上不是，因为C#编译器完全可以像前面那样，把最后一个a当作另外一个变量。这到底是怎么回事呢？我们需要作本次探索的最后一个实验：
publicvoidTest()
{
a=2;
{
inta;
}
{
inta;
}
inta;
} 这下可好，除了刚才那个错误之外，还多出来另外一个：
error CS0103: The name 'a' does not exist in the class or namespace 'ConsoleApplication1.Class2'
也就是说，编译器根本就没有把后面那个a当作从函数一开始的地方定义来看待。但是这两个错误合起来反而容易让我们产生这样的错觉和悖论：
因为前面两个a在范围外面就应该消失其影响力，那就不应该跟后面的a产生冲突。但现在既然你说了，第三个a的定义根前面那两个a的其中某一个定义相冲突了，那我就只能够认为后面这个a实际上在前两个a被定义出来之前就已经存在了，因为后面这个a处于外层范围，它不会在内层范围失去作用之前失效，这样还能够解释得通。可是这么解释我只能够认为外层的a应该在函数一开始的地方就生效了（老式的C编译器有一段时间确实是这样的），可是偏偏还来一个CS0103错误！解释不通，有“Bug”！