Russian Qt Forum

Доброго времени суток. Прошу прощения, елси данный вопрос поднимался, поиск не дал вразумительных результатов (по крайней мере по данному разделу)

Вот предположим, есть некоторый сигнал

Теперь предположим у нас есть такой код:
где message имеет тип char*, которая дальше удаляется. Но строка, которую мы хотим передать помещается в объект str.

Далее, предположим у нас многопоточное приложение, и данный сигнал связан со слотом другого потока. Насколько я понял, если мы используем Qt::AutoConnection при связывании, в многопоточном приложении объект str будет помещен в некоторую очередь (наверняка через копирующий конструктор), и управление вернется в приведенный код. После этого объект str выходит из области видимости, и вызывается деструктор.

И вот собственно вопрос. Что происходит дальше? Именно в реализации механизма сигнал-слот. Распишите подробно, как данный объект (помещенный в очередь) будет жить дальше в случае с одним связанным слотом, нуля связанных слотов или нескольких. Когда для данного объекта будут вызываться копирующие конструкторы, когда будет вызываться operator = и когда вызовется деструктор.

всё это можно найти в официальной документации.

Был бы очень благодарен за ссылку. Какие-то оф. доки я читал, но не наталкивался даже на отдалённые упоминания.
К тому же, оф. докам не задашь вопрос, если что-то будет непонятно\не до конца понятно.

Мне кажется проще и лучше посмотреть invokeMethod по исходникам - как минимум информация из первых рук

"В общих чертах" - совершенно верно. Конкретно - не следует надеяться на какие-то чудесные правила многопоточности которые сами все сделают  :)

Я понимаю (и уважаю) желание "докопаться" но для пользования оно совсем необязательно. Ваш пример: Вы послали str - значит он будет доставлен слоту. Конкретно в Вашем примере Вы послали по значению - здесь вообще вопросов нет. Послали по ссылке/указателю - значит при многопоточном использовании Вы должны иметь ввиду - поезд может уйти, слоту доставлена та копия/версия что посылалась. Насколько я помню, Dendy неоднократно объяснял этот момент

С invokeMethod у меня сразу не заладились отношения.

Дело в том, что моя задача разработать систему, которая будет работать очень длительное время без остановок. Поэтому утечки памяти (даже небольшие) очень нежелательны. Вот отсюда и желание докопаться до механизма реализации сигнал-слотов, ибо идея, конечно, привлекательная.

Приветствую любые ссылки по данному вопросу. Я просто не очень представляю как составить поисковой запрос, чтобы получить то, что я хочу.

В этом коде ничего не создаётся динамически. Если предположить, что в QString и реализации сигналов/слотов утечек нет, то этот код тоже не будет "протекать".

Ладно, тогда следующий вопрос. Есть ли разница с точки зрения Qt в пердаче параметров как "Classname" или как "Classname &"?

Это вопрос по C++,а не по Qt. Почитайте про способы передачи параметров в C++.

Есть. Почитай про Implicit Sharing в ассистенте. Когда передается копия(Classname) например QString, то неявно в Qt передается ссылка(для увеличения эффективности) и увеличивается счетчик ссылок на этот объект, а затем если в функции происходит изменение этого объекта, то счетчик ссылок уменьшается и создается копия объекта(в функции). Передача по ссылке(Classname &) происходит обычно, т.е. передается ссылка и при изменении в функции будет изменен тот объект, который передан(копия не будет создаваться). И никакого счетчика ссылок во втором случае нету.

Важно добавить, что это справедливо для типа соединения Qt::DirectConnection

Детальный разбор механизма сигнал/слот - дело хорошее, но как это связано с утечками? Они постоянно обнаруживаются, напр. в последний месяц-полтора их находили Dr_Behemot и Spectre. Однако от факта обнаружения до выявления причины - дистанция огромного размера (не говоря уже о фиксации). Обычно дело кончается ничем и (у)течка спокойно живет дальше  :) Заметим что сигнал/слот активно используется самим Qt и избавиться от этого нельзя. Да и нет никаких поводов считать сигнал/слот причиной утечек. Так что Ваш план не очень понятен.