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

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

Страницы: 1 2 3 4 58 Следующая »
#30
16:38, 8 дек. 2015

0r@ngE
> Получается на каждый ивент нужно добавлять в класс новый член-обсервер, который
> будет реагировать на событие?

Можно кастомизировать старые члены

#31
17:33, 8 дек. 2015

innuendo
> Можно кастомизировать старые члены
Ну их в любом случае придется добавлять.

В моем варианте внедрений в класс таки минимальны.

ЗЫ. Я рад что мы таки к конструктиву перешли ;)

#32
22:14, 8 дек. 2015

Не нравятся мне эти абстрактные event-системы. Непонятно что это за система такая и какая у нее ответственность. Я предпочитаю написать класс делегат(привет C#). И тогда сразу понятно что это такое.
Delegate.h:

template<typename... Args>
class DelegateTemplate
{
  typedef void(*fp)(Args...);
  std::vector<fp> _functions;

public:

  void Add(fp func)
  {
    _functions.push_back(func);
  }

  void Invoke(const Args&... args)
  {
    for (auto func : _functions)
      func(args...);
  }
};
/* Специализации делегата для конретных функций */
typedef DelegateTemplate<> Delegate;
//...
Пример использования:
#include "Delegate.h"
void event_handler1()
{
}

void event_handler2()
{
}

void main()
{
  Delegate d;

  d.Add(event_handler1);
  d.Add(event_handler2);

  d.Invoke();  // Вызовет event_handler1(), event_handler()
}
А так спасибо за статью! Наконец-то вдохнул свежего воздуха.

#33
22:27, 8 дек. 2015

k-payl
> Я предпочитаю написать класс делегат(привет C#)

Ненавижу делегаты!

#34
23:10, 8 дек. 2015

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

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

#35
23:30, 8 дек. 2015

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

#36
0:04, 9 дек. 2015

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

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

#37
0:02, 10 дек. 2015

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

#38
0:35, 10 дек. 2015
Я вот не хотел влазить в эту тему... так как что бы досконально влезть нужно все разобрать и все понять, но...

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

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

#39
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?

#40
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
?

#41
1:24, 10 дек. 2015

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

template<typename EventTrait>
class EventSystem {
а весь остальной говнокод можно тупо выкинуть, заменив unordered_map на list
#42
2:36, 10 дек. 2015

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

#43
5:38, 10 дек. 2015

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

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

#44
7:44, 10 дек. 2015

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

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

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

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

cNoNim
> ?

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

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

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

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

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

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

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

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

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