仍是新生事物——C#C# 对多数人来说还都是新生事物，毕竟是微软酝酿了几年的产品了，在 2002 年正式推出以来对大家都是很新鲜的。C# 和 Java 一样，需要一个运行环境，而不像 C++ 只要编译以后直接运行就可以。 C# 对多数人来说还都是新生事物，毕竟是微软酝酿了几年的产品了，在 2002 年正式推出以来对大家都是很新鲜的。C# 和 Java 一样，需要一个运行环境，而不像 C++ 只要编译以后直接运行就可以。 当年 2001 年的时候听微软王建硕的讲座，他也发了一些光盘，我当时也因为提了一个问题而拿到一套，是 VS .NET Beta1。当时我提的什么问题我已经记不起了……不过我还记得一些他当时讲的东西：int 可以看作 object，所有语言都编译成中间语言 IL，中间语言程序在执行时再由 JIT 编译器编译成 native code。内存管理是用 garbage collectior 的，所以 new 了以后不必显式 delete。 从我的理解来说，所有语言都编译成中间语言 IL，中间语言程序在执行时再由 JIT 编译器编译成 native code，这是与传统编译语言最大的不同，也是与 java 不同之处。C++ 编译时需要编译器的参与，编译完成以后只要操作系统就可以运行了，或者连操作系统都不需要。C# 事先编译成 IL，此间把所有查错、高级代码优化都做了，然后在第一次运行的时候再由 JIT（just in time 编译器）编译为 native code，而且运行时还需要 garbage collector 的支持。我想 CLR 大概就包含 JIT 和 garbage collector 这样的环境吧。 从运行的时间效率来讲，如果不涉及内存分配，C# 程序是肯定比不上 C++ 程序的。这是因为 C# 程序虽然会被编译为 native code，但是 bounds checking 的额外工作 JIT 编译出来的代码在运行时还是会做一下的，这是因为 C# 天生要成为一种“安全”的语言，所谓 managed code。但是涉及内存分配时，情况就比较复杂了。对 C++ 程序来说，malloc 等函数的速度有时候可能比较快，有时候可能比较慢。某些 malloc 函数在分配时就做了相当的优化工作，这使将来的分配与释放变得同样高效。某些 malloc 函数在分配时做的优化不多，而当后期分配与释放的操作多了以后，内存碎片增加了以后，效率则可能比较低，况且用 malloc 分配的内存还不能移动。C# 使用 garbage collector，好处是已分配好的内存块可以移动，以消除内存碎片，分配时则只需一路向前分配即可，而且 garbage collector 会自动回收已分配的内存。但是移动已分配好的内存块需要改变既有指针的地址，回收已分配的内存也是分批进行的，这也是耗时的工作。所以从内存分配的效率来讲，我也不清楚到底是 C++ 快还是 C# 快。 从运行的空间效率来讲，C# 需要一个 CLR，所以在短时间内肯定是 C++ 消耗的内存空间更少。但是从长时间来看，CLR 有机会进行内存碎片整理，而 C++ 一般则没有这种机会，因此，可能 C++ 反而消耗内存又会多于 C#。正因为这样原因，所以单单实现了最佳匹配的内存分配算法还不一定足够应付复杂的内存分配方案。一种措施是在分配内存的时候，如果分配的是可变长度的对象，比如字符串，那就把它扩大到二幂次。这样可以减少内存碎片，从而提高空间利用率。还有一种办法是使用优化的低碎片堆（Low Fragmentation Heap），或优化了的 malloc 函数。低碎片堆在 Windows XP/Server 2003 的 API 中得到了实现。 从编程来讲，C# 有内置的 bounds checking 和 garbage collection，因此编程出错的概率会降低不少，也给初学者降低了门槛。这是不错的。但是某些不是内置管理的地方，如 User 对象与 GDI 对象的使用、数据库连接的建立与释放等等还是应当注意的。另外 C# 与 C++ 我认为不属于同一语系，因为 C# 里面除了结构体以外，所有对象的标志符都是引用。它和 java 倒是比较像。另外它支持属性，所以又和 BCB、Delphi 和 VB 比较像。 自打进了单位工作，基本上都是在用 C# 编程，感觉还行，除了类库要重新适应以外，其他的问题也不大。不过业余时候还是喜欢用 C++ 写程序。 |