C++无框架GUI

8
据我所了解,如果要设计一个C++ GUI界面并将其作为一个独立的可执行文件发布,目前似乎没有这样的方式。所有的第三方框架都会以.dll等形式添加它们的依赖项,无论是MFC、Qt、WTL、wxWidgets还是GTK。这就只能让我自己使用Win32 API来设计当前应用程序的GUI界面。我的假设是否正确,或者我错过了什么?我一直想知道uTorrent和其他一些应用是如何实现的。谢谢。

1
如果你的目标明确是开发一个轻量级可执行文件,最好还是坚持使用Win32 API。在我看来,这并不是一个糟糕的选择。 - valdo
3个回答

7
不,大多数流行的GUI框架,包括MFC、Qt、ATL/WTL和wxWidgets都可以进行静态链接。我不知道GTK是否可以静态链接,但我认为你也可以这样做。
静态链接意味着你将库代码直接链接到可执行文件中,而不是动态链接到DLL中的库代码,从而产生一个单独的可执行文件,无需任何外部依赖项即可运行。
但是,当然,这些依赖仍将存在并且会使你的可执行文件变得臃肿,这可能是一个问题,取决于你的部署机制。此外,编程接近于底层也有其优点,因此直接使用Win32 API绝对是一种选择。这将产生最小、最轻量级的应用程序,并且可能是最快的。事实上,我相信这正是μTorrent所做的(或者至少是他们几个版本之前所做的)。

谢谢,我对静态链接有些了解,但不幸的是,在我的情况下这不是一个选项,因为我的当前项目需要应用程序尽可能轻量级和快速。我想我会坚持使用Win32API。只是想确保没有更简单的替代方案。 - astralmaster
2
@astralmaster,我不知道你在评论中的意思。你想使用一个框架,但感觉它太重了!静态链接不会使应用程序变慢。使用框架也不会使应用程序变慢。大型可执行文件也不会使应用程序变慢。你可以使用GUI框架而不必拥有巨大的可执行文件。 - David Heffernan
1
为什么要有这个大小的要求?你需要在普通硬盘上存储500万次可执行文件吗?想象一下,如果你使用一个合适的框架并只需要稍微多一点硬盘空间,你可以节省多少时间来实现更多功能... - PlasmaHH
2
@David Heffernan 因为我正在开发的应用程序,是要在一台只有256 KB内存的设备上运行的。 :) - astralmaster
1
256 KB的内存甚至无法运行Windows,因此针对Windows API是相当无意义的。也许你的意思是256 MB - Cody Gray
显示剩余2条评论

1
一些框架允许您构建一个自给自足的“独立单体”EXE,没有任何额外的依赖(除了操作系统提供的明显API)。 例如,在MFC中,您可以选择使用“静态”或“动态”MFC。第一种选项意味着所有所需的内容都将链接到您的EXE中。

谢谢回复。我相信你同意MFC很难处理。那么没有其他选择吗? - astralmaster

0
根据您的应用程序的最低操作系统要求,您可以动态链接到包含在目标 Windows 版本中的 MFC 或 ATL(在 WTL 应用程序的情况下)版本。
这种解决方案的另一个优点是,每当使用的库发布安全更新时,您无需更新应用程序即可从中受益。
但是,为纯 Windows API 编写代码并不那么可怕,因此我建议您采用它。
其中一个问题是,使用较新版本的 Visual Studio 编译的应用程序需要最新的 CRT 运行时库,您必须在安装程序中提供或让用户自行安装。有办法克服这个问题。我认为 该博客文章 是我一段时间前偶然发现的。当然,如果您动态链接到旧的 CRT 库,则最好针对其头文件编写代码。也许有一种方法可以完全摆脱 CRT 依赖性。
编辑
在与 Cody Gray 的激烈讨论之后,我决定详细阐述一下我的观点并发出一些警告。

即将发表抱怨

即使是桌面软件,你在发布后也必须为用户提供维护服务。操作系统版本会改变,它们的API和已安装库也会改变。苹果并不介意在新的OS X和iOS版本中“破坏”应用程序,开发人员明白他们必须保持产品更新或者他们将失去客户或者忙于支持电话。微软等“大企业世界”的公司创造了一类将软件视为建筑物的程序员。你设计它、构建它,有人批准了,然后你就完成了,也许还要支持两年。但这不是应该的。

即使一个人尽可能编写了未来可靠的应用程序,即依赖于目标操作系统和任何可能出现的操作系统的完全定义、通用和文档化行为,并且甚至静态链接所有使用的库,使其自包含、正确和oldnewthing-approved,他们仍然必须积极地维护它多年。它所依赖的库会发生变化。它们会升级、改进、修复漏洞、修复OS相关的行为。

即使应用程序只依赖于最小的系统库集合,上述所有内容也同样适用。

所以,无论您的应用程序是否被设计为仅限于一定时间使用,您都必须假设并计划您将不得不维护它,如果与您的应用程序相关的任何内容发生变化。即使它是一个纯Win32 API应用程序,您也必须检查它在较新版本的Windows中的行为方式,以及它是否提供用户期望从他们的应用程序中获得的UI元素或服务。

话虽如此,如果您不走纯Win32 API路线,请注意您所做出的权衡,如果使用我最初提到的任何黑客技巧时。

即使您的项目最终只是一个一次性应用程序。即使只是为了未来保护自己。


Windows 没有分发 MFC 或 ATL 的版本,因此这不是一个选项。而且那篇博客文章所造成的问题远远超过它解决的“问题”... - Cody Gray
你找不到可靠的来源有很好的理由;你的信息是错误的。是的,Windows 附带了一些 内部 库供自己使用,但关键词是 内部:这些库不适用于应用程序使用。你不应该依赖它们的存在。你仍然必须随应用程序一起提供所需的库。[Windows 不是 MFC 的交付渠道。] (http://blogs.msdn.com/b/oldnewthing/archive/2008/01/11/7065021.aspx) - Cody Gray
我完全支持Raymond Chen的说法,绝不会依赖于一些不可靠的Kodak Image Viewer组件,但是我不介意依赖于MFC 4.2,或者至少ATL 3.5。我知道这可能部分地创造了Raymond专门致力于解决的问题 - 强制微软使Windows向后兼容20年。但是嘿,我刚刚检查了一下 - Windows 8 Consumer Preview也附带了这些DLL文件。如果你像我看到的那样关心你的应用程序,如果有任何变化,你肯定会更新它。 但是我的回答的主要观点仍然是 - 选择Pure。;) - macbirdie
我已经是 Raymond 的博客的粉丝有10年了。可能比你编程的时间还要长。我只是不再像以前那样虔诚了。如果我使用之前讨论过的假设编写一个应用程序,而它被微软“破坏”了,我会更新它,因为这完全是我的责任。谢谢少一点傲慢。 - macbirdie
是的,每个人都认为如果他们这样做就可以了,但其他人不行。这正是问题所在。没必要争论,我显然无法改变你的想法。我只是建议你不要向那些可能不了解其中缺点的人提供这种建议。 - Cody Gray
显示剩余5条评论

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接