Qt的危险之处是什么？[关闭]

10

阳光下没有完美的事物。Qt也不例外，它也有局限性：我们不能在GUI以外的线程中使用像素图，我们不能使用每通道16位图像格式的QImage等。

由于Qt的限制，哪些情况迫使您破坏了设计？
最讨厌的怪癖是什么？
在项目中使用Qt时应避免哪些设计决策？

qt design-decisions

— 葡萄藤
source

你能说的 Qt的？如果你把它扩大到“Q工具包”，你可以添加一个“的”前面的它，但是它正确/良好做法说了 Qt的？只是好奇。

— 安托

@Anto：我想the不是一定要绑定到corners这里，Qt但这只是我的直觉，因为我是俄语：)

— vines

一种可能的危险曲线是该项目可能会遇到财务问题。诺基亚最近与微软签署了一项协议（在其手机上使用Win7），这使Qt的未来处于不稳定状态。

— 彼得·罗威尔

我对知道这个答案非常感兴趣，因为我对C ++可视化编程

— 不满意

@Vines：“ QT的危险之处是什么？”呢？

— 克里斯（Chris

12

具有讽刺意味的是，我想说Qt的功能也是缺点之一。有这么多强大的构造和扩展，您在Qt中编写的代码很容易以“ Qt方式”被牢固树立。尝试将功能提取到另一种语言中不仅意味着要重写，还需要了解很多Qt特定的技术。

Qt的广度意味着雇用程序员意味着要么承诺拥有Qt经验的人，要么接受该专业知识的培训。赶上承包商并加快速度要比香草C ++难。

当Qt从3.x更改为4.x时，我们的团队需要近9个月的时间来进行移植，在此期间几乎没有添加任何新功能。您希望在剩余的时间内弥补主要的升级成本以提高开发效率。（注意，我省略了Qt的优点，其中也有很多优点）

— 詹姆士·克里斯蒂
source

2

我认识的大多数人都很难从Qt3到Qt4端口。这个QML和在较新版本中引入的类似内容使我感到担心，因为这可能意味着将再次出现一个复杂的端口。

— Vitor Py

10

Qt不使用标准的C ++库，但具有自己的QString，QVector，QMap等。

这意味着您必须做出重要的设计决策：应用程序的哪些部分将使用QString，哪些部分将使用std :: string？

在某些部分中使用std :: string，在其他部分中使用QString，这意味着您必须在边界上的QString和std :: string之间进行转换。

为了避免这种开销，可以决定在整个应用程序中使用QString。但这使使用非基于Qt的第三方库变得更加困难，例如boost。

（请注意，std :: map与QMap，std :: vector与QVector等相同）

确定哪些零件使用Qt的类型，哪些零件使用STL是一个重大的设计决策，具有重要的意义。只是因为Qt拒绝使用标准的C ++库。

恕我直言，根据项目的不同，该决定可以采用任何一种方式。因此，我无法回答您要避免的问题。

— 舍尔德
source

1

我同意，但是我会欣喜若狂，说QString（等）也是优点之一，因为与它们一起工作真是太好了。

— 约翰

1

另外，使用不使用QString的库并不是很困难。有一个简单的方法可以将QString转换为std :: string，反之亦然。没什么。

@Glenn Nelson：是的，如今有用于QString的转换函数。非常有用和方便！但是尤其是对于QVector和QMap，转换时会产生开销（并且简单的解决方案不适用于QVector <QString>）；在设计过程中应考虑该开销，以避免性能问题。

— Sjoerd

3

这并不能直接回答问题，但我认为值得一提：Qt最“危险”的一面也许就是诺基亚与MSoft接轨了……

— 向量
source

2

但是他们放弃了Qt来做到这一点。

— 马丁·贝克特

1

为了完整起见-Qt的商业部分现在由Digia拥有，而Qt已迁移到“开放治理”系统，其他人可以轻松地做出贡献。还有一个KDE Free Qt基础，可以保护Qt免受封闭源的侵害。

— Vishesh Handa 2014年

2

最近，我发现，尽管QChar命名为QChar，但它实际上并不对应于一个字符，而是对应于UTF-16代码单元。因此，当您想逐个字符地扫描任意Unicode文本字符时，必须添加用于处理高位和低位替代，组合字符等的算法。

— 塞巴斯蒂安·内格拉苏斯（Sebastian Negraszus）
source