代码之家 › 专栏 › 技术社区 › Evan Teran

有利于限制qt对象的范围?

qt c++

Evan Teran · 技术社区 · 16 年前

与分配的qt对象 new 都是为你处理的。因为qt对象有一个良好的父子关系,所以在某个时刻(几乎总是在父对象被破坏时)事情会被清除。

所以我的问题是:考虑到一些小部件存在于应用程序的生命周期中,限制一些子小部件的范围是否被认为是好的/有益的?在我看来,如果不这样做,在应用程序退出之前,应用程序可能不会释放这些对象。例如:

MyMainWindow::contextMenu(...) {
    QMenu *menu = new QMenu(this);
    // ...
    menu->exec();
}

VS:

MyMainWindow::contextMenu(...) {
    QMenu *menu = new QMenu(this);
    // ...
    menu->exec();
    delete menu;
}

对比:

MyMainWindow::contextMenu(...) {
    QScopedPointer<QMenu> menu(new QMenu(this));
    // ...
    menu->exec();
}

我最喜欢最后一个,我知道菜单对象将被清除立即 ,无需添加任何代码行。但是,在第一个,它应该被清理干净最后 . 我是否在努力管理这些qt小部件的生命周期?我应该把它完全留给qt吗?

2 回复 | 直到 16 年前

Jeremy Friesner 16 年前

在第一个示例中,当这个(即myMainWindow对象)是…这可能不是您想要的,因为这意味着如果多次调用ContextMenu(),多个未打开的旧qmenu对象将在内存中累积,并且如果用户长时间不关闭/删除myMainWindow,最终可能会占用大量RAM。

你的第二个和第三个例子都很好。第三种可能稍好一点,因为它避免了在没有调用delete的地方引入任何bug的可能性。

Caleb Huitt - cjhuitt 16 年前

如果所有对象的作用域与父对象的作用域明显不同,我会尝试清除它们。我喜欢你的第二个或第三个选择,我想提议第四个:

MyMainWindow::showMyDialog() {
    QDialog *d = new MyDialog(); // Oftentimes parents don't make sense for dialogs
    d->setAttribute( Qt::WA_DeleteOnClose );
    // ... presumably connect signals/slots here
    d->show();
} // d isn't deleted yet, but will be once the dialog is accepted or rejected 
  // (and all corresponding signals are emitted).

推荐文章

Andrey Yankovich · Qt 6.8 linux(gcc)Web引擎缺失

1 年前

Wolfspirit · 你如何确定一个时间点是否在一个时间段内?

1 年前