Слоты Qt не вызываются в режиме релиза, и я виню QSharedPointer - PullRequest
Новая
       37

Слоты Qt не вызываются в режиме релиза, и я виню QSharedPointer

0 голосов
/ 28 февраля 2020

У меня проблема с механизмом слота сигнала, возможно, это проблема с QSharedPointer, так как интеллектуальные указатели являются новыми для меня.

Небольшое объяснение контекста: TCPAssociation является дочерним классом LANAssociation. TCPClient является дочерним классом для LANClient. LANClient имеет защищенную QSharedPointer<LANAssociation> connection переменную, TCPClient имеет личную QSharedPointer<TCPAssociation> conn; оба указывают на один и тот же объект, создаваемый в переопределенной чисто виртуальной функции, показанной ниже: 

void TCPClient::startNewConnection(const QHostAddress &address)
{
    conn.clear();
    connection.clear();

    conn = QSharedPointer<TCPAssociation>(new TCPAssociation(address, port, QString("Client %1").arg(hostId())));
    Q_ASSERT(conn);

    Q_ASSERT(connect(conn.data(), &LANAssociation::started, this, &LANClient::assoc_started, Qt::UniqueConnection));

    connection = conn.staticCast<LANAssociation>();
    Q_ASSERT(connection);
    conn->start();
    //TCPAssociation::start() { doStuff(); emit started(); }
}

Код работает на Windows 10 в режиме отладки просто отлично. В режиме разблокировки Linux, LANClient::assoc_started никогда не вызывается.

Теперь я запустил свое серверное приложение (функция выше из клиентского приложения) в выпуске на Windows, и я вижу, что другой слот не вызывается в релизе, но прекрасно работает в отладке: 

void ThreadController::init(ThreadWorker *worker)
{
    worker->moveToThread(&workerThread);

    Q_ASSERT(connect(&workerThread, &QThread::finished, worker, &QObject::deleteLater, Qt::UniqueConnection));
    Q_ASSERT(connect(this, &ThreadController::operate, worker, &ThreadWorker::doWork, Qt::UniqueConnection));
    Q_ASSERT(connect(worker, &ThreadWorker::finished, this, &ThreadController::finished, Qt::BlockingQueuedConnection));
    doConnects(worker);

    workerThread.start();
}

*worker указывает на дочерний класс ThreadWorker. ThreadWorker::doWork() - это виртуальная функция. Это было вызвано в отладке, а не в выпуске. Я исправил это, сделав doWork() чисто виртуальным - теперь он вызывается как в отладке, так и в выпуске.

У меня также есть проблема с QTcpSocket и QUdpSocket объектами, не излучающими connected() или readyRead(). Теперь я понимаю, что это, вероятно, потому что я использую QSharedPointer<QAbstractSocket> для управления ими, но:

  1. почему разница между отладкой и выпуском? как это сделать правильно?

  2. Должен ли я прекратить использование наследования или общих указателей?

  3. почему TCPAssociation::started() не выводится? LANClient::assoc_started также не является виртуальной функцией.

1 Ответ

1 голос
/ 28 февраля 2020

Выражение внутри макроса Q_ASSERT не будет оцениваться в конфигурациях без отладочной сборки:

Q_ASSERT() полезно для тестирования до и после условий во время разработки. Он ничего не делает, если во время компиляции было определено QT_NO_DEBUG.

https://doc.qt.io/qt-5/qtglobal.html#Q_ASSERT

...