[Qt] сигнал-слот

Возможно, пригодится QSignalSpy

А можно узнать зачем тебе это?

Обычно если хочется это знать, то архитектура косячная. Максимум должно хотеться узнать какой объект тебе сигнал послал, на это есть функция sender()

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

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

ОМГ

кому не нравится моя точка зрения, могут дать правильные ответ, если нет, не надо портить настроение другим

Единственный расово верный способ узнать, откуда вызвали тот или иной слот - прошерстить стек вызовов. В плюсах прямого пути для этого нет.

Всякие глобальные переменные в многопоточном окружении - ад

>Я бы тупо глобальную переменную создал и юзал ее, без заморочек всяких.
/me надавал по рукам pozitiffcat

>Есть способ узнать от какого сигнала был запущен слот (узнать внутри запущенного слота) или нет.
нету
если не секрет, дай пример кода и объясни зачем оно тебе.

>Всякие глобальные переменные в многопоточном окружении - ад

А если обернуть в thread-safe, прозрачно для пользователя?

Костыль конечно, но судя по вопросу у разрабатываемой софтины архитектура и так трещит по швам, так что одним косяком больше, одним меньше... Решение хоть лобовое, но очень простое - в этом его плюс. Главное не забыть это нормально задокументировать :)

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

Это да, либо спрятать в макросе. Мне почему-то показалось, ТС хочет свои некоторые избранные сигналы отслеживать.

а ты бы как сделал, быстро и без заморочек? Объясни раз умный, распиши...

> Я бы тупо глобальную переменную создал

Я бы тупо глобальную переменную

тупо глобальную переменную

тупо глобальную

глобальную

тупо

Выпороть.

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

а ты бы как сделал, быстро и без заморочек? Объясни раз умный, распиши...

твой способ тоже не быстрый и не без заморочек.

>А если обернуть в thread-safe, прозрачно для пользователя?
ради весьма сомнительной фичи можно сильно потерять в производительности.

сдается мне, что задачу ТС можно решить более элегантным способом.
крайний случай - дополнительный параметр, вариант получше - callback у sender-а, еще лучше - использовать один из поведенческих паттернов и передавать объект.
но на самом деле лучше её не решать! ибо это отять-таки следствие кривой архитектуры.

гого, ну объясни, как без лишних телодвижений быстро замутить

вы изобретаете такой велосипед.. вот вы хотите сделать красиво, скока времени ушло у вас уже? вы все ни как не решите как лучше.. кому нахрен такие работники нужны. Вот я со своим стилем написания за 3 месяца годовалую работу сделал, начальник мне не нарадуется.. а вы тут херней занимаетесь, институтники!

И вообще... есть же setProperty, перед эмитом просто дописать что-нить вроде setProperty(«lastSignal»,SIGNAL(blablabla(blablabla)); и его уже достать через sender()->property(«lastSignal»);

Скажи мне, где ты работаешь, я буду держаться от этого места по-дальше.

>ради весьма сомнительной фичи можно сильно потерять в производительности.

Фича не сомнительная, а весьма годная подпорка для костыля. Сигналы вызываются не так часто, чтобы думать о производительности - это должно быть очевидным. Может быть не так очевидно то, что глобальные пользовательские переменные - это по сути флаги, какие-то состояния, то есть опять имеем редкие случаи обращения. В лоб интенсивный обмен данными через них будет вести только крайне упоротый первокурсник.

>Вот я со своим стилем написания за 3 месяца годовалую работу сделал, начальник мне не нарадуется.. а вы тут херней занимаетесь, институтники!

Справедливости ради стоит отметить, что с таким стилем написания не особо стоит рассчитывать на создание масштабируемой системы, ее дальнейшай поддержка и развитие третьими лицами опять же под вопросом.

Институтники передают пламенный привет твоему шефу :)

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

Подожди. Через год начальник сменит свою точку зрения.

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

эээ. убивание мультитрэдовости - не повод думать о производительности?
когда используешь блокировки, алгоритм по сути перестает быть параллельным. тогда использование потоков вообще теряет смысл!
(разумеется, речь идет о самом худшем случае: блокировка устанавливается в начале трэда, сбрасывается - в конце)

>В лоб интенсивный обмен данными через них будет вести только крайне упоротый первокурсник.
тут согласен :)
просто я изначально рассматривал как раз худший случай) привычка

Как такого толстотролля не закопали ещё - непонятно )