Корректное удаление виджета Опции

[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 - убит. Приплыли.