Согласен, пример синтетический. Я им хотел показать, что при выполнении контракта подписчиком все равно произойдет падение. Ответственность подписчика это, действительно, основа моей идеи.
Расскажете как у вас с копией реализуется кейс, когда объект отписывается от события при обработке события в другом объекте(пускай не напрямую как в моем синт. примере, а через какие-то вложенные обработки, или идет последовательный диспатчинг и тд)? Такое же вполне возможно и не может быть запрещено. Или, так на вскидку, слишком уж сложно контролируемо.
Давайте рассмотрим ситуацию с копией на примере, для лучшего понимания:
Есть 3 объекта A,B,C.
Объект А содержит Event<>.
Объект В содержит в себе объект C.
При создании объекта B создает объект С.
Затем объект B подписывает себя на объект Event объекта А.
Потом объект B подписывает объект С на событие А.
Объект В получает событие, отписывает объект С и удаляет объект С
Если будет копия, то отписка объекта С на копию никак не повлияет и после выхода из обработки в В будет вызван обработчик С, который уже умер, хотя выполнил свой контракт и отписался.
Я решил отказаться от этого для скорости - хеш посчитали 1 раз без виртуальных IsEqual и каста.
У меня вроде нет std::function
Согласен можно, но это будет сложный для восприятия код и я написал что такой вариант покажу в другой статье если будет интересно)
Действительно прям большие? По моим оценкам были мизерные, но может я и ошибаюсь. Хранение сырых указателей даст заметный прирост производительности?
Такова и была архитектурная идея моя. Ты отписываешься мгновенно, а подписываешься отложено. Это осознанное решение и я на этом сделал акцент. Копия вектора это оверхед, как мне кажется, недопустимый. Если RemoveHandler тягается в уничтожении объекта, а реально из Event он удален не будет и будет вызван в этой итерации будет UB согласны? Нельзя так просто взять и сделать копию.
Я понял вас. Да у меня не готовая EDA и не предлагает такую схему работы. Я понимаю event как "уведомление", тоесть задача "как уведомить кого-то о чем-то". Будет интересно почитать ваши замечания по реализации.
Для человека, который решил вынести свои идеи и свое творение на публику вы что-то слишком уж загадочны. Если это были внутренние закрытые разработки, то можно же так и сказать -- внутренние, закрытые. В общем, странное поведение.
Я не могу сказать не потому, что это секретная инфа, а потому что если у них названия и есть я их просто не знаю.
Что-то подобное мне знакомо. Я бы отнес бустовые сигналы к пункту 1. Это универсальный механизм на все случаи жизни да еще и с синхронизацией межпоточной за, что придется заплатить. По важности, что не устраивает: 1. Необходимость хранить connection для отсоединения - это то, что я не хотел делать обязательным. 2. Синтаксис - сигнатура функции с возможностью возвращать значение и требованием std::bind для функций-членов - универсально, но в EventSystem не нужно - синтаксис чище.
Это так на вскидку.
Signals универсальный под любые задачи, мой под ограниченную однопоточную архитектуру, простой и понятный.
Я использую эту версию(ну может немножко модифицированную уже) в production. RAII мне не нужно, так как принцип построения системы подразумевает контроль за лайфтаймом. Рекурсию только если спецом написать - ошибка проектирования. Без virtual это (спойлер) шаблоны и void*. Интерфейс остается прежним.
Для меня LLM типа ChatGPT очень, ну просто крайне, удобная база данных не более того. Очень помог мне с UE например - удобно структурирует и обобщает информацию. Но вот попросил я его нарисовать схему генератора управляемого напряжением и все тютю. Справочник да, реальный исполнитель чего либо - нет.
Ну может вы и правы. Я решил разрешить такую ситуацию)
Спасибо.
А как вы решали проблему hot отписки и уничтожения подписчика? Он останется в скопированном списке и вызовется.
Раз вы уверены в контроле над этим значит у вас очень четкая архитектура, документация и ревью. Круто конечно, но я на такое рассчитывать не могу)
Согласен, пример синтетический. Я им хотел показать, что при выполнении контракта подписчиком все равно произойдет падение.
Ответственность подписчика это, действительно, основа моей идеи.
Расскажете как у вас с копией реализуется кейс, когда объект отписывается от события при обработке события в другом объекте(пускай не напрямую как в моем синт. примере, а через какие-то вложенные обработки, или идет последовательный диспатчинг и тд)? Такое же вполне возможно и не может быть запрещено. Или, так на вскидку, слишком уж сложно контролируемо.
Давайте рассмотрим ситуацию с копией на примере, для лучшего понимания:
Есть 3 объекта A,B,C.
Объект А содержит Event<>.
Объект В содержит в себе объект C.
При создании объекта B создает объект С.
Затем объект B подписывает себя на объект Event объекта А.
Потом объект B подписывает объект С на событие А.
Объект В получает событие, отписывает объект С и удаляет объект С
Если будет копия, то отписка объекта С на копию никак не повлияет и после выхода из обработки в В будет вызван обработчик С, который уже умер, хотя выполнил свой контракт и отписался.
Спасибо за подробный коммент. По пунктам:
Я решил отказаться от этого для скорости - хеш посчитали 1 раз без виртуальных IsEqual и каста.
У меня вроде нет std::function
Согласен можно, но это будет сложный для восприятия код и я написал что такой вариант покажу в другой статье если будет интересно)
Действительно прям большие? По моим оценкам были мизерные, но может я и ошибаюсь. Хранение сырых указателей даст заметный прирост производительности?
Такова и была архитектурная идея моя. Ты отписываешься мгновенно, а подписываешься отложено. Это осознанное решение и я на этом сделал акцент. Копия вектора это оверхед, как мне кажется, недопустимый.
Если RemoveHandler тягается в уничтожении объекта, а реально из Event он удален не будет и будет вызван в этой итерации будет UB согласны? Нельзя так просто взять и сделать копию.
EventDispatcher подразумевает EventListener)
Я понял вас. Да у меня не готовая EDA и не предлагает такую схему работы. Я понимаю event как "уведомление", тоесть задача "как уведомить кого-то о чем-то".
Будет интересно почитать ваши замечания по реализации.
Я не могу сказать не потому, что это секретная инфа, а потому что если у них названия и есть я их просто не знаю.
Возможно вы понимаете что-то другое под понятием Event System?)
Я как раз не пытался реализовать signal slot как в qt или boost.
1. Все же интересно что, по вашему, тут неудачно?
2. Почему не подходит для "серьезной"(еще бы пояснить что вы под этим подразумеваете) разработки?
Возможно вы видите какие-то явные проблемы архитектуры, функционала, логические проблемы или проблемы производительности?
Всегда рад пообщаться)
У статьи стоит раздел и уровень сложности.
Очень странно читать "где картинки из программы", учитывая тему.
Что-то подобное мне знакомо. Я бы отнес бустовые сигналы к пункту 1. Это универсальный механизм на все случаи жизни да еще и с синхронизацией межпоточной за, что придется заплатить.
По важности, что не устраивает:
1. Необходимость хранить connection для отсоединения - это то, что я не хотел делать обязательным.
2. Синтаксис - сигнатура функции с возможностью возвращать значение и требованием std::bind для функций-членов - универсально, но в EventSystem не нужно - синтаксис чище.
Это так на вскидку.
Signals универсальный под любые задачи, мой под ограниченную однопоточную архитектуру, простой и понятный.
Предположить можете, но подтвердить это я не смогу.
Это те, с которыми я сталкивался в разных проектах. Если у них были названия, то я их не знаю)
Это можно да, но мелочь, всегда 2 файла каждый может сделать с ними что хочет)
Под С++17
Зачем? что-то не компилируется где-то?
Шанс 1 делить на 2 в 62 степени, вроде как-то так
Где чтение исполняемой памяти? я беру sizeof(MemberPtr) и по нему хеш составляю на случай если он не 8 байт, а 16.
Для игр - без исключений.
Я думал убрать в неймспейс какой-то. Но какой? Проще если тот, кто будет юзать сам обернет в неймспейс который ему нравится.
Тут я ваще не понял контекста вопроса
Я использую эту версию(ну может немножко модифицированную уже) в production. RAII мне не нужно, так как принцип построения системы подразумевает контроль за лайфтаймом. Рекурсию только если спецом написать - ошибка проектирования.
Без virtual это (спойлер) шаблоны и void*. Интерфейс остается прежним.
Идея была сделать легкое, под конкретные задачи и без кодогенерации.
Я и огласил вобщем-то) Все с чем сталкивался подпадает под 3 группы
Для меня LLM типа ChatGPT очень, ну просто крайне, удобная база данных не более того. Очень помог мне с UE например - удобно структурирует и обобщает информацию. Но вот попросил я его нарисовать схему генератора управляемого напряжением и все тютю.
Справочник да, реальный исполнитель чего либо - нет.