在用纯 C++ 编写了很多代码之后,我最近又回到了 Qt/C++ 编程。
在浏览 StackOverflow 时,我经常 catch "Why use pointers?" 之类的帖子。在大多数情况下,答案的要点是“ 如果可以避免,请不要使用它们 ”。
在 C++ 中编码时,我现在主要尝试使用通过 (const
) 引用传递的堆栈变量,或者,如果需要,std::shared_ptr
分别std::unique_ptr
需要的地方。
回到 Qt,我发现所有这些“原则”显然都被完全忽略了。
我知道 Qt 使用自己的内存管理来处理原始指针,但这是我的问题:
他们为什么不至少使用 shared_ptr
或 unique_ptr
, 特别是因为他们甚至有自己的实现 QSharedPointer
?
最佳答案
Qt 从 4.x 版本开始是围绕在 C++ 环境中模仿 Java 的框架思想而设计的,使用 C++98 手段。它建立了“所有者”-“从属”关系,而不是 RAII 交互方法,在框架的术语中是“父”和“子”。更重要的是,Qt 使用 PIMLP 私有(private)实现的概念。 QObject
您使用的 s 并不是正在发生的事情的真实表示,它们是完全隐藏的内部实现的接口(interface)。
按照设计,您必须创建子元素的 QObject 派生对象并将所有权传递给拥有对象。例如。在窗口是所有者的情况下,窗口内的按钮将是“从属”对象。当所有者被删除时,所有从属于它的对象也将被删除。全部 QObject
s 是线程感知的,但 QWidgets
只能在主线程中工作。这将创建一个非拥有指针:
QWidget *myWidget = new QWidget(mainWindow);
mainWindow
将拥有QWidget
在这种情况下的例子。但是这个是拥有的?QWidget *myWidget = new QWidget;
它不是。它仍然归 QApplication 所有。QObjectDerivedClass *myWidget = new QObjectDerivedClass;
它是一个拥有指针,但是这个对象被注册为存在于我们的框架中。更重要的是,如果为实例分配了名称,则可以找到任何实例,存储 QObject 以访问它们只是一种缓存优化。全部
QObjects
和 QWidgets
全局注册并且是可迭代的。随着 QApplicationCore
的破坏例如,所有顶级 QWidget 都将被释放。至少在 QDesktopWidget
的 Qt 4.x 版本中,该规则存在未记录的异常。即使对象是顶级小部件,它们也会被忽略。所以,如果一个 QMainWindow
通过成为它的 child 而被迫出现在某些屏幕上,它不会被破坏。现在开始发挥信号槽连接。在 GUI 中,某些处理程序会在父子连接建立后立即开始工作,但您可以添加新的处理程序。如果在
QEventLoop
创建的消息泵的开始和结束之间删除子对象,你的程序可能会遇到一个 UB。为避免这种情况,您必须调用 deleteLater()
在设计时刻标记要删除的对象。线程之间的信号处理是分开完成的。实际上,主事件循环是 GUI 中唯一与其他线程同步的部分。由于某些受支持的嵌入式平台强加的这种复杂结构和已经存在的在一个线程中工作的要求,与可能对性能的影响相比,在 GUI 框架中使用智能指针的需求可以忽略不计。
在 C++11 Qt 之前有
QPointer
(并且仍然得到它),它知道 QObject 是否仍然存在或不使用类似于所有者- child 交互的机制。这种设计早于 C++11 和
QSharedPointer
之后才出现,以填补用户要求维护用户定义数据模型的利基市场。它不支持某些功能,例如,您不能像 ISO 版本那样拥有它的原子版本,直到 5.x 的最后一个版本才部分原子版本。 QAtomicPointer
不是QPointer
或 QSharedPointer
, 它的作用类似于 std::atomic<QObject*>
. QSharedPointer
虽然允许使用自定义非独立删除器,包括调用 deleteLater()
:QSharedPointer<MyDataQObject> objPtr { new MyDataQObject, &QObject::deleteLater };
假设 MyDataQObject
源自 QObject
, objPtr
将调用方法deleteLater()
在托管对象的上下文中,而不是使用 delete
销毁或重置时在托管指针上。
关于c++ - 为什么 Qt 使用原始指针?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/67918226/