Использование std:: function и std:: bind для хранения обратного вызова и удаления объектов.

мне нравится отделять моего слушателя / вещателя от реализации слушателя.

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

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

using token = std::shared_ptr<void>;

template<class...Args>
struct broadcaster {
  using target = std::function<void(Args...)>;
  using wp_target = std::weak_ptr<target>;
  using sp_target = std::shared_ptr<target>;
  static sp_target wrap_target( target t ) {
    return std::make_shared<target>(std::move(t));
  };

  token start_to_listen( target f ) {
    auto t = wrap_target(std::move(f));
    targets.push_back(t);
    return t;
  }
  void broadcast( Args... args ) {
    targets.erase(
      std::remove_if( targets.begin(), targets.end(),
        [&]( wp_target t )->bool { return t.lock(); }
      ),
      targets.end()
    );
    auto targets_copy = targets; // in case targets is modified by listeners
    for (auto wp : targets_copy) {
      if (auto sp = wp.lock()) {
        (*sp)(args...);
      }
    }
  }
  std::vector<wp_target> targets;
};

это заставляет людей, которые регистрируют слушателей держать std::shared_ptr<void> вокруг.

мы можем даже сделать его более причудливым, где уничтожение последнего shared_ptr<void> фактически немедленно удаляет слушателя из списка. Но вышеупомянутое ленивое снятие с регистрации, кажется, работает достаточно хорошо в моем опыте, и относительно легко сделать его многопоточным. (одна серьезная проблема заключается в том, что происходит, когда широковещательное событие удаляет или добавляет вещи в список слушателей: адаптация вышеизложенного для его работы приятна и проста с правилом, что слушатели, добавленные при трансляции, не получают трансляция, и слушатели, удаленные во время трансляции, не получают трансляцию. Слушатели удалены по совместительству во время трансляции можно получить трансляцию в большинстве моих реализаций... Это становится дорогим, чтобы избежать.)

вместо этого мы могли бы разделить его по-другому. Слушатель может пройти std::function и a std::weak_ptr отдельно к вещателю, который хранит оба и только вызывает std::function Если std::weak_ptr действителен.

Мне нравится подход якка. Вот обновленная версия, которая исправляет несколько проблем компиляции (например, не может назвать функцию "register"). Он также добавляет метод rm_callback для клиентов, чтобы легко удалить их регистрацию, не заставляя их регистрационный маркер выходить за рамки или знать внутренние. Мне не нравилось сканировать список каждый раз, когда событие транслировалось, поэтому я добавил deleter на общий указатель, который выполняет задачу очистки. Все новые ошибки или недостатки-мои. Этот Alert reader должен знать о проблемах с потоками при изменении списка во время трансляции...

using token = std::shared_ptr<void>;
template<class...Args>
struct broadcaster {
    using target = std::function<void(Args...)>;
    using wp_target = std::weak_ptr<target>;
    using sp_target = std::shared_ptr<target>;

    token add_callback(target f) {
        sp_target t(new target(std::move(f)), [&](target*obj) { delete obj; cleanup(); });
        targets.push_back(t);
        return t;
    }

    static void rm_callback(token& t)
    {
        t.reset();
    }

    void cleanup()
    {
        targets.erase(
            std::remove_if(targets.begin(), targets.end(),
                [](wp_target t) { return t.expired(); }
            ),
            targets.end()
        );
    }

    void broadcast(Args... args) {
        for (auto wp : targets) {
            if (auto sp = wp.lock()) {
                (*sp)(args...);
            }
        }
    }

    std::vector<wp_target> targets;
};

// declare event taking a string arg
broadcaster<std::string> myEvent;