Войти
ПрограммированиеФорумОбщее

Простая система событий на С++11 (комментарии) (3 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
#30
23:10, 8 дек 2015

k-payl
> Не нравятся мне эти абстрактные event-системы. Непонятно что это за система
> такая и какая у нее ответственность. Я предпочитаю написать класс делегат

Так, собственно, моя система на базе делегатов и построена - std::function, или вы о чем-то другом?

#31
23:30, 8 дек 2015

0r@ngE
Я про то что моя система событий обычно ограничивается std::function(или, что одно и тоже, делегатом). Что бы не плодить непонятные абстракции:)

#32
0:04, 9 дек 2015

k-payl
> Я про то что моя система событий обычно ограничивается std::function(или, что
> одно и тоже, делегатом). Что бы не плодить непонятные абстракции:)

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

#33
0:02, 10 дек 2015

0r@ngE
на самом деле от этого указателя можно избавиться а в системе хранить по ключу ID+ptr

#34
0:35, 10 дек 2015

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

что бросается в глаза...
я возможно не прав, но в классической системе событий, могут быть сколь угодно по разному разделены понятия Наблюдатель и Наблюдаемый
в данной убер системе я или не вижу или не понимаю...
каким образом отделить одного наблюдателя от другого
вот есть два GameObject'а что если я хочу подписаться на события только одного из них?
я там увидел попытку замутить что то подобное только в передаче одним из параметров события рефа на levelHash
при этом опять же подобную фигню получат все подписчики, и они как то там уже должны принять решение их это объект или нет.
в общем и целом я не совсем понимаю профита от того что система событий singleton

и дальше уже встают вопросы... типа с какого фига в обсервере необходимы знания о слушателе
и signal slot тот же вопрос встает, может автор статьи что то перепутал?
в классическом обсервере наблюдаемый от наблюдателя отделен слоем полиморфизма
в сигнал слоте прослойка выполнена на основе делегатов (std::function условно)
какие знания о наблюдателе о чем вообще автор?

#35
1:16, 10 дек 2015

почитав код... я кажется понял...
автор все перепутал
в классических системах событий необходимы знания о наблюдаемом, а не о наблюдателе
т.е. наблюдатель должен знать на какие события он подписывается,
автор в статье же отделил наблюдателя от наблюдаемого прослойкой в виде event_traits
статически генерируемых... причем в целом и в частности там такой шаблонный говнокод... что ну его нафиг
автор начисто забыл что в С++ есть namespaceы, а про ADL он и вообще не слышал судя по всему

#define DECLARE_EVENT_TRAIT(eventTrait, ...)                                    \
    struct eventTrait {                                                         \
        typedef std::tuple<__VA_ARGS__> ParamsTuple;                            \
        typedef std::function<void(__VA_ARGS__)> DelegateType;                  \
        static const std::size_t numArgs = std::tuple_size<ParamsTuple>::value; \
        static const char * name() { return #eventTrait; }                      \
    };    

не?

а теперь давай зарегаем два одинаковых эвента, в разных namespace?

#36
1:20, 10 дек 2015

> result = hasher(traitName); // TODO: replace this with something platform-independent
http://en.cppreference.com/w/cpp/types/type_info/hash_code
?

#37
1:24, 10 дек 2015

а вот, что меня в конец добивает, это желание сначала смешать все в кучу, а потом героически решать появившиеся проблемы
абсолютно все проблемы решит вот такая мелоч

template<typename EventTrait>
class EventSystem {

а весь остальной говнокод можно тупо выкинуть, заменив unordered_map на list

#38
2:36, 10 дек 2015

А я ретроград, я люблю слушателей и интерфейсы. В основном из-за того, что тривиално отследить, кто какой интерфейс реализует. Моя любовь к делагатам закончилась в тот момент, когда мне нужно было добавить обрабоку ошибок в построенную на них систему (в которой был релизован только sunny day scenario). Я реально задолбался отслеживать все места, где добавлялись эти обработчики (там уровень индирекции достигал вроде 6).

#39
5:38, 10 дек 2015

0r@ngE
> Простая система событий на С++11
Неудобная система, как минимум по 3 причинам:
1. Перед удалением объекта требуется вручную отписывать все его функции, ранее подписанные на события
2. Нет возможности подписывать функции, которые возвращают значение (порой важно знать, обработал ли объект событие или нет, например в иерархии GUI объектов)
3. Много лишних сущностей, выделений памяти и синтаксического мусора

innuendo
> Ненавижу делегаты
Я бы удивился, если бы было наоборот. :)

#40
7:44, 10 дек 2015

cNoNim
> и дальше уже встают вопросы... типа с какого фига в обсервере необходимы знания
> о слушателе
> и signal slot тот же вопрос встает, может автор статьи что то перепутал?

Ну подпишите мне слот на сигнал не зная ничего об обеих сущностях

cNoNim
> а теперь давай зарегаем два одинаковых эвента, в разных namespace?

А зачем такое делать? У вас есть хидер с задекларированными ивентами - юзайте его.
Но даже если вас угораздило такое учудить - то компилятор даст по рукам, ибо уже есть такой ивент.

cNoNim
> ?

Могу ответить тем же знаком вопроса - что вы хотели спросить? Детализируйте вопрос пожалуйста.

Hybernaculum
> 1. Перед удалением объекта требуется вручную отписывать все его функции, ранее подписанные на события

Покажите мне систему в которой не надо этого делать

Hybernaculum
> 2. Нет возможности подписывать функции, которые возвращают значение (порой
> важно знать, обработал ли объект событие или нет, например в иерархии GUI
> объектов)

Да, ее нету. Ибо данная система писалась из расчета на асинхронность в будущем (+ возможную реализацию RPC поверх нее, именно для этого EventTrait хранит в себе ParamsTuple)

Hybernaculum
> 3. Много лишних сущностей, выделений памяти и синтаксического мусора

Будут конструктивные замечания к коду?  Ткните в ту часть что вам не нравится, обсудим.

#41
8:48, 10 дек 2015

0r@ngE

Повторно предлагаю сделать альтернативный вариант с слушателями

#42
12:52, 10 дек 2015

0r@ngE
> Будут конструктивные замечания к коду?
Я уже написал вам конструктивные замечания, а вот насколько вы конструктивно
приняли к сведению эти замечания, это уже другой вопрос.

> Покажите мне систему в которой не надо этого делать
То есть у вас даже нет представления о том, что такие системы существуют и как они реализованы?

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

#43
16:33, 10 дек 2015

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

На более-менее конструктивные я ответил. Как по вашему я должен отвечать на пункт "это все говнокод и мне не нравицца" ?  Я и так максимально сдержанно ответил.

Hybernaculum
> То есть у вас даже нет представления о том, что такие системы существуют и как они реализованы?

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

Hybernaculum
> Кривые отмазки не принимаются.

И что такого кривого в асинхронности? Еще раз повторою для тех кто не читал текст статьи - прелесть данного подхода в "бросил ивент и забыл".
Если вам надо получать ответ - это уже есть некий контракт между вызывателем и получателем, используйте другие подходы.

Странные люди на ГД.ру - если чье-то решение конкретно под его задачу не подходит - решение говно и вообще все убейтесь...

#44
17:44, 10 дек 2015

0r@ngE
> Понятно что это можно спрятать и делать неявно (как в Qt), но все равно это происходит.
Отписываться от событий "вручную" в каждом классе тупо неудобно и даже потенциально опасно, если учесть т.н. человеческий фактор.

> И что такого кривого в асинхронности?
Не надо прикрывать "асинхронностью" свою некомпетентность.

> прелесть данного подхода в "бросил ивент и забыл"
В вашей текущей реализации системы эвентов асинхронностью даже и не пахнет,
raise_event не возвращает управление пока не раздаст евенты всем подписчикам.

> это все говнокод и мне не нравицца
Это ваши слова.

> Если вам надо получать ответ - это уже есть некий контракт между вызывателем и получателем
В большинстве реальных задач желательно иметь возможность получать ответ от подписчика.

Страницы: 1 2 3 4 5 6 7 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.