为什么不使用Qt编写更多的桌面应用程序？[关闭]

据我对Qt的了解和了解，它是一个非常好易学习的库。它具有设计良好的API，并且是跨平台的，而这些只是使其具有吸引力的众多功能中的两个。我想知道为什么更多的程序员不使用Qt。是否有不足之处与之相反？哪些功能使其他库比Qt更好？问题与许可有关吗？

我并不是真的希望这是一个猛烈的回答，但这就是我不亲自使用Qt的原因。关于它，有很多好话要说-即API在大多数时间都有效，并且可以无缝地桥接平台。但是我不使用Qt，因为：

1. 在某些情况下，它看起来不像本机程序。由于各种视觉样式的原因，当从一台机器移到另一台机器时，固有地为所有平台设计单个UI看起来并不正确。例如，在Mac机器上，分隔条通常相对较粗，按钮较小，并带有图标圆形。在Windows机器上，分隔条通常较窄，按钮的文字更具文本含义，并且具有更多的方形设计。仅仅因为您可以为每个平台编写一个UI并不意味着您应该为大多数应用程序编写。
2. Qt不是C ++库。与大多数其他库相比，它需要一个单独的编译步骤，这使构建过程变得更加复杂。
3. 由于（2），C ++ IDE和工具可以将Qt表达式标记为错误，因为它们不了解Qt的细节。这几乎迫使使用QtCreator或仅文本编辑器（如）vim。
4. Qt是大量资源，在编译之前，您必须在使用的任何计算机上都存在Qt并预安装Qt。这会使设置构建环境更加繁琐。
5. 它仅在LGPL下可用，这使得在需要以限制性较高或限制性较小的许可证进行释放时，很难使用单二进制部署。
6. 与类似编写的“纯程序本机应用程序”（当然，为KDE编写的应用程序除外）相比，它生成的编译二进制文件非常大。

就像人们所说的那样，每种工具都适合每种问题和情况。

但是，如果您是C ++程序员，那么Qt是您的框架。没有对手。

我们开发了复杂的医学成像商业应用程序，并且Qt坚持了下来。

我并不是说人们所说的“缺点”是错误的，但是我有一种感觉，就是他们很久没有尝试过Qt了（它在每个新版本上都在不断改进...）而且如果您保重，他们评论的所有问题都不是问题。

UI平台不一致：仅当您按原样使用UI小部件时，没有自定义或自定义插图。

Qt预处理器重载：仅当您滥用信号时隙机制或QObject继承时，才真正不需要。

顺便说一下，我们仍然在C＃.NET中编写应用程序，并且已经做了很长时间了。所以我认为我有观点。

就像我说的，每种情况的每种工具

但是Qt无疑是一个一致且有用的框架。

在我不喜欢Qt的所有事情中，它不能很好地与模板配合使用这一事实使我感到最困惑。您不能这样做：

template < typename T >
struct templated_widget : QWidget
{
  Q_OBJECT;

public signals:
  void something_happened(T);
};

它也不能与预处理器配合使用。您不能这样做：

#define CREATE_WIDGET(name,type) \
struct name ## _widget : QWidget \
{ \
  Q_OBJECT; \
\
public signals: \
  void something_happened(type); \
}

加上对信号作出响应的所有内容都必须是Q_OBJECT的事实，使得Qt很难为C ++程序员使用。习惯Java或Python风格编程的人们实际上可能更好。

实际上，我花了大量时间和精力研究和设计一种获取类型安全性并将Qt信号连接到任何仿函数对象的方法：http : //crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals -in-qt-step-1.html

我想做的事情是Qt moc几乎无法进行的基本的日常C ++开发……如今，即使实际上确实如此，这本身也是完全不必要的。

坦率地说，我坚持使用它，因为如果您想进行自动化的UI测试，那么Qt几乎是MFC之外唯一一款市面上的游戏了……到1980年为止（在这种情况下，确实很难工作）。有人可能会说WX，但问题更加严重。GTKmm本来应该是我的首选，但是由于它是所有人所有的，并且不具有可访问性……因此不能由行业标准测试软件来驱动。Qt在这方面已经足够困难了（修改辅助功能插件时几乎无法使用）。

不使用Qt的原因之一是，如果仅针对Windows等一种体系结构进行编写，则可能要使用C＃/。NET（或Mac上的Cocoa），因为它们将始终能够利用最新的优势- -操作系统的口哨声。

如果您正在编写跨平台的应用程序，那么您可能已经在Java之类的另一项技术上投入了很多精力（例如，您在“ Java Shop”中工作）。您对技术的选择可能取决于您所开发的生态系统，例如特定语言的API。在这种情况下，最小化技术数量可能是有益的。

我能想到的第三个原因是Qt基于C ++，并且C ++是一种比较困难/危险的编程语言。我认为它是专业人士使用的语言。如果您需要最高的性能并且能够做到细致，那么C ++可能仍然是市面上最好的游戏。实际上，如果您将内容设置为超出范围，Qt可以缓解许多内存管理问题。同样，Qt本身做得很好，使用户摆脱了许多令人讨厌的C ++问题。每种语言和框架都有其优缺点。这是一个非常非常复杂的问题，通常可以用食客经常看到的加法来概括：速度，质量和价格（但是您只能选择两个）。

尽管规则说我应该继续专注于回答问题，但我确实想反驳Billy ONeal提出的一些问题，我认为总结了不使用Qt的普遍被引用的原因很不错：

1. Qt确实是C ++库/框架/头文件。它被增强宏处理器（moc）可以使信号和时隙生效。它会转换其他宏命令（例如Q_OBJECT），以便类具有自省性，您可能会想到这些其他种类的东西，可以将Objective-C功能添加到C ++中。如果您对C ++的了解足够多，会因缺乏纯正而受到冒犯，即您是专业人士，那么1）不要使用Q_OBJECT及其同类产品；或2）对此会非常感激，并在非常有限的情况下进行编程这会导致问题。对于那些说“对信号和插槽使用Boost的人”！那么我反驳说，您正在将一个“问题”交换为另一个。Boost是巨大的，它有其自己经常被提及的问题，例如不良的文档，可怕的API和跨平台的恐怖（例如gcc 3之类的旧编译器）。

2. 对于编辑器支持，我也同意从1开始。实际上，即使您不使用Qt，Qt Creator还是IMHO最好的图形C ++编辑器。许多专业程序员都使用emacs和vim。另外，我认为Eclipse可以处理其他语法。因此，Qt宏（Q_OBJECT）或信号/插槽添加没有问题。您可能在Visual Studio中找不到这些宏，因为（我承认）它们是C ++的添加。但是总的来说，由于C＃/。NET人们拥有自己专有技术所涵盖的许多功能，因此他们将永远不会使用Qt。

3. 至于Qt源的大小，只要它能在一夜之间编译，谁在乎？我“不到一整天”就在双核Macbook上编译了Qt 4。我当然希望这不是促使您决定使用或不使用特定技术的原因。如果确实存在问题，则可以从Qt网站下载适用于Mac，Linux和Windows的预编译SDK。

4. 可以通过三种选择获得许可：1）如果您希望修改Qt ITSELF而不共享，或者隐藏一个人正在使用Qt而又不愿出处商标的事实，这将是专有许可（这对于品牌和形象非常重要！）2 ）GPL和3）LGPL。是的，静态链接存在问题（将所有Qt都滚动到二进制文件中）-但是我认为这更多是因为人们无法窥视内部并且注意到您正在使用Qt（归因！）。我试图从Digia购买专有许可，他们告诉我“对于您正在做的事情，您真的不需要它。” 哇。来自从事许可证销售业务的公司。

5. 二进制文件/捆绑文件的大小是因为您必须将Qt内容分发给没有它的人：Windows已经拥有？Visual Studio的东西，或者您必须安装运行时。Mac已经附带了巨大的Cocoa，并且可以动态链接。尽管我不做很多分发工作，但分发约50兆字节的静态文件（使用UPX等二进制剥离程序/压缩实用程序可以使它变小）却从未发现太多问题。我只是不太在乎这样做，但是如果带宽成为一个问题，我会在构建脚本中添加一个UPX步骤。

6. 什么定义了“本地外观”？我认为“大多数”会同意Mac最接近统一的外观。但是我坐在这里，看着Safari，iTunes，Aperture，Final Cut Pro，Pages等，尽管它们是由OS供应商制造的，但它们看起来却完全不同。我认为“感觉”方面更相关：小部件样式，响应能力等。如果您关心响应能力，那么使用C ++而不是Java或其他高度动态语言是一个很好的理由。（目标C也会动摇，但我试图消除有关Qt的神话）

总之，这是一个复杂的问题。但是我想指出的是，我认为没有理由不使用Qt，这是基于神话和十年来过期的信息而可能想到的。

其中一些是许可。有关某些许可历史记录，请参阅https://en.wikipedia.org/wiki/Qt_(software)#Licensing。直到2000年，对开源非常关注的人们才使用Qt。期。（实际上，这是开发Gnome的最初动机。）直到2005年，想要能够为Windows发行免费软件的人们一直没有使用Qt。即使在那之后，想要使用GPL以外的其他免费软件的人也根本无法选择使用Qt。因此，任何早于这些日期的免费软件项目都不能使用Qt。而且，当然，编写专有代码的人必须支付特权。

此外，这似乎并不缺乏其他选择。例如WxWidgets，GTK +和Tk都是开源的跨平台工具包。

而且，很长一段时间以来，Windows在台式机上一直占据主导地位，以至于很多软件只能在Windows上运行。如果安装Microsoft工具链，那么使用Microsoft专有的东西比担心其他事情要容易得多，许多程序员就是这样做的。

我几乎同意上面讨论的所有原因，但是这里很多人都说他们不会使用Qt，因为它带来了额外的开销。我不同意这一点，因为当今所有最常见的语言（Java，C＃和Python）本身都承担相当大的开销。

其次，Qt使使用C ++进行编程变得如此简单和直接，以弥补其使用的额外资源。我已经遇到了很多用Qt而不是标准C ++编写的控制台应用程序，因为它们易于编写。

我要说的是，Qt的生产率高于C / C ++，但低于Python之类的语言。

这确实不是发动火焰战争的尝试，我只是想解决一些问题。

Qt未被广泛使用的真正原因可能是它是C ++，并且更少的人将c ++用于桌面应用程序。

Qt不是C ++库。与大多数其他库相比，它需要一个单独的编译步骤，这使构建过程变得更加复杂。

Visual Studio的vs-addin与Qt自己的命令行制作过程一样自动执行此操作。用于构建MFC对话框的资源编译器也是一个单独的步骤，但是仍然是c ++。

Qt是大量资源，在编译之前，您必须在使用的任何计算机上都存在Qt并预安装Qt。这会使设置构建环境更加繁琐。

每个版本的Visual Studio都有一个二进制下载，从源代码进行的构建是一个命令。我认为这些天SDK的源大小没有太大的意义。Visual Studio现在将安装所有C ++库，而不是让您自行选择，结果是编译器的安装大小> 1Gb。

它仅在LGPL下可用，这使得在需要以限制性较高或限制性较小的许可证进行释放时，很难使用单二进制部署。

LGPL仅适用于lib，不会影响您的代码。是的，这意味着您必须交付DLL而不是单个二进制文件（除非您付费），但是在一个需要下载Java运行时或.Net更新以获取微小实用程序的世界中，这并不是什么大问题。在具有单个ABI的平台上，这也不再是问题，因此其他Qt应用程序可以共享库。

在某些情况下，它看起来不像本机程序。由于各种视觉样式的原因，当从一台机器移到另一台机器时，固有地为所有平台设计单个UI看起来并不正确。

应该使用本机窗口小部件和主题。我必须承认我主要从事技术性应用程序，因此我的用户不太在乎样式。尤其是在Windows上，一种具有将所有样式都样式化为智能手机小部件的新时尚，这意味着标准越来越少了。

原因很简单：它与所有主流语言都没有很好的绑定，而且魔术上并不总是适合当前的工作。

使用正确的工具完成工作。如果我正在编写一个简单的命令行应用程序，为什么我会仅仅为了Qt而夸大它？

作为一个更一般的答案（之所以可以给出，因为我在这里很重要），有些程序员根本不会放弃并决定使用它。在某些情况下，除了程序员从未发现需要并对其进行调查外，没有其他特殊原因。

当你更关心你的产品看起来像Qt的框架是合适的一样上比你的产品寻找所有平台的权利在所有平台上。如今，这类应用程序越来越多地转向基于Web的技术。

我同意Qt是一个不错的框架。不过，我仍然有很多问题：

1. 它是用C ++编写的，这是一种非常底层的语言。与使用其他语言编写的Framework相比，仅使用C ++这一事实将使每个Qt程序员的生产力大大降低。使用C ++作为GUI开发语言的主要优点是，它几乎没有自动内存管理的概念，这使开发过程更容易出错。它不是内省的，这使得调试更加困难。其他大多数主要的GUI工具箱都有一些自动内存管理和自省的概念。
2. 每个跨平台工具包都有一个问题，即它只能实现所有受支持平台的最小公分母。那个问题以及不同平台上的不同UI准则都对整个跨平台GUI的整体需求提出了质疑。
3. Qt非常着重于编写所有UI。即使可以使用QtDesigner来构建UI的某些部分，但与（Cocoa / Obj-C）Interface Builder或.Net工具相比，它还是严重缺乏。
4. 即使Qt确实包含许多底层应用程序功能，也无法与为特定平台手工量身定制的框架相提并论。Windows和OSX的本机操作系统库比Qt的实现功能强大得多。（请考虑音频框架，低级文件系统访问等）

就是说，我喜欢将PyQt用于快速的应用程序原型制作或内部应用程序。使用Python进行所有编码可减轻C ++的麻烦，实际上使Qt成为一个非常愉快的地方。

编辑，以回应一些评论：

当我写Qt用C ++编写时，我并不是在抱怨Qt本身，而是在抱怨它所处的环境。确实，Qt很好地管理了自己的资源，但是与您的GUI相关的所有问题，但是- not-Qt代码也必须用C ++编写。即使在那里，Qt也提供了许多不错的工具，但是最终，您必须在该级别上使用C ++。Qt使C ++可以使用，但它仍然是C ++。

至于自省，我的意思是：最难调试的情况是，当您指向某个对象的指针无法按照您认为的方式运行时。使用C ++，调试器可能可以稍微查看一下该对象的内部（如果它恰好在该位置具有类型信息），但是即使那样也不总是可行。另一方面，在相同情况下可可。在Cocoa / Obj-C中，您可以直接在调试器中将消息（“调用函数”）发送到对象。您可以更改对象状态，可以查询对象的属性，可以要求对象的类型和函数名称...这可以使调试更加方便。Qt / C ++甚至都没有。

我真的很喜欢Qt，但是对于很多应用程序来说，它有点重量级。有时，您只是不需要这种级别的复杂性。有时，您只需要一些简单的东西，而没有Qt的所有开销。并非每个应用程序都需要事件驱动，并且C ++提供了一组合理的模板。Boost提供了另一个非常好的集合，并包含了QT所做的许多低级功能（文件，套接字，托管指针等）。

其他应用程序具有许可要求，无法与GPL，LGPL或Qt的商业许可配合使用。GPL不适合用于商业软件。LGPL不适合用于静态链接的软件，并且商业许可证要花钱-许多人不愿支付。

有些具有安全性或稳定性考虑，不允许使用Qt之类的复杂库。

您需要运行moc来预处理源。这不是一个大问题，但是对于新用户而言，这可能是个艰巨的任务。许多程序员认为您需要将Qmake与Qt一起使用，但这是一个错误的说法。可以很容易地将Qt插入其他构建系统。

有些目标的内存或CPU受限制。

其中有一些特定于平台的陷阱。这些陷阱中的大多数都是未记录的。构建一个足够大的应用程序，您将遇到它们并想知道发生了什么（免责声明，我上一次在愤怒中使用Qt的时间是18个月前，因此它可能有所改善）。

仅C ++。还存在其他语言绑定，但是它们往往隐藏或不好地展示了Qt想要的许多功能。

不使用Qt的原因很多，这就是为什么有其他选择的原因。如果您只有一把锤子，那么每个问题都会像钉子一样。

最重要但未提及的事情。在大型项目中，一件事会导致很多问题，而且不必要的代码。Qt的信号时隙机制效率低下。Qt小部件不为事件简单小部件提供必要的信号。例如，您不能为onHover，onMouseEnter，onMouseLeave，onKeyReleased，onLostFocus，onGainFocus等设置信号。即使是最复杂的小部件（例如QTreeWidget）也提供一两个非常简单的无用信号。

是的，您可以使用事件，但是！！！您已经为每个带有自定义事件的窗口小部件创建了新类。这是巨大的效率损失；

• 您已经重写了每个自定义的窗口小部件对象事件，其中有很小的变化。
• 您会失去所有Qt Designer的东西。您必须使用自定义事件来提升每个小部件。
• 项目变得更大且难以维护。
• 因此，您开始不喜欢qt。并开始讨论.net如何提供委托，它比信号槽要好得多，.net组件（小部件）通常如何提供您可以想象的每个事件。等等。

我的一所大学为每个组合框小部件编写了一个新的组合框类，因为他必须使用一些非信号事件。真实的故事...

但是，到目前为止，Qt是最好的C ++ UI框架。

以我个人的观点，学习C ++编程要比陷入其他隐藏其复杂性的语言要简单得多，程序员也不知道后台真正发生了什么。另一方面，Qt在C ++方面增加了一些好处，使其比本地C ++更高级别。因此，对于谁想要以相同的方式开发低级或高级任务的人，Qt C ++是一个很好的框架。C ++（通过某些实践）是一种复杂而简单的语言。对于不想挑战的人来说很复杂，对于喜欢它的人来说很简单。不要因为它的复杂性而离开它！

实际原因并非技术原因。

人们碰巧是不同的。他们的选择也是如此。一致性不是人类的特征。