Nano Hash - криптовалюты, майнинг, программирование

C++: реализация системы событий для игрового движка

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

  • Объекты регистрируются в системе событий. Идентификатор уведомления и указатель на функцию обратного вызова передаются в качестве параметров каждой команды регистрации.
  • Объекты добавляют уведомления в систему событий. Идентификатор уведомления передается в качестве параметра каждого уведомления. Уведомления добавляются в очередь, содержащую все ожидающие уведомления.
  • Кроме того, система событий поддерживает запланированные уведомления. Идентификатор уведомления и будущее время выполнения передаются в качестве параметров каждого уведомления. Запланированные уведомления затем сохраняются в структуре данных («расписание»), содержащей запланированные уведомления в порядке будущего времени выполнения.
  • Объект-вызов дает системе событий команду обработать все уведомления, находящиеся в очереди. Система событий выбирает уведомления по порядку и вызывает функцию обратного вызова каждого объекта, который зарегистрировал себя с тем же идентификатором, что и текущее уведомление.
  • Объект-вызов дает системе событий команду обработать одно запланированное уведомление. Самое старое уведомление извлекается из расписания, и вызываются обратные вызовы всех объектов, зарегистрированных с одним и тем же идентификатором уведомления.

.

class Registration
{
public:
    void callback(void){ callback_(); }
    void setCallback((*callback)(void));
    void addToEventSystem(int ID, EventSystem &eventSystem);
private:
    void (*callback_)(void);
};

class EventSystem
{
public:
    void register(int ID, Registration* registration);
    void unRegister(int ID, Registration* registration);
    void addNotificationToQueue(int ID);
    void addNotificationToSchedule(int ID, int notificationTime);
    void processQueuedNotifications(void);
    void processNextScheduled(void);
    int getCurrentTime(void);
private:
    //placeholder types
    <list> notificationQueue;
    <binaryheap> notificationSchedule;
};

//------------Use:------------------
class ReceiverObject
{
public:
    void doStuff(void);
    void initialize(void){
        keyPressRegistration.setCallback(doStuff);
        //multiple registrations with different ID:s to same eventsystem possible
        keyPressRegistration.addToEventSystem(1234,eventSystem);
        keyPressRegistration.addToEventSystem(42,eventSystem);};
private:
    Registration keyPressRegistration;
};

int main()
{
    ReceiverObject receiverObject;
    EventSystem eventSystem;
    receiverObject.initialize();
    eventSystem.addNotificationToQueue(1234);
    eventSystem.processQueuedNotifications();
}

Однако я не совсем доволен этим решением, в основном потому, что система не позволяет легко передавать параметры получателям, и я скептически отношусь к обратным вызовам для функций-членов, является ли это хорошей практикой проектирования? А как насчет имен методов/классов/переменных, которые я придумал? Конструктивная критика, рекомендации и альтернативные подходы к проблеме приветствуются.

30.07.2013

  • Как насчет передачи std::function вместо простого указателя функции для ваших обратных вызовов? 30.07.2013
  • Действительно, они выглядят многообещающе. У меня просто нет ни опыта, ни знаний о С++ 11, но я посмотрю на новый стандарт. 30.07.2013

Ответы:


1

Это не имеет прямого отношения к вашему вопросу, но, говоря о дизайне, я бы не стал использовать глобальную систему уведомлений «для всего», поскольку в прошлом я видел плохие последствия. Вы просто склонны использовать тяжелую систему событий в местах, где один объект просто вызывает какой-то метод для другого объекта.

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

В любом случае вам будет сложно решить такие проблемы, как ожидание событий, ожидающих доставки уже убитым получателям.

30.07.2013

2

Лично я хотел бы иметь класс интерфейса EventHandler, который вы можете зарегистрировать, который будет иметь виртуальную функцию action (и, возможно, функцию для системы событий, чтобы сообщить классу, что он не зарегистрирован). Это полностью исключает обратные вызовы, а фактическая реализация EventHandler будет иметь возможность хранить другие данные (или ссылки на другие данные).

30.07.2013
  • Что ж, это имело бы больше смысла, чем моя текущая идея обратного вызова, но как насчет передачи параметров/данных? Конкретная реализация EventHandler по умолчанию должна знать класс получателя, что нормально, но если данные должны быть переданы, она также должна знать источник данных (вероятно, класс, который в первую очередь добавил событие в EventSystem ), что соединит их вместе. 30.07.2013
  • Не уверен, что вы имеете в виду - по моему мнению, класс получателя является экземпляром EventHandler. 30.07.2013
  • Я думал, что вы имеете в виду в своем первоначальном ответе, что Registration был сделан абстрактным базовым классом с именем EventHandler, а система обратного вызова в Registration/EventHandler была заменена виртуальной функцией, используемой производными классами, которые реализуют желаемый ответ, например вызов ReceiverObject->doStuff() . Мое первоначальное намерение состояло в том, чтобы объект-приемник владел экземпляром Registration, который обрабатывает взаимодействие между получателем и системой событий, поэтому я подумал из вашего ответа, что объект-приемник также будет владеть экземпляром EventHandler. 30.07.2013
  • Нет, сделайте RecieverObject производным типом от EventHandler и сохраните указатель или ссылку на него в вашем list of noitfications. 30.07.2013
  • Хорошо, но почему? Если бы каждый объект, способный получать события, был бы производным от EventHandler, то почти вся игра была бы производной от него. 30.07.2013
  • И? Наследование от базового класса — это нормально — этот класс просто добавит одну или две виртуальные функции. И с ним очень легко справиться. 30.07.2013

  • 3

    Для проблемы с параметрами - вы можете определить базовый класс ParamList, чьи производные являются шаблонными:

    class ParamList
    {
         const ID_Type& GetParamsType();
         ...
    };
    template <typename T>
    class Params: public ParamList
    {
         ...
    }
    

    теперь обратные вызовы будут типа: void (*Callback)(ParamList&); для безопасного использования вы можете добавить в класс Registration const ID_Type& GetExpectedParamsType(); и используйте его перед обратным вызовом

    то же самое касается уведомлений: void addNotificationToQueue(int ID, ParamList& param); void addNotificationToSchedule(int ID, ParamList& param,intnotificationTime);

    30.07.2013
    Новые материалы

    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..

    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..

    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..

    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..

    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..

    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..

    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..