2个关于.NET的基本但有趣的问题

1-差异语言有其优缺点。有一系列语言(功能性、动态、静态等)更适合特定的问题领域。你需要在每个家庭学习一个,知道什么时候选择哪个。例如,要编写一个简单的脚本,我会选择Ruby而不是C#

2-编译成CIL:可移植性可能不是什么大问题。但准确地说,mono在Linux上实现了clr。就这样。CIL还可以帮助您在运行在CLR上的语言之间进行混合和匹配。例如,IronRuby可以访问用C语言编写的标准框架库。它还使CLR能够利用运行程序的实际硬件(例如,启用优化、使用特定指令)。两台机器上的clr将为各自的机器从相同的il中生成最好的本机代码。

语言和平台选择是项目目标的函数。听起来你喜欢系统级的编程,这是使用C/C++的优点之一。所以,如果你喜欢的话,继续写系统级的代码。

用C编写在快速业务应用程序开发中非常强大,因为这些应用程序的目标本质上是不同的。更快地编写好的工作代码在工时和上市时间上都是物有所值的。微软为我们提供了一种表达性语言和一个坚实的功能框架,使我们不必为95%的业务需求编写低级代码或工具,这对我们是一个巨大的帮助。

IL的一个重要优势是语言独立。您可以定义项目中的模块,这些模块应该在C++中完成,一些在C中完成,有些在VB.net中完成。编译时,所有这些项目都提供各自的程序集(.dll/.exe)。这可以在C++语言中使用C++项目的程序集,反之亦然。这是可能的,因为……无论您选择哪种语言(支持.NET)。所有代码都编译为相同的IL代码。

我不确定C是否更有效,只是因为它是微软的产品。如果使用Visual Studio或其他RAD,某些代码是自动生成的,有时效率较低。几年前,我是一个教条主义者,认为只有C可以回应我们所有的祈祷:P,但现在我认为虚拟机可以在优化代码之前执行它(像一个RDBMS),存储在CACH_)代码块以后执行等方面提供很多帮助,包括像赤陶一样创建虚拟机的“集群”的可能性。至少拥有一个额外的抽象层的好处比没有它的更大。

我同意斯波森的观点。C非常擅长解决业务问题。您可以非常有效地创建一个为业务流程建模的框架,并通过面向对象和设计模式解决许多这些问题。在这方面,它提供了C++所具有的许多面向对象的能力。

如果你关心的是速度,c是你所说的原因的路线。

进一步讨论第二个问题:您可以运行ngen来生成程序集的本机映像,这可以提高性能。不完全是机器代码,但是由于它绕过了JIT(及时编译)阶段,应用程序的运行速度会更快。

http://msdn.microsoft.com/en-us/library/6t9t5wcf(VS.80).aspx

本机映像生成器(ngen.exe) 是改善 托管应用程序的性能。 ngen.exe创建本机映像,其中 文件是否包含已编译的 处理器特定的机器代码,以及 将它们安装到本机映像中 本地计算机上的缓存。这个 运行时可以使用来自 缓存而不是使用 要编译的实时(JIT)编译器 原始组件。

“那么还有什么别的原因吗?托普 速度,使用除 “C?”

我至少可以想到四个,都有点关联:

• 我现在在“语言X”上有一笔很大的投资,我没有时间或金钱去换别的东西。(移植现有的代码库,购买/获取/移植库,在C中重新开发团队技能,学习不同的工具。)
• 预期需要将代码移植到不支持C的平台。
• 我需要使用C_中没有的工具,或者没有得到很好的支持。(IDE、备用编译器、代码生成器、库、列表等等…)
• 我发现了一种更有效的语言。;-)

“编译的好处是什么? 进入CIL,然后由clr运行,然后 直接编译成机器 代码?”

这一切都是为了给运行时环境更多的控制代码的执行方式。如果你编译成machien代码,很多东西在那个时候就变成了“石头”。将编译推迟到机器代码,直到您对运行时环境有了更多的了解,才允许您以其他方式进行优化。就在我头顶上几下:

• 延迟编译允许您选择更接近主机CPU的指令。(当您拥有64位本机指令或最新的SSE扩展时使用它们。)
• 延迟代码可以让您以其他方式进行优化。(如果运行时只有一个从特定接口派生的类,则可以开始内联甚至是虚拟方法等。)
• 垃圾收集器有时需要在用户代码中插入检查点。延迟编译可以让GC对如何完成这项工作有更多的控制和灵活性。

第一个答案:默认情况下,新项目应使用C_。有一些情况,它还没有赶上到C++(在多支持),但它正朝着这个方向前进。

第二个答案:“可移植性”还包括x86/x64可移植性,这可以通过将平台设置为anycpu来实现。另一个(在这一点上更为理论化)优势是,JIT编译器可以利用CPU特定的指令集,从而更有效地优化。