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

Происходит.

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

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

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

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

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



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



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





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

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

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

Это что-же получается надо заводить какой-то флаг по пришествии 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

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

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

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

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

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

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

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

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

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

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