我正在完成暑期工作，为我们的行李扫描仪编写图形软件。一切都在.NET或MFC中完成，使用普通的C ++进行硬件通信（我不做任何硬件工作）。我有时使用Win32 API调用（如SendMessage）来提高表单或控件的性能。我只有一年的CS课程（全部用C语言），但我对Win32 API很着迷 - 它比我想象的要大得多，也更强大。
.NET是否只是隐藏了Win32 API的所有“乏味”或底层工作？最终软件在.NET中消耗更多系统资源还是执行速度更慢？
答案 0 :(得分：7)
.NET是否只是隐藏了Win32 API的所有“乏味”或底层工作？最终软件在.NET中消耗更多系统资源还是执行速度更慢？
是的，尝试隐藏所有繁琐的细节。是的，.NET应用程序 通常会比使用C和Win32编写的类似应用程序更慢并且可能消耗更多资源。
但是，牺牲性能通常是可以忽略不计的代价来支付生产力的提高和易维护性。
我理解使用简单的C和纯win32编程如此接近裸机的l33t-ness因素可能看起来很诱人，但我发现很难证明使用.NET会更容易和更快
答案 1 :(得分：7)
.Net通常会让发展变得更好。它通过提供一个系统来实现这一点，该系统使得开发人员可以减少公共活动的开发。
我喜欢在.NET工作。在它可用之前，我主要使用MFC和Win32编写的用C ++编写的GUI。当我切换到.NET时，我不得不完全修改我的估算，因为我可以更快地完成工作！
回答您的实际问题：有一些不太常见的开发方案，.NET没有帮助（有些人可能会说它会妨碍）。这些通常涉及低级别使用硬件通信或精细调整的COM编程。
请注意，您可以使用C ++ for .NET进行开发，这样您就可以轻松地在Win32和.NET之间进行交叉。 （当你开发到CLR时，它不是标准的C ++，但也不难发现差异。）
如果没有可以实际测试的实际场景，请不要考虑性能。要在同一任务上对.NET和C ++进行有趣的性能比较，请在此处查看博客条目（和链接！）：http://blogs.msdn.com/b/ricom/archive/2005/05/10/416151.aspx
答案 2 :(得分：5)
.NET的吸引力在于它是一个更高效的开发平台。 .NET框架的许多部分都提供了Win32 API的部分包装器。虽然该框架确实抽象了很多“乏味”的Win32 API调用，但这并不能阻止我不时地需要一点PInvoke。
你会发现.NET框架确实涉及一点开销，并不像C或C ++那样严格有效;然而，通常需要在生产力和效率之间进行权衡。个别申请的要求将决定哪个更重要。在许多软件中，要求是“足够有效”，并且可能完全适合.NET开发。
答案 3 :(得分：4)
对你的问题的简单回答，按顺序是“不”，“是”和“不一定”。也就是说，.NET不仅仅“隐藏”Win32 API，它在某些情况下包装它，在其他情况下扩展它，在其他情况下完全忽略它。
使用.NET框架开发的软件通常会消耗比专家可以（理论上）生成的精简和平均手工编码程序集更多的资源，但在许多情况下，C或C ++开发人员将使用框架和.NET框架一样重的工具包，区别在于它。另一件需要考虑的事情是，如果程序现在消耗额外的kb内存通常无关紧要。没有人注意到。如果在.NET（或任何其他技术）中开发的好处超过风险，那么它是一个更好的选择。只有你能根据自己的具体情况判断一下。
至于“性能”，这是一个非常大的类别，但由于.NET代码被编译为机器语言（它没有被解释），通常没有什么区别。同样，硬编码汇编程序员可能会击败它，但应用您的成本效益分析来确定它是否值得。
答案 4 :(得分：3)
你提到的所有内容都是在Win32之上“分层”，是的。 Win32是您可以通过编程方式使用Windows的最低级别之一。在我看来，学习Win32非常有用。
几乎所有东西都基于它。 （那和COM。）这就像学习寄存器如何在CPU上工作，而不是它是一个黑盒子。
我认识的所有非常优秀的（专业）Windows程序员，了解并熟悉它。
Charles Petzold的Programming Windows几乎是Win32和IMO的圣经，写得很好并且已经执行。
不过，我认为任何一个在他们心中都是“工程师”的人总是需要知道事情是如何运作的。我认为这是一件好事。答案 5 :(得分：3)
.NET 意图隐藏Win32 API的繁琐细节。它在某些方面取得了成功，但在其他方面却失败了。如果你写的大部分内容都与MS试图支持的内容非常吻合，那么它可以很好地成功。如果你离开“处女地”，你可以完全失去优势，甚至比直接使用Win32的本机代码造成大量的额外工作。
生成的软件（基本上总是）比本机代码消耗更多资源。唯一真正的问题是它使用更多内存，运行速度慢多少等。
遗憾的是，这些很难回答。速度可以是从基本相同到8x左右的任何地方。内存使用率一直相当高（例如，至少2倍，通常是3-5倍。一个有趣的点是垃圾收集在速度和内存消耗之间进行权衡（运行GC更经常减少内存使用，代价是使用更多的CPU时间。因此，执行时间将取决于CPU速度的内存可用性。
有趣的是，我个人使用.NET做的第一件事就是移植一个我知道的内存泄漏的C ++程序（我甚至知道它是什么以及大致如何修复它，但是实际上这样做会有很多工作）。移植到.NET并不需要很长时间（这不是很多代码）。好消息是内存泄漏消失了。坏消息是，尽管我可以想象，泄漏的C ++代码必须连续运行一年以上才能使用与启动所需的.NET版本一样多的内存。
答案 6 :(得分：2)
.NET让您在学习时更快地开始学习，特别是在使用可视化界面构建表单时。这一段时间非常吸引人，但根据我的经验，你最终会找到一些限制。
缺点：
1 - 要求客户端计算机上存在相应的.NET框架版本，但并不总能保证。
2 - 3D图形应用程序出现问题，停止支持.net directX。 （我觉得SlimX引擎可以解决这个问题，但你仍然有点卡住了。）
3 - 您的3D应用程序可能无法在没有返工的情况下在较新版本的Windows上运行，或者可能没有解决方法，请参阅＃2。 （我发现这很难）
我一直在研究Win32已有一段时间了，虽然它起步起来比较困难，但确实感觉更强大，更精简。
缺点：
1 - 您必须在项目中处理头文件，这需要一些时间让初学者理解。有一种非常具体的方法可以使用这些，因为编译器是一次通过＆＃39;事情的顺序很重要。
2-win32 API更具有重要性，一切都在一个或多或少的常用命名空间中，大的列表很难探索。
3 - 会员没有提示/说明＆＃39;自动完成显示，所以你必须花费数周时间来倾注所有不同的成员＆＃39;文档。
4 - 没有自动＆＃39;回调＆＃39;就像在.NET中一样（即On_button_click），你必须通过＆＃39;消息来处理Windows元素。由＆＃39; wndproc＆＃39;处理功能。这需要一些时间来解决问题，特别是如果你来自.NET。而且，您还需要通过大量文档来确定所需的消息名称和参数。 这种范式本身不是问题，但它使您很难将实际应用程序与Windows gui设计分开。
5 - 再次，因为Windows元素通过＆＃39;消息进行通信。与实际的会员功能一样，您不会获得明智或描述性的自动填充选项。 请参阅此伪代码：
button.text =＆＃34; ABC＆＃34 ;; //在这种情况下，您了解可能的选项
VS
SendMessage（button_hwnd，BN_SETTEXT，＆＃34; abc＆＃34;，0）; //需要查看MSDN / StackOverflow
6-没有自动取消分配对象内存。但我认为这不是太糟糕。 c ++类有一个~name（）析构函数，你可以在销毁实例时解除分配。 我还尝试将动态数组用于在运行时实例化的成员，这有助于实际有序并负责实际的分配过程。 伪代码：
类游戏{
std :: vector（ghost）ghosts;
}
更新{
ghosts.pushback（）; //添加一个等等
ghosts.erase（位置）; //任何元素都可以被杀死。这很不错
}
~game（）{//
〜鬼（）; //释放数组
}
所以我到目前为止所看到的只是你需要更加注意和结构化以防止内存泄漏，否则我不会让手动解除分配成为一个问题。
关于portabilty，我认为如果应用程序封装得很好，它不应该太难以移植到其他平台。依靠.NET框架是不值得的，具有讽刺意味的是它本身就失去了可移植性。 但是每个人的里程都不尽相同。
但是无论利弊如何，到目前为止我对Win32感到满意，我已经投入了大约2个月的学习时间，并且我已经为Windows控件构建了自己的包装器，所以它已经“＃”;更容易编程并以编程方式与Windows窗体交互。
我还在窗体上运行了irllicht 3D引擎，它似乎在几台具有不同版本Windows的机器上运行完美。很高兴看到可执行文件在没有依赖项或安装的任何（Windows）计算机上运行。
程序加载速度更快，尺寸更小。不过在性能方面，我认为这些天AFAIK没有什么大的优势。
我相信微软应该只为API编写一些简单的包装器，以及一些不错的示例和模板项目，而不是使用整个庞大的.NET路由。
只需我0.02美元
编辑：据我所知，MFC包含了一些功能，但我读过它会增加一些开销，但它并没有真正流行起来。希望有人能加上这个，因为我还没有真正玩过它。 哦，这里[Is it worth to learn Microsoft Foundation Classes(MFC) Nowadays?
答案 7 :(得分：0)
我的答案基于一件事：C ++是iso标准。 C＃是一种专有的Microsoft语言。
如果你想通过Windows扩展你的技能，那么iso C＆amp; C ++会更进一步。
.NET有一个庞大的框架 - 但是如果你知道在哪里可以看到有一大堆lgpl和（如果你兼容的话）为C＆amp; C编写的gpl开源软件。 C ++。 boost正在成为一个庞大的库，拥有.NET提供的大部分（非GUI）功能，但是采用跨平台标准。
也就是说，如果你不介意出售自己的灵魂并将自己的职业生涯投入到单一公司的持续成功中...... C＃/ .NET有两个巨大的奖金，Win32 API不提供：