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

#1 楼

我并不是真的希望这是一个猛烈的回答，但这就是我不亲自使用Qt的原因。关于它，有很多好话要说-即API在大多数时间都有效，并且可以无缝地桥接平台。但是我不使用Qt，因为：在某些情况下，它看起来不像本机程序。由于各种视觉样式的原因，当从一台机器移到另一台机器时，固有地为所有平台设计单个UI看起来并不正确。例如，在Mac机器上，分隔条通常相对较粗，按钮较小且带有图标圆形。在Windows机器上，分割条通常较窄，按钮的文字更丰富，并且具有更多的方形设计。仅仅因为您可以为每个平台编写一个UI并不意味着您应该为大多数应用程序使用。
Qt不是C ++库。它需要一个单独的编译步骤，与大多数其他库相比，编译过程更加复杂。
由于（2），C ++ IDE和工具可以将Qt表达式标记为错误，因为它们不了解Qt的细节。这几乎迫使QtCreator或仅文本编辑器（如vim）使用。这会使设置构建环境变得更加乏味。
仅在LGPL下可用，这使得在需要以限制性较高或限制性较小的许可证发布时，很难使用单二进制部署。 >与类似编写的“纯文本本机应用程序”（当然，为KDE编写的应用程序除外）相比，它生成的编译二进制文件非常大。

#2 楼

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

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

我们开发了复杂的医学成像商业应用程序，
Qt坚持了下去。错误，
，但我感觉他们很久没有尝试过Qt了（
（每个新版本都在不断改进...）如果您注意的话，他们评论的所有问题都不是问题。 。

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

顺便说一下，我们仍然在C＃.NET中编写应用程序，并且已经做了很长时间了。因此，我认为我有自己的见识。

#3 楼

在我不喜欢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风格编程的人们实际上可能会更好。 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在这方面已经足够困难（修改辅助功能插件后几乎无法工作）。

#4 楼

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

如果您正在编写跨平台的应用程序，那么您可能已经在Java等其他技术（例如，您在“ Java商店”中工作）方面有很大的归属。您选择的技术可能取决于您所开发的生态系统，例如特定语言的API。在这种情况下，最大限度地减少技术数量可能是有益的。

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

尽管规则说我应该一直专注于回答问题，我确实想反驳Billy ONeal提出的一些问题，我认为他总结了不使用Qt的常见原因很不错：Qt确实是C ++库/框架/头文件。宏处理器（moc）增强了它的功能，该处理器可以实现信号和时隙等功能。它转换其他宏命令（例如Q_OBJECT），使类具有自省性，您可能会想到这些其他种类的东西，可以在C ++中添加Objective-C功能。如果您对C ++的了解足够多，会因缺乏纯正而受到冒犯，即您是专业人士，则1）不要使用Q_OBJECT及其同类产品；或2）对此会非常感激，并在非常有限的情况下编程这会导致问题。对于那些说“对信号和插槽使用Boost的人”！然后我反驳说，您正在将一个“问题”交换为另一个。 Boost巨大，它有自己经常被提及的问题，例如文档质量低下，可怕的API和跨平台恐怖（请考虑使用gcc 3.3之类的旧编译器和AIX之类的大型铁编译器）。
要获得编辑器支持，也从1开始，我有些同意。实际上，即使您不使用Qt，Qt Creator还是IMHO最好的图形C ++编辑器。许多专业程序员都使用emacs和vim。另外，我认为Eclipse可以处理其他语法。因此，Qt宏（Q_OBJECT）或信号/插槽添加没有问题。您可能在Visual Studio中找不到这些宏，因为（我承认）它们是C ++的附加功能。但是总的来说，由于C＃/。NET人们拥有自己专有技术所涵盖的许多功能，因此他们仍然不会使用Qt。
关于Qt的大小源，只要它能在一夜之间编译，谁在乎？我“不到一整天”就在双核Macbook上编译了Qt 4。我当然希望这不是促使您决定使用或不使用特定技术的原因。如果确实存在问题，则可以从Qt网站下载适用于Mac，Linux和Windows的预编译SDK。
可以通过三种选择获得许可：1）如果您希望修改Qt ITSELF而不共享，或者隐藏一个人正在使用Qt而又不愿出处商标的事实，这将是专有许可（这对于品牌和形象非常重要！）2 ）GPL和3）LGPL。是的，静态链接存在问题（将所有Qt都滚动到二进制文件中）-但我认为这更多是因为无法窥视内部并且注意到您正在使用Qt（归因！）。我试图从Digia购买专有许可，他们告诉我“对于您正在做的事情，您真的不需要它。”哇。来自一家从事许可证销售业务的公司。
二进制文件/捆绑包的大小是因为您必须将Qt内容分发给没有许可证的人：Windows已经拥有了？ Visual Studio的东西，或者您必须安装运行时。 Mac已经带有巨大的Cocoa，并且可以动态链接。尽管我不做很多分发工作，但分发约50兆字节的静态文件（使用UPX等二进制剥离程序/压缩实用程序甚至可以使它变小）时，我从未发现太多问题。我只是不太在乎这样做，但是如果带宽成为一个问题，我会在构建脚本中添加UPX步骤。我认为“大多数”会同意Mac最接近统一的外观。但是我坐在这里，看着Safari，iTunes，Aperture，Final Cut Pro，Pages等，尽管它们是由操作系统供应商制造的，但它们看起来却完全不同。我认为“感觉”方面更相关：小部件样式，响应能力等。如果您关心响应能力，那么这是使用C ++而不是Java或其他高度动态语言的一个很好的理由。 （目标C也会动摇，但我试图消除有关Qt的神话）

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

#5 楼

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

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

长期以来，Windows在桌面系统中占据主导地位，以至于很多软件只在Windows上运行。如果安装Microsoft工具链，那么使用Microsoft专有的东西比担心其他事情要容易得多，许多程序员就是这样做的。

#6 楼

我几乎同意上面讨论的所有原因，但是这里很多人说他们不会使用Qt，因为它带来了额外的开销。我不同意这一点，因为当今所有最常见的语言（Java，C＃和Python）本身都会承担很多开销。补充其使用的额外资源。由于可以轻松编写它们，因此我遇到了许多用Qt而不是标准C ++编写的控制台应用程序。

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

#7 楼

实际上，这并不是发动火焰战争的尝试，我只是想解决一些问题。将c ++用于桌面应用程序。


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


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


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


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


它仅在LGPL下可用，这使其可以当人们需要以更多限制性或更小的限制性许可证发布时，难以使用
单一二进制部署。它不会影响您的代码。是的，这意味着您必须交付DLL而不是单个二进制文件（除非您付费），但是在一个需要下载Java运行时或.Net更新以获取微小实用程序的世界中，这并不是什么大问题。在具有单个ABI的平台上，因此其他Qt应用程序可以共享库，这也不是什么大问题。 br />本质上，为所有平台设计单个UI并不能实现
从机器到机器的移动，对于各种视觉效果
样式原因。

应该使用本机小部件和主题。我必须承认我主要使用技术应用程序，因此我的用户不太在乎样式。尤其是在Windows上，可以将所有样式本身都用作智能手机小部件的新时尚反正意味着标准越来越少。

评论

---

很多大型软件公司都使用C ++构建商业应用程序，但我不知道很多使用QT的公司。因此，尽管我了解非C ++开发人员可能会避免QT，但即使在编写C ++应用程序时，也有其他避免QT的原因。实际上，确实没有任何我无法发现的跨平台语言和GUI工具包。似乎跨平台开发仅是平原上的困难，而做到这一点绝非易事或花钱，而且QT做出的承诺（一次编写您的GUI并在任何地方重复使用该GUI）还不够。

– Warren P
2012年11月20日19:45

---

大多数台式机C ++软件要么因为在20年前就开始在MFC中使用，要么使用20年前就开始使用的内部工具包来避免使用MFC（例如MS-Office或Autocad）。我非常怀疑用WPF用C ++ / CLR编写。但是，即使没有跨平台的考虑，我仍然认为Qt是最好的（或至少更糟的！）台式机工具包。像大多数人一样，我们正朝着Webby前端（可能在QtQuick / QML中使用）和C ++服务器后端移动-可能会使用Qt信号/插槽但没有GUI

–马丁·贝克特（Martin Beckett）
2012年11月20日19:52

---

我同意。最差。即使在仅Windows应用程序上，我也希望调试QT问题而不是MFC问题。

– Warren P
2012年11月20日20:02

---

@WarrenP-是的，我不会错过在codeproject中搜索MFC缺少的所有内容的信息。但是随着MSFT对本地代码的新发现，他们并没有做太多事情来简化编写gui的工作。

–马丁·贝克特（Martin Beckett）
2012年11月20日20:40

---

#8 楼

原因很简单：它与所有主流语言都没有很好的绑定，而且在魔术上并不总是适合于手头的工作。如果我正在编写一个简单的命令行应用程序，为什么我会仅仅为了它而用Qt夸大它？在这里），一些程序员根本不会放弃并决定使用它。在某些情况下，除了程序员从未发现需要并对其进行调查外，没有其他特殊原因。

评论

---

但是Qt提供了仅编写控制台应用程序的功能。是不是

– Dehumanizer
2011年7月1日在9:18

---

@Dehumanizer：我不知道。但是，为什么我将它用于小型实用工具？当我仅用标准C ++编写应用程序时，会给我带来什么好处？似乎您在寻找使用库的原因，这是一种向后编程的方法。

–轨道轻赛
2011年7月1日在9:20

---

@Dehumanizer：正如我所说，这是一种向后的方法。当您找到需要的书架时，您就会知道，然后可以尝试一些，看看哪种书架更适合您的需求。在没有用例的情况下尝试在库中收集意见是愚蠢的事情。

–轨道轻赛
2011年7月1日在10:15

---

“如果我正在编写一个简单的命令行应用程序，为什么我会仅仅为了Qt而夸大它”，至少有一个用Qt编写的非常著名的非GUI工具-Doxygen：-

–瓦伦丁·海尼兹（Valentin Heinitz）
13年4月16日在13:36

---

@Dehumanizer例如，当您必须非常快速地处理文件，xml，unicode，json，regexp，concurency，数据库等时，不想下载，采用，维护十二个第三方库。

–瓦伦丁·海尼兹（Valentin Heinitz）
13-4-16在13:40

---

#9 楼

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

#10 楼

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

#11 楼

我同意Qt是一个不错的框架。尽管如此，我仍然遇到许多问题：


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


编辑，以回应一些评论：

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

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

#12 楼

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

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


您重写了每个自定义的widget对象事件，只有很小的变化。
您丢失了所有Qt Designer内容。您必须使用自定义事件来推广每个小部件。
项目变得越来越大且难以维护。
因此，您开始不喜欢qt。并开始讨论.net如何提供委托，它比信号插槽好得多，.net组件（小部件）通常如何提供您可以想象的每个事件。等。

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

然而，Qt迄今为止是起伏不定的最好的C ++ UI框架。

#13 楼

我真的很喜欢Qt，但是对于许多应用程序来说，它有点重量级。有时，您只是不需要这种复杂性。有时，您只需要一些简单的东西，而没有Qt的所有开销。并非每个应用程序都需要事件驱动，并且C ++提供了一组合理的模板。 Boost提供了另一个非常好的集合，并包含了QT所做的许多低级功能（文件，套接字，托管指针等）。 GPL，LGPL或Qt的商业许可证。 GPL不适合商业软件。 LGPL不适合用于静态链接的软件，并且商业许可证要花钱-许多人不愿意支付。 >
您需要运行moc来预处理您的源。这不是一个大问题，但是对于新用户而言，这可能是个艰巨的任务。许多程序员认为您需要将Qmake与Qt一起使用，但这是一个错误的说法。可以很容易地将Qt插入其他构建系统中。

某些目标的内存或CPU受限。

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

它是C ++只要。还存在其他语言绑定，但是它们倾向于隐藏或不好地暴露您想要Qt的许多功能。

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

#14 楼

实际原因不是技术原因。
人们恰好不同。他们的选择也是如此。一致性不是人类的特征。

评论

---

这就是为什么所有人都靠腿走路吗？好吧，那些至少有腿的人...

– dtech
15年8月23日在9:43

---