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

评论

它是本机C ++。大多数开发人员更喜欢高级语言,例如C#。

向后兼容的两刃剑使Qt产生了许多过时,无法修复的缺陷以及其他不良行为。

@ user16764:“最多”吗?

我认为TIOBE指数不是真正准确的度量,因为它度量的是知名度,而不是用途。比较诸如GitHub,Bitbucket,Codeplex和Sourceforge之类的开源存储库中的代码量,可以得出更准确的测量结果。 (而且我相信,这些更精确的测量结果使C和C ++处于#1和#2位置– Java在TIOBE索引中具有不公平的优势,因为它用于大学一年级课程,并且新程序员比有经验的程序员更能引起嗡嗡声) br />
@Giorgio:嗯,您必须在C#中考虑这些事情。 “谁拥有这个”的概念远远超出了“谁叫删除”。智能指针使之明确的事实并不是语言失败。如果您不考虑这些事情,那么您将以我所见过的任何高级语言生成垃圾。

#1 楼

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


评论


@Dehumanizer:这里有LGPL许可证,还有商业许可证。商业许可证是被许可方的数千美元,并且不允许重新分配等。对于采用BSD,MIT或Boost等自由许可的开源项目,作者并没有赚很多钱,他们希望要在自由许可证下发布代码,对LGPL的依赖是不合理的,但是相关开发人员通常无法负担商业许可证。

–比利·奥尼尔(Billy ONeal)
2011年7月1日6:37



#6是我避免它的最大原因。我的意思是,我不需要庞大,笨拙的程序,而且我不喜欢受限于特定的许可证,但这实际上是缺乏良好的本机外观,这对我来说是个大难题。 OSX和Windows的最新版本特别出色地完成了其本机界面的美观,快速和实用的工作,我宁愿利用它们为我所做的所有工作;我发现许多没有本机外观的程序对我来说都是便宜又笨拙的(并非总是如此,但这让我有点烦恼)。

–格雷格·杰克逊(Greg Jackson)
2011年7月1日7:24



您的6号应该是1号。这是Qt迄今为止最大的问题。在许多情况下,它根本不使用本机API。我喜欢我的软件看起来很原生。用户也一样。我从未见过用Qt创建的Mac应用程序看起来像Mac应用程序。没有其他Mac用户,他们对这种事情很挑剔。如果仅使用它来创建Linux应用程序,则将失去它作为“跨平台”的所有好处,因为它实际上是原生的,因此这是唯一看起来是原生的。

–科迪·格雷
2011年7月1日9:07



除了“本机”外观的问题不再存在。 Windows应用程序的旧一致性现在已成为WPF和silverlight所具有的任何独特Blob,发光和动画的混用。看一下Office或Windows 7的“控制”面板,看看当今MS旗舰产品的GUI如何都不一致。 Mac用户-嗯,您的观点很正确。

– gbjbaanb
2011年7月1日在9:19

@TrevorBoydSmith:对不起,但是你错了。 Qt是唯一使用预处理的框架。期。检查GNOME,FLTK,WX和朋友,并向我展示预处理步骤。您将找不到一个。其他一些库带有不同的构建系统,但归根结底,它们是可以由任何C ++编译器构建的C ++库。至于“未在我的原因下出现win32原始版本”,由于我的原因,它出现在#5和#6之间。

–比利·奥尼尔(Billy ONeal)
2011-10-14 17:05



#2 楼

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

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

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

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

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

评论


+1解冻!我只是想写同样的东西。最胡说八道的是“非开源/商业争论”。令人惊讶的是,许多人对“开源”一词的理解有多错误。自从我使用Qt(1.4)以来,它就是开源的。它曾经拥有最公平的许可证:使用Qt-> pay赚钱。

–瓦伦丁·海尼兹(Valentin Heinitz)
13年4月16日在10:26

哦,我真的不在乎将10 MB的DLL添加到包含50 MB的美术作品以及200 MB的视频教程和数据的应用程序中:)

–ПетърПетров
13年8月17日在20:33

这些天Qt所需的空间很便宜。

–trusktr
2014年1月30日下午4:21

这与我在Qt上的经验非常吻合(小部件框架,到目前为止,我还没有使用QML / QtQuick处理任何严重的事情)。适合编写具有复杂UI要求的大型应用程序。学习之后,您将非常有生产力。如果构建系统正确设置,则所提到的缺点(用于移动,ui文件等的单独编译步骤)不是问题。我可以推荐qmake或cmake。

–指甲
2015年12月9日在9:46

从Qt 5.8开始,有一个名为Qt Lite的项目可以最大限度地减少Qt以满足您的特定需求。这是一项商业功能;)

– S.M. Mousavi
19年2月28日在21:23

#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在这方面已经足够困难(修改辅助功能插件后几乎无法工作)。

评论


出于兴趣,您认为WX的主要问题是什么?

–汤姆·安德森(Tom Anderson)
2011年7月1日,11:33

@Tom-糟糕的文档,特别是对于新内容。几乎没有记录AUI组件,缺少了很大一部分,这使得它很难在生产环境中使用。关于事件过程的文档,至少在win32上,关于所遵循的路径基本上是错误的。花了很多时间在计算机上大喊:“这应该可以工作!!!”在深入研究处理代码之前,先确定WX的工作不遵循文档,而我所做的却永远无法工作。

–爱德华·奇异
2011年7月1日在16:57

我还对将属性网格库接受到主线感到不安。我使用了该库,除了代表编写它的程序员实际的知识不足(例如,在构造函数中称为虚函数)以外,它还显示出许多基本的设计缺陷。它以及AUI的不良状态显示出标准降低的趋势。我也不是静态事件表的忠实拥护者,尽管至少有另一种响应事件的方式……与MFC不同,WX太像刺激了。

–爱德华·奇异
2011年7月1日在16:59

谢谢。我只使用了一点,并通过wxPython API使用了它,看起来很不错。我能体会到这会隐藏一些邪恶的东西,但是我只是没有足够深入地参与到更严重的问题中来。我需要注意的一些事情。

–汤姆·安德森(Tom Anderson)
2011年7月1日在17:38

响应信号的所有内容都必须是Q_OBJECT,如今不行……现在,静态函数,函数甚至lambda函数都可以响应信号(可以将函数指针用作插槽)。如果您使用std :: bind将实例成员转换为函数指针,则No-QObject类也可以具有成员插槽。

–ViníciusA. Jorge
19 Mar 1 '19 at 18:52

#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,这是基于神话和十年来过期的信息而想到的。

评论


我不明白的是,为什么这些跨平台库不只是包装函数,甚至更好?如果围绕Cocoa,Win32,KDE / Gnome功能进行定义,则可确保具有所有功能的最佳UI。

– MarcusJ
15年7月10日在10:44

@MarcusJ围绕一个工具包编写包装显然很简单,不要介意4个或更多-但是,如果您认为那样简单,欢迎尝试。至于仅使用条件预处理就可以实现的想法……您一定是在开玩笑吧?

– underscore_d
16-2-17在22:33



@MarcusJ libui就是这样(尽管没有KDE支持)。

–黛米
17年2月27日在0:32

我想补充一点,您现在可以将Qt / QML与.NET一起使用。您无需接触C ++。 github.com/qmlnet/qmlnet PS:我是作者。

– Paul Knopf
19年4月14日在14:27

#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专有的东西比担心其他事情要容易得多,许多程序员就是这样做的。

评论


@btilly:GTK +是跨平台的。例如,Pidgin IM客户端是在GTK +上编写的。

–比利·奥尼尔(Billy ONeal)
2011年7月1日在6:42

好的,但是,可以“某种方式”在Windows上运行:)

– Dehumanizer
2011年7月1日下午6:43

只需在Windows上安装GIMP并看看。

–user281377
2011年7月1日在7:37

是的,GIMP在Windows上可以很好地运行,但是它肯定不适合Windows 7 UI外观。

–艾伦B
2011年7月1日在8:38

Pidgin可能是Windows上GTK的更好示例。它没有任何花哨的功能,但它可以容纳10年或更长时间了吗?

–布伦丹·朗(Brendan Long)
2011年7月1日在16:22

#6 楼

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

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

评论


我想这都是与个人经验有关的,因为我可以用C ++ 14编写OK,但是每次看一些Qt代码时,我都不得不have着眼睛认出它是同一种语言...所以我当然不您认为这里暗示的是生产率的一致提高。

– underscore_d
16-2-17在22:35



@underscore_d显然,如果您非常了解C ++并且不懂Qt,那么使用后者不会提高工作效率。但是,当您同时了解C ++和Qt时,该框架确实使很多事情更容易,更快地实现(C ++ 11、14等填补了空白,但还没有完全解决)。

– ymoreau
18年8月2日在11:01

#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 ++甚至都没有。

评论


1. Qt自己在乎内存管理,您不必在每个“新”之后都调用“删除”。 1a。 C ++不是低级语言,它是具有低级“功能”的高级语言。 3.我同意,但是Qt提供了同时使用QtDesigner和“普通代码”制作UI的功能。 4.再次同意,但是Qt还提供使用本机API的权利。

– Dehumanizer
2011年7月1日,11:47



到nr 1.我认为c ++确实具有半自动内存管理:如果您使用诸如std :: auto_ptr或boost :: shared_ptr等智能指针,则通常不必担心释放内存。也可以为其他资源(必须释放的文件,系统资源)创建此类容器。 RAII模式的使用对内存管理非常有帮助,并且随着它的发展,您真的不必担心内存。

–deo
2011年7月1日12:38



“与其他语言编写的框架相比,仅使用C ++的事实将使每个Qt程序员的生产力大大降低。” [需要引用]

–内森·奥斯曼(Nathan Osman)
2011年7月3日在22:08

@ SK-logic:虽然我认为我理解您第三句话中的所有单词,但我不知道您在说什么。什么是“抽象上限级别”?因此,鉴于Wikipedia对“低级语言”的定义,您的第一句话是错误的。

– David Thornley
2011-10-19 14:46

@ SK-logic:模板元编程是图灵完备的,并且有足够的聪明和知识的人可以利用它。 RAII并不是很好的垃圾收集器,但它或多或少地适用于各种资源的事实弥补了这一点。现在,具体来说,哪种抽象适用于Java,但不适用于C ++?

– David Thornley
2011年10月19日在20:15

#12 楼

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

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


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

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

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

评论


关于事件和创建新类:您可以在需要对事件做出反应的类中使用事件过滤器。

– MrFox
2012年11月20日17:47

“是的,您可以使用事件,但是!!!!您为每个带有自定义事件的窗口小部件创建了新类。这会大大浪费效率;” - 不完全是。我只得到处理多个小部件的bool eventFilter,然后在所有子小部件上安装了eventEventFilter(this)。而且这不会损失效率和编程性能!实际上,我从不使用“ Promoted widgets” ...我只放空的widget,将其安装为eventFilter并在主cpp类中重新实现大多数事件。尝试一下,不费力:)您可以在Qt中自定义几乎所有内容,而无需每次都创建新类

–ПетърПетров
13年8月17日在20:39



#13 楼

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

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

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

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

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

评论


“ LGPL不适合静态链接的[封闭源代码]软件” –似乎不准确,因为实际上LGPL和静态链接在法律上是可能的(请参阅)。

– Tanius
20-05-31在2:35



您的位置看起来正确。请参阅gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic,但这是额外的工作和额外的工作。你能摆脱它吗?是。您想花费精力吗?可能不是。

–亚当·霍斯(Adam Hawes)
20年6月12日,下午3:59

#14 楼

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

评论


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

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