.net做了多少东西不是必需的？

Question

正如标题所述; .Net BCL对于Windows本身而言并非严格要求的典型Windows应用程序做了多少工作（作为一个粗略的百分比数字，如果可能的话）？据推测，Winforms所做的一切都在MFC中具有类似的功能，后者是超高效的实现。显然我们使用.Net的原因在于它的灵活性，并且它为开发人员提供了很多让生活变得轻松的事情 - 毕竟，Winforms是Win32的许多基本功能的包装器。我想知道这是如何增加应用程序开销的，原则上可以减少多少并且仍允许应用程序保持相同的行为。

Answer 1

由于.Net是Windows的附加功能，理论上可以在不改变Windows本身的情况下重新实现它。所以绝对没有必要。我怀疑你问的那个背后有一个不同的问题 - 也要问这个问题吗？ ：）

Answer 2

关于什么是必需的问题是非常哲学的。与纯汇编程序相比，C ++有其自身的开销，与为运行单个应用程序而开发的（假设的）专用处理器相比，C ++实际上不需要这些东西。

从另一个角度来看，您不应低估复杂性，可扩展性和可维护性，这可能因语言/框架选择而异。

另一个问题是框架提供的功能集：在纯MFC / C ++中制作自定义控件是一个比.NET / WPF（imho）更痛苦的操作。

无论如何，选择语言/框架的最终关注点是应用程序所需的成本，时间和质量。所有其他似乎并不重要，至少在商业软件开发方面。

Answer 3

从技术上讲，整个图形用户显示中不需要以最高效率在计算机上执行计算，因此在这方面，Win32和WinForms以及MFC是100％多余的。 ;＆GT;

MFC“超高效”？只是在它什么都不做的意义上。 MFC是Win32的一个瘦包装器，与Win32上的其他应用程序框架相比，它对你来说做的很少。 “超高效”实现是直接使用Win32 API自己完成所有工作。而且，IMO，Win32 API比MFC包装器和宏更容易使用和理解。

对于您的问题，没有一个好的答案，因为您可能会或可能不会使用的功能以及您正在使用的功能需要您担心的开销可能是不必要的，您可能没有意识到需要该基础结构。您正在折扣的一些最有价值的基础架构功能是生产力和易于开发。

如果您将文件大小视为“效率”的标记，则.NET DLL将始终比手工雕刻asm构建的模块大100倍至1000倍，因为.NET DLL包含符号信息以及指令逻辑。是的，这是开销，但是当您希望/需要在运行时搜索DLL中的可用类型或使用某些取决于该服务级别的功能时，它会节省多少人工年？你永远不会用超高效的手工雕刻汇编语言。如何构建一个能够在32位系统和64位系统上运行本机代码速度的DLL？在.NET中很容易做到，在C或汇编程序中非常难。

效率的定义完全取决于你最重视的东西。在.NET中开发比使用手动编码汇编程序更有效地利用我的时间，因为我可以在.NET中以相同的时间在汇编程序中完成更多可用的工作。 Assembler和C在磁盘空间和原始单线程CPU性能方面更高效，但磁盘空间便宜，单线程无法再充分利用CPU。

软件开发的基本规则：“快速，便宜，简单：选择两个。”

Answer 4

.NET的目标之一是提供一个抽象级别，它可以节省大量使用较低级别框架时需要考虑的管道，例如： MFC，解决给定的要求。当然，这需要一些成本。对于给定的问题，通常可以编写汇编代码，其资源成本低于用高级语言/框架编写的应用程序。但请考虑编写汇编代码所涉及的投资。想想一些非常聪明的人确实为你做过的所有工作。一个很好的例子是C＃执行速度与C ++执行速度相比。 JIT编译器在运行时编译IL，是一个非常聪明和复杂的软件。如果你可以通过在C ++中编写低级优化来击败它，那么你可能需要a）非常聪明并且b）有足够的时间在你的手上。采取较低级别的方法通常不会付出代价。