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

【问题标题】：2 basic but interesting questions about .NET关于 .NET 的 2 个基本但有趣的问题
【发布时间】：2011-03-01 14:39:27
【问题描述】：

当我第一次看到 C# 时，我认为这一定是个笑话。我开始使用 C 编程。但在 C# 中，您可以拖放对象，然后向它们编写事件代码。就是这么简单。

现在，我还是最喜欢C，因为我非常喜欢基本的低级操作，而C只是汇编程序的下一级，基本例程很少，所以我很喜欢。更重要的是因为我为微控制器编写了小应用程序。

但昨天我在 asm 中为基于微控制器的 LED 立方体编写了非常简单的控制程序，我需要一些方法来简单地为 Cube 创建动画序列。所以，我想起了 C#。我几乎没有 C# 技能，但我仍然在谷歌的帮助和 C# 中嵌入的函数描述的帮助下创建了简单的程序，在大约一个小时内使用 GUI 制作动画序列。

那么，直截了当地说，除了最高速度之外，还有其他原因使用 C# 以外的任何其他语言吗？我的意思是，它是如此有效。我知道 Java 有点类似，但我希望 C# 更有效，因为它直接来自 Microsoft。

第二个问题是，编译成CIL，比CLR运行，比直接编译成机器码有什么好处？我知道可移植性是其中之一，但由于 C# 主要用于 Windows，直接编译它会不会更强大？谢谢。

【问题讨论】：

拖放与 Visual Studio IDE 的关系比与 C# 语言本身的关系更大。在这种情况下，任何 IDE 都可以帮助您拖放和 GUI 应用程序。事件中的代码仍然需要编写。
.Net 不只是 Windows 台式电脑，它也是手机/PDA，如果我没记错的话，还有一些嵌入式设备。
我曾经有同样的想法，认为 C/C++/Assembly 是唯一的出路，认为其他一切都是缓慢而单一的。事实是，当您尝试为每项工作使用相同的工具时，您会将自己编码到一个角落。有一段时间，我错过了以这种方式思考的个人进步。道德：拓宽视野并尝试新事物总是好的。
借助 .Net Micro 框架，您现在可以使用 c# 对微控制器进行编程。

标签： c# .net windows

【解决方案1】：

我不确定 C# 是否更有效只是因为它是 Microsoft 产品。如果您使用 Visual Studio 或其他 RAD，则某些代码是自动生成的，有时效率较低。几年前我是一个教条主义的人，认为只有 C 可以回应我们所有的祈祷 :-P，但现在我认为虚拟机可以在执行代码之前优化代码（如 RDBMS），存储在缓存中稍后执行的代码等。包括像 Terracotta 那样创建虚拟机“集群”的可能性。至少有一个额外的抽象层的好处是没有它的更大。

【讨论】：

什么是 RDA？快速发展？还是？
@kenny 大声笑...对不起！ RAD（快速应用程序开发）

【解决方案2】：

“还有其他原因吗？速度，使用任何其他语言 C#？”

我能想到至少四个，都有些相关：

我目前对“语言 X”进行了大量投资，但我没有时间或金钱来切换到其他语言。（移植现有的代码库，购买/获取/移植库，用 C# 重新培养团队技能，学习不同的工具。）
预计需要将代码移植到不支持 C# 的平台。
我需要使用 C# 中没有的工具，或者没有得到很好的支持。（IDE、备用编译器、代码生成器、库，不胜枚举……）
我发现了一种更有效率的语言。 ;-)

"编译有什么好处进入 CIL，然后由 CLR 运行，然后直接编译成机器代码？”

这一切都是为了让运行时环境更好地控制代码的执行方式。如果你编译成机器代码，那么很多东西在那个时候就变得“一成不变”了。在您对运行时环境有更多了解之前，将编译推迟到机器代码可以让您以其他方式可能无法做到的方式进行优化。就在我的脑海中浮现了一些：

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

【讨论】：

【解决方案3】：

关于第二个问题：您可以运行 NGEN 来生成程序集的本机映像，这可以提高性能。不完全是机器代码，但由于它绕过了 JIT（即时编译）阶段，应用程序往往会运行得更快。

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

本机图像生成器 (Ngen.exe) 是一种提高托管应用程序的性能。 Ngen.exe 创建本机映像，它是包含编译的文件特定于处理器的机器代码，以及将它们安装到本机映像中缓存在本地计算机上。这运行时可以使用来自缓存而不是使用即时 (JIT) 编译器进行编译原始程序集。

【讨论】：

+1 我不知道这存在。您是否在生产中使用过它？您看到了哪些改进？

【解决方案4】：

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

如果您担心速度，由于您所说的原因，C 是要走的路线。

【讨论】：

【解决方案5】：

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

【讨论】：

【解决方案6】：

语言和平台选择是项目目标的一项功能。听起来您喜欢系统级编程，这是使用 C/C++ 的优势之一。因此，如果您喜欢，请继续编写系统级代码。

在目标本质上不同的快速业务应用程序开发中，使用 C# 编写非常强大。更快地编写好的工作代码在工时和上市时间上都是物有所值的。 Microsoft 为我们提供了一个巨大的帮助，它提供了一种富有表现力的语言和一个可靠的功能框架，使我们不必为 95% 的业务需求编写低级代码或工具。

【讨论】：

【解决方案7】：

1 - 差异语言各有利弊。有一些语言家族（函数式、动态式、静态式等）更适合特定的问题领域。您需要在每个家庭中学习一种才能知道何时选择哪一种。例如要编写一个简单的脚本，我会选择 Ruby 而不是 C#

2 - 将其编译为 CIL：可移植性可能不是什么大问题。但准确地说，Mono 在 Linux 上实现了 CLR。所以在那里。 CIL 还可以帮助您在 CLR 上运行的语言之间进行混合和匹配。例如IronRuby 可以访问用 C# 编写的标准框架库。它还使 CLR 能够利用运行程序的实际硬件（例如，打开优化、使用特定指令）。 2 台机器上的 CLR 会为各自的机器从相同的 IL 生成最好的本机代码。

【讨论】：

【解决方案8】：

第一个答案：默认情况下，新项目应该使用 C#。在少数情况下，它还没有赶上 C++（在多范式支持方面），但它正朝着这个方向前进。

第二个答案：“可移植性”还包括x86/x64的可移植性，可以通过将平台设置为AnyCPU来实现。另一个（此时更理论上的）优势是 JIT 编译器可以利用 CPU 特定的指令集，从而更有效地优化。

【讨论】：

我不同意你的第一句话，你说的太笼统了。不使用 C# 是有原因的，而且它完全依赖于项目。
对，但默认选择应该是 C#。除非有特定项目的理由不这样做。我就是这个意思。
不，如果您制作产品软件或 Web 应用程序，或者目标与 Windows pc 不同，或者需要扩展，则不会...
所有 .NET 语言实际上是等效的，动态语言除外。我在 C# 中有可扩展的解决方案，包括 Web 应用程序、移动设备和 Silverlight。鉴于 op 的先前经验（C 和 C#）和问题（默认为 C# 还是 C），我相信我给出了一个很好的答案。我并不是说 F# 是邪恶的。可能比操作人员现在想咬的还多。