编译器直接支持的数据类型成为基元类型。基元类型与FCL中的类型有直接的映射关系[int=Int32],这样我们可以简化的方式书写代码,并且编译后的IL和直接使用FCL中的数据类型是完全相同的。
Checked和Unchecked操作:
Byte b=100;
b=(Byte)(b+200);
CLR只在32位和64位上进行算数运算,所以b首先会被转换为32位的值再和100相加,得到的是32位的值,接着转型为Byte,再然后将其放入b的存储堆栈。但是b的结果是44,反生了溢出,并不是期望的300[当然b也存不下300],然而却并没提示什么异常或错误。这是因为C#编译器默认是不检查溢出的。可以使用/checked+命令行开关。但是这是针对所有的代码都进行溢出检查,会试代码的效率有所下降。C#中的checked和unchecked操作符则提供了更好的灵活性。
b=checked((Byte)(b+200));这样再运行此行的话就会抛出 System.OverflowException[算术运算导致溢出]异常;相反unchecked则是不检查溢出,不会抛出异常。
System.Decimal是一个特殊的类型,虽然C#把它当作基元类型,但是CLR却不是,意味着CLR没有直接操作Decimal的IL指令,查看msdn中Decimal类型的文档可以发现它提供了Add、Divide、、、静态方法及一些操作符[+-*/...]重载方法,当我们使用它的值运算时实际上是调用它的成员来执行的,所以效率会比其他基元类型差些[CLR为其他基元类型直接提供了运算的IL指令,省去了操作符的重载],因为也没IL指令,所以checked和unchecked对它没有任何影响,如果对它的操作没有安全执行,则抛出System.OverflowException异常。
作为局部变量时值类型位于线程堆栈上,引用类型位于托管堆;作为类型成员时,则由其所属类型决定。托管代码中,我们定义的类型决定了它在内存中的分配位置,而我们对此没有控制的权限。另外值类型不受GC的控制。C#中值类型不允许定义Finalize方法[只有值类型装箱后才可能被调用],CLR允许,但是CLR执行垃圾清理时比不会调用它,所以为值类型定义Finaliza方法是没有意义的。
控制类型中字段的布局:System.Runtime.InteropServices.StructLayout特性来告诉CLR如何布局类型中的字段;C#编译器为引用类型选LayoutKind.Auto,让CLR自己排列字段。为值类型选择LayoutKind.Sequential,让CLR保留我们自己定义的字段布局。当然我们也可以通过此特性来改变编译器的默认行为。
装箱过程:从托管堆中为新生成的引用类型对象分配内存[大小是值类型成员本身的大小加上附加成员的大小];再把值类型的实例字段拷贝到托管堆上新对象的内存中,然后返回对象的引用。
拆箱过程:获取指向对象中包含的值类型部分[数据字段]的指针,不会涉及字段拷贝。
然而紧接着拆箱之后的典型操作往往是字段拷贝。--所以装箱和[拆箱+字段拷贝]总体互反。另外装箱操作装进去什么类型就要拿什么类型来拆,不然你装进去一个大苹果[int],拆除一个小苹果[byte]、或者拆出一个string[桔子],你会愿意吗?装箱和拆箱\字段拷贝会从速度和内存上损伤程序的性能。尽量的避免这些操作