[Qt 4.5.0] QHttp и QProgressDialog, странное поведение Опции

[Kagami]

А меня, кстати, пару дней мучает вопрос: "Происходит ли вызов disconnect() для всех сигналов и слотов объекта при его удалении?"

[SABROG]

А меня, кстати, пару дней мучает вопрос: "Происходит ли вызов disconnect() для всех сигналов и слотов объекта при его удалении?"

Происходит.

A signal-slot connection is removed when either of the objects involved are destroyed.

Сигнал-слот соединения удаляются, когда любой из объектов разрушены.

[Kagami]

Попробуй переопределить

void QObject::disconnectNotify ( const char * signal ) [virtual protected]

и посмотреть, действительно это происходит

[SABROG]

и посмотреть, действительно ли это происходит.

Действительно происходит, но метод, который ты предложил об этом не сообщит, т.к. он вызывается только в методе QObject::disconnect(), а деструктор QObject::~OObject не использует метод disconnect(), он предпочитает сам пробежаться по списку и поудалять всё при этом никуда не сообщив.

Скорее всего сомнение закралось в тот момент, когда представилась следующая картина. Один объект постоянно живет и его сигналы подключены к массе другим объектам, которые то появляются, то умирают. Узнает ли объект о том, что какие-то объекты уничтожились и нужно ли разрывать с ними связь. Так вот в деструкторе каждого QObject'a разрывается связь как с приемниками (receivers), так и с передатчиками (senders). В последнем случае удаляющийся объект как лазутчик получает доступ к объекту, который шлет ему сигналы и удаляет себя из его списка. Типа как в qip "Удалить себя из списка контакта".

---
Сейчас еще одна проблема возникла, у QNetworkReply есть метод abort(), но это не слот и поэтому я никак не могу соединить кнопку cancel у QProgressDialog со слотом abort. Придется создавать свой собственный слот, т.к. наследоваться от QNetworkReply не хочется, да и бесполезно, ведь указатель на него генерит QNetworkAccessManager, а он ничего не знает о моем классе.
---
Блин, тролли жгут. Когда я задал вопрос в тех поддержку о том кто должен удалять указатель на QNetworkReply возвращаемый от QNetworkAccessManager::get(), то получил ответ - читай документацию. Я прочитал и там было написано:

Note: The slot is responsible for deleting the object at that poi

Дословный перевод гугла:

Примечание: слот отвечает за удаление объекта в этой точке.

На самом деле не совсем понятно, что эта фраза означает. Толи объект удалится сам по себе при выходе из слота, толи пользователь должен его удалить. Сегодня фразу в документации поправили:

After the request has finished, it is the responsibility of the user to delete the QNetworkReply object at an appropriate time.

После запроса закончил, это ложится на пользователя, чтобы удалить QNetworkReply объекта в надлежащее время.

Только теперь стало понятным, что указатель должен удалять сам пользователь. Будьте осторожны народ, а то memory leak схватите.

Сообщение отредактировал SABROG - 20.6.2009, 17:29

[SABROG]

Я в ступоре, сейчас тролли говорят, что это нормальное поведение

Это что-же получается надо заводить какой-то флаг по пришествии finished() (ни у QNetworkReply, ни у QNetworkRequest нет методов типа state(), которые могли бы нам сообщить о состоянии сокетов или еще чего-то) и потом его проверять в остальных слотах, если вдруг finished() прийдет раньше чем сигналы типа error(), readyRead(), updateProgress().

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

Всё пипец им, нашел \examples\network\downloadmanager\:

void DownloadManager::downloadFinished()
{
    progressBar.clear();
    output.close();

    if (currentDownload->error()) {
        // download failed
        fprintf(stderr, "Failed: %s\n", qPrintable(currentDownload->errorString()));
    } else {
        printf("Succeeded.\n");
        ++downloadedCount;
    }

    currentDownload->deleteLater();
    startNextDownload();
}

void DownloadManager::downloadReadyRead()
{
    output.write(currentDownload->readAll());
}

Тут если пришел finished(), то QNetworkReply удаляется несмотря на то, что может прийти сигнал readyRead после этого. Стало быть файлик скачается битым.

Сообщение отредактировал SABROG - 22.6.2009, 18:29

[SABROG]

Баг признали, правда тикет еще не приняли. Пока советуют такой вариант:

connect(reply, SIGNAL(finished()), this, SLOT(finished()), Qt::QueuedConnection);

И действительно так работает. Еще одно подтверждение тому, что QEventLoop вклинивается в порядок вызовов слотов. Сказали, что будут разбираться после полудня, но я не знаю какой часовой пояс у этого человека. Хотя нет, знаю 09:37:42

Сообщение отредактировал SABROG - 23.6.2009, 11:01

[Litkevich Yuriy]

а я что-то непонял насчёт этого варианта, разъясни

[SABROG]

а я что-то непонял насчёт этого варианта, разъясни

Если бы я сам до конца понимал. Тролли пока молчат.

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

[Litkevich Yuriy]

я пока вижу только то, что добавился признак соединения через очередь. На первый взгляд это-то и должно приводить к косякам, а не наоборот.

[BRE]

я пока вижу только то, что добавился признак соединения через очередь. На первый взгляд это-то и должно приводить к косякам, а не наоборот.

Бегло посмотрел исходники, по-моему, сигнал readyRead отсылается через очередь сообщений, а finished - директом. Поэтому, сначала приходит finished, а только после этого прокручивается цикл обработки сообщений и приходит последний readyRead.
Хотя я пока не сообрасил, как с этим соотноситься "выпрямление" ситуации при изменении порядка выполнения connect.

Сообщение отредактировал BRE - 24.6.2009, 8:11