so-5-5
so-5-5 copied to clipboard
eao197
[en/ru] Event-handlers formats for SObjectizer-5.6
There is a topic in development of SObjectizer-5.6 where some feedback from SObjectizer's users (or just watchers) are required. I described this topic in a post in SObjectizer's Google group: Event-handler formats in SObjectizer-5.6. Please share you option if you have a time/desire. As reply in the Google group or even here.
При разработке SObjectizer-5.6 возникла тема, по которой хотелось бы получить обратную связь от пользователей SObjectizer-а или просто интересующихся. Тема описана в SObjectizer-овской Google-группе: Форматы обработчиков сообщений в SObjectizer-5.6. Пожалуйста, поделитесь своими соображениями, если у вас найдется время и желание. В виде ответа в Google-группе или прямо здесь.
Я хоть и не давно испольюзую (точнее пытаюсь использовать) для side-projects, но по-мне так оба варианта равнозначны:
(1)
ret_value handler(mhood_t<Msg_Type>);
ret_value handler(const mhood_t<Msg_Type>&);
(2)
ret_value handler(Msg_Type);
ret_value handler(const Msg_Type &);
Вариант (1), правда, выглядет более общим для будущего расширения, в том смысле, что ещё можно SO-специфичную (или даже app-специфичную) служебную информацию прикрутить, например, конверт (Envelope), дату отправления/отправителя и т.п. Поэтому голосую за 1-й вариант.
@basiliscos Спасибо, что нашли возможность высказать свое мнение. В результате обсуждений решено было оставить оба варианта, т.к. они сейчас оба широко используются. И каждый из них удобен в разных ситуациях.
Удален только такой вариант:
ret_code handler();
который в SO-5.5 используется для обработчиков сигналов.
Понимаю, что это немного "некропостинг", но все же интересно, а какой тогда вообще смысл в сигналах? Если их использование теперь ничем не отличается от использования сообщений.
Отсылка сигналов "дешевле", т.к. в случае отсылки сообщения пользовательского типа, который не наследуется от message_t, все равно под капотом создается динамический объект, который все-таки производен от message_t. Даже если пользовательский тип пустой.
А вот при отсылке сигнала ничего подобного нет, в SObjectizer-е вместо сигналов идет доставка nullptr-а.
Поскольку динамическая аллокация -- это дорогая операция, то когда данные переноситься не должны, то дешевле отсылать сигналы.
PS. Хорошие вопросы не могут быть некропостингом :)
Правильно я понимаю, что метод, подписанный на сигнал, получит экземпляр mhood_t "внутри" которого nullptr?
До этого, активно используя синтаксис void handler();, я не задумывался об этом, считая, что при сигналах никакого mhood_t не существует.
В случае сигнала будет mhood_t внутри которого вообще ничего нет: https://github.com/Stiffstream/sobjectizer/blob/v.5.7.0.1/dev/so_5/mhood.hpp#L223-L231
Выходит именно этим обусловлена невозможность использовать короткую запись (ret_value handler(const Msg_Type &)) для сигналов.
С одной стороны данное изменение делает код более громоздким, с другой заставляет разобраться с тем, что на самом деле происходит получше. Не знаю как относиться к этому, так что-то просто приму как данность. :)
Спасибо за ответы!
Скорее это последствия эволюции SObjectizer-а. Начиная с 2002-го года :)
Первоначально все event-handler-ы принимали сообщения по указателю. И эти указатели могли быть нулевыми.
Затем захотелось упросить ситуации, когда указатель в принципе не должен был быть нулевым. Так появились обработчики, которые принимали сообщение по ссылке. Это все еще в SO-4 происходило.
Потом этот опыт перешел в SO-5. Но когда в SO-5 появились сигналы, то пришлось вводить дополнительные форматы обработчиков (т.е. ret_value handler()).
Но потом выяснилось, что обработчики такого формата не очень дружат с шаблонами. И появился mhood_t.
А потом пришел дворник и всех разогнал :) Т.е. стало понятно, что форматов ну очень уж много. И от обработчиков вида ret_value handler() отказались. Еще и потому, что после удаления синхронного взаимодействия из ядра SObjectizer-а в качестве ret_value мог быть только void.