.NET给了我什么,Win32没有？

.NET的用法会给我什么,我没有使用Win32 - 有时可能使用Google搜索可以重用的50-100行代码？

我正在开发Win32,因为它存在(> 15年).它直接且非常强大,虽然有时它需要比你期望的更多的呼叫,当然你需要跟踪手柄等.但是我们的(250.000 LOC)应用程序安装在不到1分钟内很少见有任何兼容性问题.

关于.NET与Win32(即Win32 vs .Net)的关于SO的几个讨论已经进行了 .但是他们没有回答这个问题.

1> Thomas Maier..：

---

答案很简单:更高层次的抽象和与幕后"真实"事物脱钩.这就是.NET可以在其他操作系统上实现的原因.

事实上,如果没有.NET,这一切都是可能的,但这是不切实际的.简短示例:.NET中的WCF为您提供了每个人都可以使用的第一类IPC和SOA框架.它内置功能.在win32中,您可以使用第三方库或其他任何方式获得相同的自编码.用户群很小,你没有那个大的社区支持你的问题,而且很难实现..NET Framework为您提供了开箱即用的功能.

对于大量应用程序,.NET将加快开发时间并使开发更便宜.

对于特殊类型的应用,情况恰恰相反.EG(几乎)不可能用.NET开发实时应用程序,因为级别2上的GC会冻结所有线程.

补充:
.NET framework 4.5包含一个增强的垃圾收集器.它为服务器垃圾收集器启用多线程后台垃圾回收(使用app.config中的元素启用),该收集不会冻结应用程序线程.

不幸的是Mono垃圾收集器并不是那么先进,所以Mono的基本声明仍然是正确的.

---

"这就是为什么.NET可以在其他操作系统上实现的原因." - >你怎么拼"单声道"？

---

好的:IS在其他操作系统上实现,如linux(mono)

---

Win32也在其他操作系统上实现:请参阅Wine(www.winehq.org)

---

wine ...这是非模拟器,其测试套件仅在2台计算机上运行100%成功,没人知道原因,不是吗？

2> MarkJ..：

---

恕我直言,只有那些已经开发Win32超过15年的人可以称之为简单而强大.如果您愿意自己编写全部250,000行而不是使用组件,那么您的应用程序将很容易安装.我不确定这种权衡是否值得.

.NET给你的是更快的开发,出于各种各样的原因.更高的抽象,更好的组件,没有指针问题,更少需要管理自己的内存或句柄.如果你已经开发了Win32 15年,也许你不需要任何这些.你有没有聘请新的初级程序员？我确信他们比Win32更快地学习.NET.在你甚至可以说"Hello world"之前,你需要在Win32中学到很多东西.

---

相信我 - 这些250.000 LOC中很少涉及Windows API.大约1000行,可能是10% - 但不是更多.

---

"无需管理自己的记忆或处理".不正确,你仍然需要管理资源(套接字,数据库连接等需要及时处理),你仍然可以得到内存泄漏:http://www.codeproject.com/KB/showcase/IfOnlyWedUsedANTSProfiler.aspx

---

@MarkJ:也许没有你想象的那么多.许多LINQ技巧可以用C++中的STL完成,在某些情况下甚至可以提供更大的灵活性.至于指针,几乎经常可以避免它们.引用,智能指针和STL容器意味着您通常不需要*指针.但它仍然是一个有效的观点..NET的一大好处与Win32没什么关系.它是您可以访问应用程序的*rest*的语言和*general*库类.

---

我不认为C#比C++更难.想想函数指针,指针指针以及其他不容易理解的C++语言特性.

3> Adrian Grigo..：

---

在使用ASP.NET/ASP.NET MVC切换到Web开发之前,我已经用C++开发了大约8年的游戏.从我的角度来看,这些是使用.NET而不是本机C++代码时最重要的优势:

非常好的IDE工具.Resharper可以比VisualAssist做得更多

没有更多的无效/空指针错误或泄漏的内存问题

具有比Win32更好的API的可靠运行时

很多优秀的开源.NET库,比我能找到的C++更多(尽管没有C#Boost)

感谢Mono,将软件移植到另一个平台比使用C++更容易

---

在C#或Java等托管语言中,内存泄漏已成为过去,这是错误的信念.实际上很容易在这些语言中创建内存泄漏.垃圾收集器不会消除检查应用程序中的内存泄漏的需要.它只是删除了某些类型的内存泄漏.这些语言中的内存泄漏仍然经常通过静态对象持有引用,不必要的引用,缓存,...

---

@ nkr1pt,无论如何容易在.Net中存在内存泄漏,它在C++中仍然容易达到数量级,而且你也很难跟踪非托管泄漏.

---

程序不仅管理内存.还有其他非托管资源.你是否真的可以使用并实现IDisposable模式正确吗？你知道幕后发生了什么吗？你真的知道GC.SuppressFinalize()方法做了什么以及如何使用它？如果你不使用它,你知道发生了什么吗？事实上,非托管资源在.NET中更难,因为C++程序员使用与内存相同的模式.非托管资源消耗了托管内存带来的诸多好处.你必须要关心两者.

---

通过避免需要明确的所有权,GC可以实现更清晰的API设计.非托管资源是不是一个大问题 - 因为你几乎从来没有需要他们(当你这样做,有被发现某处托管包装的预包装,几乎总是).它并没有解决所有问题,但由于"其他非托管资源"而声称它无关紧要是荒谬的.

---

首先,Win32是用C语言编写的,而不是用C++编写的,尽管它可以很容易地从C++中调用.它上面有几个质量包装器,其中一个是.NET.其次,您可以在C#中获取空引用错误,并且可以获得内存和资源泄漏.第三,C++可用的C++库比C#更多:想一想,这是一种30岁的语言,而不是8岁的语言.最后但并非最不重要的是,你没有在Mono和.NET上运行SAME代码库,因为1.它们正在发散2.单声道仍然受到专利不确定性和平台不成熟的阻碍.

---

我经常使用share_ptr,它强调*不是*替代品.首先,它需要您控制*all*引用.如果外部组件(首先使C/C++具有吸引力的100个中的一个)维护指针,则需要手动计数.其次,它不能处理循环!没有固有层次结构的数据结构(例如图表)需要维护更多工作.boost的各种指针包装器很棒 - 但它们离真正的垃圾收集器只有几英里远.

4> jalf..：

---

便于使用.并且与.NET框架的其余部分(非Win32相关部分)易于互操作.

.NET没有什么神奇的东西,它只是一大堆用于轻松完成常见任务的预定义类.其中许多任务都是"创建窗口"或其他Win32功能.

至于Win32"简单而强大",我不这么认为.

这是一个很好的例子:程序员将需要的最基本的功能之一:检索与刚刚发生的错误相关的错误消息:

http://msdn.microsoft.com/en-us/library/ms679351%28VS.85%29.aspx

7个参数

读取两个表以了解参数

安全评论要考虑在内

必须调用特殊的特定函数(LocalFree)以释放系统分配的缓冲区.

只是为了实现这个简单的功能？这是"直截了当"吗？

Win32 API是最糟糕的设计,最复杂和最难以使用(正确,至少)的API之一.它始终如一地做到的唯一事情是使简单,直观的使用错误,并需要大量的步法来实现正确性.

但是,当然,任何花了十年时间使用API​​的人都已经遇到过这些问题并且已经习惯了.对你来说可能没问题.甚至更好,因为你已经拥有了你的应用程序,你也可以坚持下去.没有理由把它扔掉并在.NET中重新开始

但是,如果你今天从头开始一个项目,那么

学习曲线在.NET中会更友好(但同样,如果你已经超过了学习曲线,那就不那么重要了)

在.NET中会减少错误的范围(以"错误"方式调用函数要困难得多,即使你这样做,也会发生更少的坏事)

找到新的程序员加入你的团队会更容易

对于像C#这样的语言,大多数人的工作效率要高于C或C++..NET提供的主要功能之一是能够使用.NET语言.与此相比,班级图书馆可以被认为是锦上添花.

5> Doug McClean..：

---

两个字总结:

垃圾收集.