如何用 C++ 编写现代 Windows 软件？
我对当今现代 Windows 软件是如何用 C++ 编写的非常感兴趣。我问我曾经开发过 Windows 软件的朋友，他告诉我他最后使用的是 MFC，然后是 WTL。他说MFC已经不再现代了，但WTL仍在使用，但他不知道更多。他还说 WTL 并不是那么现代，在此之前他是使用纯 Windows API 进行编程的。
如何为 Windows Vista 或 Windows 7 编写软件？你还在用WTL吗？ MFC 和纯 Windows API 怎么样？或者现在还有其他库吗？
我对此了解不多，但是 C# 或其他 .NET 语言在编写现代 Windows 软件方面是否已经取代了 C++？
I am very interested in how modern Windows software is written in C++ nowadays. I asked my friend who had worked on Windows software and he told that last things he worked with were MFC and then WTL. He said that MFC is no longer anything modern but WTL is still used but he didn't know much more. He also said that WTL wasn't that modern and before that he programmed in pure Windows API.
How does one write software for Windows Vista or Windows 7? Do you still use WTL? What about MFC and pure Windows API? Or are there other libraries now?
I don't know much about it, but have C# or other .NET languages replaced C++ in writing modern Windows software?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
从我过去几年的观察来看：
WTL 处于生命线上。被微软抛弃，被粉丝捡起，并且有几个非常忠实的追随者。非常干净，但学习曲线陡峭且粉丝群不断减少。雅虎集团不是很活跃。我不能推荐它。
当 MSFT 发布功能包时，MFC 又获得了新生。它相当广泛并且有点不像 MFC，但它对皮肤、对接布局和功能区有强大的支持。我原以为它会广受欢迎，但从未看到很多开发人员加入其中。 MSDN 论坛的问题很少。如果您有现有的 MFC 代码库，那么一定要看看。 VS2010 的另一次 MFC 更新，添加了 Win7 功能，它确实保留了公司的基本 UI 解决方案。
wxWidgets 仍然存在。没有个人经历，但是主啊，我听过的少数练习者正在大肆抱怨。也确实是苦涩的东西。
Qt 已经存在很长一段时间了，但发展速度相当快，特别是在去年。使用它的人都真正喜欢它。它也超越了 UI 类库的限制，他们的用户正在积极寻找以字母 Q 开头的常见编程任务的解决方案。这是一个强有力的信任票。
但如果您使用的是 Microsoft 堆栈，那么这些类库都不是真正的 UI 开发所在。 WPF 是房间里的大象，它的功能比上面列出的要多一百英里。它打破设备和范例边界的能力非常强大，编写在桌面、网络浏览器以及手机上运行的代码是很难被击败的。但 C++ 不属于其中。
From what I've seen over the past several years:
WTL is on a lifeline. Abandoned by Microsoft, picked up by fans and there were several very dedicated followers. Very clean, but the learning curve is steep and the fan base dwindling. The Yahoo group is not very active. I can't recommend it.
MFC got another lease on life when MSFT released the feature pack. Rather extensive and a bit un-MFC-ish, it has strong support for skinning, docking layouts and ribbons. I thought it was going to be wildly popular but never did see a lot of devs jumping on it. MSDN forum questions have been sparse. If you have an existing MFC codebase then definitely take a look. Another MFC refresh for VS2010 with Win7 features added, it does stay the company's base UI solution.
wxWidgets is still around. No personal experience, but Lord, the few practitioners I've heard from are bitching up a storm. Real bitter stuff too.
Qt has been around for quite a while but picked up stream considerably, especially in the last year. Whomever uses it really likes it. It is moving beyond the confines of a UI class library as well, their users are looking actively for solutions to common programming tasks that start with the letter Q. That's a powerful vote of confidence.
But if you are on a Microsoft stack, none of these class libraries is where the real UI development is at. WPF is the elephant in the room, it's capabilities are a hundred miles beyond what's listed above. Its ability to break device and paradigm boundaries are powerful, writing code that runs on a desktop as well as a web browser as well as a phone is hard to beat. But C++ is not part of that.
WTL， Qt、 wxWidgets 使用非常普遍。
用纯 WinAPI 编写窗口是非常老派的，但有时可能很有趣。
C#构建窗口的方法更加快速，但灵活性稍差。WTL, Qt, wxWidgets are used pretty common.
They all allow rapid GUI development and are pretty versatile (third option, to my mind, takes more time to get used to). Second and third options are really cool because they're cross-platform.
Writing windows in pure WinAPI is extremely oldschool but sometimes could be entertaining.
C#approach to building windows is even more rapid compared to previous options, but is a bit less flexible.看看Qt——你可能会喜欢它。当然，除非您更喜欢非便携式版本。但即使您不打算在 OS X、Linux、手机等上进行构建，Qt 框架也写得很好、有很好的文档记录并且可以正常工作。 SDK 现在还包括一个不错的 IDE (Qt Creator)。
Have a look at Qt -- you may like it. Unless of course you prefer a something non-portable version. But even if you don't plan to build on OS X, Linux, phones, ... the Qt framework is well written, well documented and just works. The SDK now includes a nice IDE (Qt Creator) too.
如果您的主要平台是 Windows，则每次都会使用 WTL。 Google Chrome 使用它，Spotify 使用它。它是最高效、最灵活的，并且不占用资源。我所说的灵活是指您可以将它与纯 Win32 API 代码/其他 C++ 代码一起使用，而不会有太大困难。
更多 WTL 信息：WTL 链接集合
WTL everytime if your main platform is Windows. Google Chrome uses it, Spotify use it. Its the most productive, flexible, isn't a resource hog. By flexible I mean you can use it with pure Win32 API code / other C++ code without too much difficulty.
For more WTL information: collection of WTL links
经过评估后，我发现纯 Win32 或 WTL 是编写不基于 WRT 的现代风格 win 应用程序的唯一方法。
新的外观是重点。 MFC 在 Win8 和 Win10 上看起来很糟糕，尤其是在所有这些令人眼花缭乱的功能包的情况下。纯 MFC 很好，但是很胖，视图模型部分简直太糟糕了，我只是更喜欢 WTL。但这是没有记录的，这太糟糕和可怕了。
WxWidgets 是一个丑陋的玩具。
QT 也不再是一种选择。他们过于关注移动和应用程序框架。如果你使用 MacOSX，你根本无法使用 QT（是的，它会运行，但它会让你吐槽用户体验）。
WinRT 的限制如此之多且缺乏功能，以至于您无法使用它。您可以确定它会失败，因为没有人在平板电脑/手机上使用 WinStore 或 Windows。那么为什么还要麻烦呢。
如果您认为您的用户喜欢又慢又胖的应用程序，那么 WPF 就可以。它看起来更好，但所有的花哨的东西现在不再是 UI 设计指南的一部分，并且小部件的功能集少于 Win32 本机小部件。难以置信但却真实。我限制你使用不可移植的 C#，在我看来，这是不推荐的，因为现在性能再次重要（因为性能就是能量，就是生命周期）。
甚至 Herb Sutter 和其他 MS 高级员工也告诉您 C++ 是未来。下一个杀手级应用程序是基于 C++14 构建的，微软也知道这一点。
更新[2023]：
我坚持我之前写过的话。而微软终于同意了，于是他们开发了WinUI3，并将其添加到Windows App SDK中。 WinUI3是基于WinUI但没有WinRT的沙箱限制的C++小部件集。他们刚刚将 Windows 文件资源管理器移植为现实世界中第一个大型应用程序。
虽然对于程序员来说使用起来仍然很糟糕（糟糕的工具，尤其是没有可视化 GUI 设计器）并且缺少很多功能。当树选择发生变化时，甚至无法获取事件，他们明确表示这是在 Windows 上进行的唯一方法......迟早会发生。
原生开发的悲惨状态仍在继续。
After evaluating i came to the situation where pure Win32 or WTL is the only way to write modern style win apps which are not WRT based.
The new look is the main point. MFC looks terrible on Win8 and Win10 especially with all this Feature Pack eye candy. Pure MFC is good but fat and the view-model part is just outrages terrible and i just like WTL more. But it's undocumented and this is so bad and scary.
WxWidgets is an ugly toy.
QT is not an alternative anymore too. They focus too much on mobile and appframework. And if you go MacOSX you can't use QT at all (yes it will run but it will make you vomit about the UX).
WinRT is so restrictive and lacking features that you can't use it. And you can be sure that it will fail because nobody is using the WinStore or Windows on Tablets/Phones. So why bother.
WPF is ok if you think you user appreciates slow and fat apps. It looks nicer but all the eye candy is now not part of the UI design guidelines anymore and the feature set of the widgets is less then Win32 native widgets. Unbelievable but true. And i locks you into using unportable C# which is deprecated in my opinion because now performance matters again (because performance is energy, is life time).
Even Herb Sutter and other high ranking MS employees tell you that C++ is the future. And the next killer app is build on C++14 and Microsoft knows it.
UPDATE[2023]:
I stand to the words i have written before. And Microsoft has finally agreed, so they developed WinUI3 and added it to the Windows App SDK. WinUI3 is a C++ widget set based on WinUI but without the sandbox restrictions of WinRT. They just ported the Windows File Explorer as first real world large scale application.
And while still terrible to use for programmers (terrible tooling, especially no Visual GUI Designer) and lots of missing features. Can't even get an event when the tree selection changes, they made clear that this is the only way to go on windows ... sooner or later.
The sad state of native developing still continues.
在 .NET（C#、VB.NET...）中，GUI 编程的前沿是 WPF< /a> 目前（取代 WinForms）。 .NET 中的编译代码实际上是 CIL，它在运行时由 JIT 编译为本机代码。这样做的优点是您不必关心 64 位或 32 位目标系统。
在 C++ 中，Qt 似乎是一个很好的解决方案，因为它设计简洁并提供了大量服务。我不喜欢 Qt 的是它的编译往返，它太慢了，有一个 moc 编译器，编译器，然后链接，与 C#/.NET 相比，它需要很长时间才能获得可执行文件。另一方面，即使在嵌入式系统中您也可能会遇到它，这使得在这种情况下变得有趣。
我建议您在做出决定之前至少看一下 C#/.NET 并进行试验。
In .NET (C#, VB.NET, ...), the cutting edge of GUI programming is WPF at the moment (replacing WinForms). Compiled code in .NET is actually CIL which is compiled into native code at runtime by the JIT. This has the advantage that you do not have to care about 64 or 32 bit target systems.
In C++, Qt seems a good solution as it is cleanly designed and provides a big bunch of services. What I dislike in Qt is its compile round trip, it is so slow, there is a moc compiler, the compiler, then link, it takes ages compared to C#/.NET to get the executable. On the other side you may encounter it even in embedded systems, what makes it interesting in such cases.
I would advice you to have at least a look C#/.NET and experiment with it before deciding.