Корректное удаление виджета Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Переключить на: Древовидный Переключить на: Стандартный Линейный

[Гость_Гость_*]

Есть базовый виджет

class BaseFormWidget: public QWidget
{
    protected:
        QWebView* webView;
    public:
        BaseFormWidget(QWidget* parent = 0);
        ~BaseFormWidget();
};

Уничтожается так:

BaseFormWidget::~BaseFormWidget()
{
    delete webView;
}

От него наследуется другой виджет:

class frmServiceSelect: public BaseFormWidget
{
    Q_OBJECT

    private:
        std::vector<Button*> *serviceButtons;

        Button* _btnOk;
        Button* _btnBack;
        Button* _btnCancel;

        int _index;

    public:
        frmServiceSelect(QWidget *parent = 0, QDomNode *node = NULL, int id = 0);
        ~frmServiceSelect();

    public slots:
        void slotDestroy();
};

При нажатии на кнопку вызывается слот SlotDestroy, который вызывает деструктор:

frmServiceSelect::~frmServiceSelect()
{
    delete serviceButtons;
    delete _btnOk;
    delete _btnBack;
    delete _btnCancel;
}

void frmServiceSelect::slotDestroy()
{
    delete this;
}

При каждом цикле создания и удаления frmServiceSelect программа память освобождается не полностью. то 10-12 кб прибавляется к объему потребляемой оперативки, то 60-80... Как корректно подчистить память?

[BRE]

void frmServiceSelect::slotDestroy()
{
    delete this;
}

Не хорошо так удалять самого себя. Лучше воспользоваться методом QObject::deleteLater().

Утечки памяти лучше смотреть с помощью специальных средств.

[kwisp]

а почему ты в диструкторе уничтожаешь объекты?

BaseFormWidget::~BaseFormWidget() {     delete webView; }
frmServiceSelect::~frmServiceSelect() {     delete serviceButtons;     delete _btnOk;     delete _btnBack;     delete _btnCancel; }

у тебя что webView, serviceButtons, _btnOk, _btnBack, _btnCancel
не имеют parent`a ?

[Гость_Гость_*]

Паренты имеются, конечно же. А уничтожаю я так, для надежности

[Гость_Гость_*]

Скачал Deleaker - буду искать утечки

[kwisp]

Паренты имеются, конечно же. А уничтожаю я так, для надежности

я бы для надежности тогда уже писал

delete webView;
delete webView;

чтоб наверняка грохнуть!

дока.

Member Function Documentation
Q_INVOKABLE QObject::QObject ( QObject * parent = 0 )
Constructs an object with parent object parent.
The parent of an object may be viewed as the object's owner. For instance, a dialog box is the parent of the OK and Cancel buttons it contains.
The destructor of a parent object destroys all child objects.
Setting parent to 0 constructs an object with no parent. If the object is a widget, it will become a top-level window.
See also parent(), findChild(), and findChildren().

[Гость_Гость_*]

я бы для надежности тогда уже писал

delete webView;
delete webView;

чтоб наверняка грохнуть!

Я об этом уже тоже стал подумывать

[SABROG]

delete webView;
delete webView;

Так надежности как раз не будет, так как программа просто упадет

Вот если только так:

delete webView;
webView = 0;
delete webView;

А для указателей не на объекты на базе QObject'a можно использовать QSharedPointer.

[kwisp]

Цитата(kwisp @ 24.9.2009, 10:42) *
delete webView;
delete webView;
Так надежности как раз не будет, так как программа просто упадет

это же шутка была!.

конечно упадет(в лучшем случае) а может и просто бед натворить по уничтожению других объектов.
а второй твой вариант тоже не зачем:)

[BRE]

а второй твой вариант тоже не зачем:)

Удаление нулевого указателя валидная операция.

[kwisp]

Удаление нулевого указателя валидная операция.

пусть так.
а зачем это делать так явно?

[Litkevich Yuriy]

а зачем это делать так явно?

Дык, для надёги. kwisp, ты разве не понял, что это уже шутки пошли ?

[kwisp]

[igor_bogomolov]

Всегда считал, что удалять классы потомки от QObject через delete чревато. Только через QObject::deleteLater(). Ведь к объекту может обратиться event loop, а мы уже класс грохнули. Получим крах приложения. Поправьте, если я не прав.

[BRE]

Всегда считал, что удалять классы потомки от QObject через delete чревато. Только через QObject::deleteLater().

Вовсе не чревато.
Одновременно доступ к объекту может осуществляться только из разных потоков. Если этого нет, то любой объект можно спокойно удалять delete (даже если у него есть parent).

Ведь к объекту может обратиться event loop, а мы уже класс грохнули. Получим крах приложения. Поправьте, если я не прав.

Если сейчас выполняется твоя функция (в которой удаляется какой то объект), то это говорит о том, что процессор выполняет код этой функции, а не обрабатывает события или делает что-то еще.

[Litkevich Yuriy]

Если сейчас выполняется твоя функция (в которой удаляется какой то объект), то это говорит о том, что процессор выполняет код этой функции, а не обрабатывает события или делает что-то еще.

а потом?

[BRE]

а потом?

А потом объекта уже не будет... Деструктор QObject уберет указатель на этот объект из списка parent (если он есть) и уничтожит его.

Сообщение отредактировал BRE - 24.9.2009, 22:41

[Litkevich Yuriy]

Сейчас глянул код деструктора - он давольно навороченый:

QObject::~QObject()
{
    Q_D(QObject);
    if (d->wasDeleted) {
#if defined(QT_DEBUG)
        qWarning("QObject: Double deletion detected");
#endif
        return;
    }
    d->wasDeleted = true;

    d->blockSig = 0; // unblock signals so we always emit destroyed()

    if (!d->isWidget) {
        // set all QPointers for this object to zero - note that
        // ~QWidget() does this for us, so we don't have to do it twice
        QObjectPrivate::clearGuards(this);
    }

    emit destroyed(this);
...

[SABROG]

Ага, а потом делать рефакторинг приложения, если захочется добавить дополнительный поток. Лучше уж сразу deleteLater() использовать, если это не критично. Хотя я думаю, что в местах где скорость и память критичны - не используются QObject'ы.

[BRE]

Ага, а потом делать рефакторинг приложения, если захочется добавить дополнительный поток. Лучше уж сразу deleteLater() использовать, если это не критично. Хотя я думаю, что в местах где скорость и память критичны - не используются QObject'ы.

Не нужно удалять объект во всех методах класса, тогда в одном месте нужно будет заменить delete на deleteLater.
Если решил добавить поток, который будет работать с объектом из главного потока, там по любому нужно будет делать телодвижения для обеспечения корректного доступа к нему из нескольких потоков.

[SABROG]

Лучше, когда этих телодвижений меньше. Code less - create more.

[igor_bogomolov]

Если сейчас выполняется твоя функция (в которой удаляется какой то объект), то это говорит о том, что процессор выполняет код этой функции, а не обрабатывает события или делает что-то еще.

А потом объекта уже не будет... Деструктор QObject уберет указатель на этот объект из списка parent (если он есть) и уничтожит его.

Объект удалится, а сообщения для этого объекта почистятся в деструкторе QObject?
Помогите тогда разобрать в таком коде

MyLabel::MyLabel(QWidget *parent) : QLabel(parent)
{
    movie = new QMovie("post.gif", "gif", this);
    connect(movie, SIGNAL(frameChanged(int)), this, SLOT(myslot2()));
    movie->start();
}

void MyLabel::myslot2()
{
    qDebug("delete");
    delete movie;
//    movie->deleteLater();
}

В током виде приложение моментально падает, хотя из выше сказанного получается, что не должно. Если удалять через deleteLater, этого не произойдёт.

Хм...
Заменил QMovie на QTimer, затем на QPushButton - вылетов нет.
В чем проблема с QMovie?

[BRE]

Я чуть выше писал, что нельзя удалять объект из самого себя, для этого как раз подходит deleteLater.
А здесь, не явно, но именно это и происходит.
Из цикла обработки событий вызывается обработчик события таймера для объекта movie, он посылает сигнал frameChanged, это разворачивается в прямой вызов метода myslot2, из которого мы убиваем объект movie.

[Litkevich Yuriy]

это разворачивается в прямой вызов метода myslot2, из которого мы убиваем объект movie.

об этом я даже и не подумал

[igor_bogomolov]

Понятно.
Сколько интересно подобных объектов в Qt?
Вот и получается что удалять их через delete чревато, так как не известно как они реализованы, и к чему это приведёт.

[BRE]

Вот и получается что удалять их через delete чревато, так как не известно как они реализованы, и к чему это приведёт.

Достаточно один раз разобраться и дальше не пытаться удалять объект из слота, который инициируется сигналом этого объекта.

IMHO. На самом деле если бы все было так плохо с delete, то Тролли уже давно перекрыли бы оператора delete для объекта QObject, что бы он имел такое же поведение как и deleteLater.

[igor_bogomolov]

Я понимаю, что я уже придираюсь, и что это ошибки проектирования. Просто на примере с QMovie это не очевидно.
Теперь и я разобрался, буду иметь в виду

Сообщение отредактировал igor_bogomolov - 25.9.2009, 20:30

[SABROG]

Из цикла обработки событий вызывается обработчик события таймера для объекта movie, он посылает сигнал frameChanged, это разворачивается в прямой вызов метода myslot2, из которого мы убиваем объект movie.

А можете мне объяснить подробней, я не разобрался? Вот мы запускаем таймер тут:

movie->start();

Он срабатывает при выходе из конструктора QLabel, когда заходим в цикл событий. При первом событии таймера movie удаляется, значит вместе с ним должен удалиться и таймер и краша быть не должно... В чем подводный камень?
---
А похоже понял. Внутренний вызов из метода QMovie метода myslot2 и возврат в уже не валидный объект.

Сообщение отредактировал SABROG - 25.9.2009, 20:53

[BRE]

Он срабатывает при выходе из конструктора QLabel, когда заходим в цикл событий. При первом событии таймера movie удаляется, значит вместе с ним должен удалиться и таймер и краша быть не должно... В чем подводный камень?

DirectConnectin - подразумевает прямое связывание, т.е. грубо говоря emit signal() разворачивается в функцию:

void signal()
{
    obj->slot();    
}

Из eventloop'а активируется таймер объекта movie, мы попадаем в метод _q_loadNextFrame() объекта movie (!), из него идет прямой вызов метода slot2, в котором мы убиваем объект movie. После этого начинается откат из метода slot2, должны вернуться в _q_loadNextFrame объекта movie и продолжить выполнение этого метода. А movie - убит. Приплыли.