замечания по использованию технологии сигнал/слот

Картинка для общего примерного представления :

фотка 1

Теперь о главном - о практических нюансах .

Сигнал выпускается в коде командой emit. Но на самом деле это больше похоже не на сигнал , а на вызов обычной функции , так как при вызове emit пока все слоты не будут выполнены (кстати в непредсказуемом порядке) , то далее выполнение кода после emit не происходит.

Правда есть исключение - это queued connections.

Чтобы дождаться окончания выполнение асинхронных команд и НЕ подвешивать обработчик событий часто используют такую конcтрукцию:

QEventLoop loop;
QNetworkReply *reply = qnam.post(request , ba);
connect(reply, SIGNAL(finished()),&loop, SLOT(quit()));
loop.exec();

Это пример выполнения http запроса к серверу. Пока запрос не отработает , то есть не придет сигнал finished от QNetworkReply , код далее (чем loop.exec();) выполняться не будет.

Минус технологии сигнал/слот в том , что если что-то поменять , то надо очищать проект и делать заново qmake и полную пересборку проекта.

Неоспоримым преимуществом технологии является возможность где угодно делать вызовы сигналов emit и не беспокоится связан с ними какой-нибудь слот (слоты) или нет... Это реально просто удобно.

Именно так и поступали разработчики Qt при создании своей библиотеки, пихали везде emit-ты и вы могли их соединять со своими слотами в своих объектах , а могли и не соединять (и даже вообще могли не подозревать о их существовании).

Слоты - возвращаемые значения

Как известно слоты не возвращают значений и используются как указатели на фукции (void *) , но это когда они вызываются как слоты.

Когда их вызывают как напрямую , то слоты прекрасно возвращаю значения. И это есть гут.

Еще замечено , что на перепутанные большие / маленькие буквы в названиях слотов в конструкции connect(..) компилятор не ругается.