Сигналы и конструкторы\деструкторы\область видимости

[Narsil]

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

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

Код:

void signal(QString);

Теперь предположим у нас есть такой код:

Код:

{
QString str(message);
emit signal(str);
}

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

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

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

[ритт]

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

[Narsil]

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

[Igors]

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

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

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

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

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

[Narsil]

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

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

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

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

Насколько я помню, Dendy неоднократно объяснял этот момент

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

[SASA]

Код:

{
QString str(message);
emit signal(str);
}

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

[Narsil]

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

[SASA]

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

[kibsoft]

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

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

[Alex Custov]

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

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

[Igors]

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

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