为什么使用 QVector(Qt) 而不是 std::vector答案

【问题标题】：Why use QVector(Qt) instead of std::vector为什么使用 QVector(Qt) 而不是 std::vector
【发布时间】：2011-08-03 03:40:20
【问题描述】：

我对 C++ 和 Qt 很陌生，但我非常擅长 C#/Java。

关键是我喜欢跨平台，但我对 Qt 感到困惑。 std::vector 不是已经跨平台了吗，Qt 不是提供了一个非跨平台的东西吗？

还有File 和QFile 有何不同？

最好有链接，谢谢:)

【问题讨论】：

没有跨平台的Vector。我想你的意思是std::vector。 C++ 区分大小写。
也没有与QFile 相比的File。 FILE* 完全不同。
Qt 是旧的，并且提供的组件曾一度在所有编译器上都不可用。新代码中的那些用处不大。
补充@Bo Persson 的答案：Qt 容器甚至不是 64 位干净的。他们使用int 来表示大小，因此他们在 x86-64 上存储的元素永远不会超过 2^31。
@shbk：只要类的方法/ivars 是使用 int 定义的，只要将真正的 64 位值传递给它就不会获得任何 64 位的好处，因为它们会丢失它通过的第一个隐式转换。

标签： c++ qt vector

【解决方案1】：

QVector 类是引用计数的，适合在不复制的情况下共享。 Qt提供了很多与STL容器对应的容器。一份描述这些内容的文档，其中包含一些内部原理的解释和一些基本原理：

Inside the Qt 4 Containers

【讨论】：

【解决方案2】：

来自over here：

Qt 起源于 C++ 和标准库不是标准化或得到很好的支持编译器。因此它复制了一个很多东西现在在标准库，例如容器和类型信息。最多重要的是，他们修改了 C++ 语言提供信号，这样 Qt 类不能轻易使用非 Qt 类。

【讨论】：

这不是故事的全部，给人一种错误的印象。仍然有理由使用 Qt 容器，尤其是共享内存等。但是，如果您没有使用其他任何 Qt，请不要使用它们。
我不知道 gtkmm 常见问题解答是否是 Qt 信息的最佳来源......至少说 Qt 修改 C++ 语言的部分是不正确的。
@Roku ：您还能如何描述 MOC？
C++ 语言保持不变

【解决方案3】：

C++ 的std::vector 是跨平台的，因为它是C++ 标准的一部分。每个符合 C++ 标准的编译器都必须提供它。

我不熟悉 Qt，但我确实看到了这个in the docs：

注意：这个类中的所有函数都是可重入。

也可能（推测）QVector 类比std::vector 更容易集成以保存以Qt 为中心的对象。同样，我对 Qt 不熟悉，所以您必须自己决定。

根据经验（有很多例外），我倾向于使用std::vector，除非我有令人信服的理由使用某些特定于库的容器类。

【讨论】：

reentrant 与您的意思没有任何关系。可重入意味着任何线程都可以在可重入类的实例上调用成员函数，而没有其他类调用同一类的成员函数
@AlexShulzhenko：同意可重入与线程安全。这里所有的可重入意味着内部数据存储（数组）是私有的，只能通过类方法访问和操作。参考：doc.qt.io/qt-5/threads-reentrancy.html#reentrant

【解决方案4】：

这篇文章看起来不错。它将 Qt 模板库与标准模板库进行了比较：

QTL vs STL

希望，看到文章中列出的所有差异，您会觉得很有趣。

编辑：

我觉得有趣的是：

我认为 最大的 QTL 的优点是它具有相同的实现（包括二进制兼容性）在所有操作系统上 Qt 支持。一些 STL 实现可能低于标准当涉及到性能或他们可能缺少功能。一些平台甚至没有 STL！在另一方面，STL 更多可定制的，可在其头文件中的全部内容...... 就像我说的，没有明确的赢家。

就像他说的，没有明显的赢家。但是仍然阅读这篇文章可以使很多事情变得清晰。知道其中的区别总比不知道另一个而只选择一个要好。

【讨论】：

从同样的观点来看，Qt 可能低于标准并且缺少功能。什么是模板容器的二进制兼容性？
有人更新这个帖子吗？我的意思是自从发布此答案以来已经有一段时间了。 C++11 和 C++14 呢，它们给 STL 带来了什么新东西吗？ C++现在不是在努力跨平台吗？只是我自己的好奇心。
@Paul-SebastianManole：C++ 从一开始就是跨平台的。
@Paul-SebastianManole：甚至 STL 从一开始就是跨平台的。
@Nawaz 似乎“QTL vs STL”链接不再有效。

【解决方案5】：

我对@987654321@ 的糟糕经历与QTL 没有引发任何异常有关；这使得追踪和修复严重错误变得更加困难。此外，STL 的实现与编译器密切相关，因为库的某些部分需要对语言进行特定于编译器的扩展。这意味着STL 实现通常可以胜过QTL，后者需要可移植，因此无法从所述扩展中受益。不过，调试问题对我来说很关键。

【讨论】：

【解决方案6】：

由于没有答案提及，包括QVector 在内的Qt 容器通常具有更完整的API，与std::vector 相比，它确实提供了一定程度的额外便利并减少了冗长。

QVector 并没有真正集成到 Qt API 中，这个角色由不合适的 QList 承担，因此使用 QVector 来获得与 Qt API 的整体更好兼容性并不是一个强有力的论据。请注意，随着QList 的缺点越来越多，这可能会在 Qt 6 中发生变化。

话虽如此，如果您的应用程序已经依赖 Qt，那么为了方便起见，使用 QVector 会很有意义。我认为没有人会为一两个容器添加像 Qt 这样臃肿的依赖项。 QVector 高效且性能稳定，可以在 Qt 支持的任何平台上毫无问题地运行。

另一方面，如果你想创建一个与框架无关的核心逻辑 API，如果可能的话，最好用标准 C++ 开发它，这样你就可以得到一些不依赖于特定的可移植的东西GUI 框架，因此您可以在将来需要时轻松将其迁移到其他框架。

【讨论】：