摘要：
this morning microsoft announced that it will be releasing shared
source implementations of the .net common language infrastructure (cli),
c# compiler, and ecmascript compiler for both window......
摘要：
writing secure code using csharp......
C#首席设计师AndersHejlsberg专访(二)
我认为,我认为我们使用的il的方式对此感兴趣:我们给你一个选择—如果你愿意—你可以控制把il编译或翻译为本地代码的时机.实际上,使用受管制的 c++,你可以直接从源程序生成本地代码.受管制的 c++还可以生成il,就象c#与vb那样.当你安装你的代码时,我们给你一个编译选项,可把il编译成本地代码.因此,当你运行它们时,就不会有即时编译负担.我们还给你提供了一个动态运行与编译代码的选项—即时编译.有了il,就给你带来了很多便利,比如它提供了这些能力:移植到不同的cpu结构并引入真正的类型安全并在此之上创建安全的系统.
我认为我们il的设计与java字节码关键的不同在于,我们做出了超前的决定—不用解释器.我们的代码永远本地运行.因此,即使产生il,你也不会运行解释器.我们还有不同风格的jit.对于精简框架,我们有econnojit,就象我们称呼它的一样,它是一个非常简单的jit[编注:精简.net是.net框架的一个子集,是为移植到其它设备与平台设计的].对于桌面版,我们有完全功能的jit.我们甚至有可与我们的c++编译器共用一个后端的jit.不过,这都会比较耗时,因此你只应该在安装时使用它们.
一旦你做出偏向于执行本地代码而不是解释码的决定,它就会深深地影响il设计.它改变了应该包括那些指令,应该包括哪些类型信息,以及它应该如何传输.如果你仔细看看两个il[译注:即.net il与java字节码],你就会发现它们非常不同.从某种意义上讲,我们的il是类型中立的.指令里没有指定参数类型的信息.进一步说,它是靠已经压栈的东西推断出来的.这种方式使il更为精简.无论如何,一个jit编译器需要知道哪些信息,因此没有理由在指令里携带它们.所以,最终我们做出了不同的设计决定,而这使得容易把il翻译成本地代码.
osborn:
解释方式与你描述的方式有何不同?
hejlsberg:
解释器的核心是一个循环—从p-code流取得一些字节,然后进入一个大大的switch[译注:类似于程序语言里的switch...case]声明:“哦,这是add指令,因此它到这儿来,但是这不是…”等等.
解释器模拟cpu.我们反其道而行之,我们只走一条道,我们一直都走一条道,我们把指令翻译为机器码.现在,在econojit的情况下,机器码实际上非常简单,它只创建一个调用与压栈指令的列表,并且调用运行时帮助器,然后运行时帮助器替换这个列表.当然,这个代码比解释器代码执行得快.
osborn:
让我用一句话来总结一下:你们完全编译代码.因此当你编译完时,字节已经完全准备好运行了,尽管从il翻译成机器码的时机可能不同.
hejlsberg:
是的.但是,如果它是在一个内存受限的小设备的环境里,有可能当运行完就被扔掉了.
osborn:
让我们进入语法细节.我在想,c#是否包括对正则表达式的内建支持.我没有在语言参考里看到它,或许它可能在别的什么地方吧....
下一页 摘要：
using system.text.regularexpressions;
using system;
class validation
{
public static void main()
{
string strtotest;
validation objvalidate=new validation();
console.write("enter ......
