Синхронное обращение через сигнал слоты и возврат результата расчета после emit

[Denjs]

А вот как удалять созданный экземпляр t_returnSyncObject ? ... Какие есть мнения?

сам удалится сборщиком мусора) почему не?

или с сигналом пересылать QPointer<returnSyncObject> для безопасности, а в конструкторе returnSyncObject сделать deleterLater?
все равно объекту не нужно жить дольше чем работает функция в которой он создан.

[BRE]

Вспомните - с чего данная нить разговора началась?)

Я помню.

Если твой класс является наследником от QThread, то sleep будет доступен для всех его методов.

[Igors]

или с сигналом пересылать QPointer<returnSyncObject> для безопасности, а в конструкторе returnSyncObject сделать deleterLater?
все равно объекту не нужно жить дольше чем работает функция в которой он создан.

Не дождались ответа - кончился таймаут. Удалили объект и вышли. Слот проснулся, долбит удаленный объект. Ваши действия?

Edit: еще одно соображение: если вышли по таймауту, то по-хорошему слот не должен выполнять действий, т.к. поезд ушел.

[Denjs]

Не дождались ответа - кончился таймаут. Удалили объект и вышли. Слот проснулся, долбит удаленный объект. Ваши действия?

эээээ....
"долбит" удаленный объект? простите за нескромный вопрос - "кто кого куда"?))))
"слот проснулся" - т.е. наконец до него был доставлен сигнал?

приемный класс никого не "долбит". Если Pointer<returnSyncObject> выдал что объект удален - то извините. Поздно. Никаких действий.

Это если с QPointer. Если с простыми ссылками - то объект не должен быть удален пока на него есть ссылки. И собственно приемный объект.

А собственно какие проблемы если ничго не делать?

[ритт]

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

[Igors]

"слот проснулся" - т.е. наконец до него был доставлен сигнал?

Да

А собственно какие проблемы если ничго не делать?

Если объект не удалять - течет память. Если удалять - обработчик получает невалидный указатель.

приемный класс никого не "долбит". Если Pointer<returnSyncObject> выдал что объект удален - то извините. Поздно. Никаких действий.
Это если с QPointer.

А когда выдал? Слот получает сигнал и начинает его обрабатывать. В этот момент у посылающего кончился таймаут - и объект удален. Тогда получается нужен QSharedPointer, хотя лучше держать информацию об отмене в самом объекте.

Если с простыми ссылками - то объект не должен быть удален пока на него есть ссылки. И собственно приемный объект.

Это понятно но Вы уж пожалуйста оформите все как положено, ведь это "кладовая готовых решений".

[Denjs]

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

он требует знания о том, то тебя вызвал и его методах.
Т.е. вы не "портите сигналтуры",  -  вы "портите методы класса")))

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

[ритт]

он требует знания о том, то тебя вызвал и его методах.
Т.е. вы не "портите сигналтуры",  -  вы "портите методы класса")))

ась? это вообще о чём было? зачем знать апи вызывающего? при чём тут методы класса и их порча?

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

какому-такому наименованию?
что за объект на другом конце и зачем нужна ссылка на него? если это про объект, испустивший сигнал, то `sender()` в помощь.

короче, них не понял я пред.мессага...