patterncppMinor
Custom event handling system
Viewed 0 times
customsystemhandlingevent
Problem
I'm relatively new to C++ (learned it years ago, but never used it much until now), and I needed an exercise to get a better handle on the language. I also needed a good way of handling events, and while there are plenty of libraries that have good event systems, I didn't like the client code for any of them. It felt unintuitive and like the listeners were having to do a lot more than just "listen." So I decided to try my hand at making my own, with pretty specific client code in mind as a goal.
There's obviously some flaws in the code still, and some things that I'm not sure about (how to apply the Law of Three to the Listener class?), but overall the code works exactly how I wanted it to, so I'm pretty satisfied. Since it's my first real project in C++ though, I'd really love any input and critique I could get on it though.
The Requirements
First and foremost, I wanted the system to be able to have callbacks of any type. Lambdas (with or without delegating to a member function), free functions, static functions, or member functions bound with std::bind. And I didn't want the listener to have to specify what kind of callback they were registering, or the event dispatcher to have to have any knowledge of what type of callback it was. I wanted the system to work exactly the same regardless of the kind of callback.
This introduced the next requirement. Lifetime handling, and the problems that came with passing delegates because of it. The undefined behavior from having a delegate get called for a deleted object would be a nightmare. So the listeners needed to be automatically disconnected from the event when they were destroyed, but be able to disconnect at a specific time if needed. And I didn't want them to have to worry about whether the object they had previously registered to was destroyed already, before disconnecting from it.
Event dispatchers needed to be able to have as many events as needed, without having to create a new event class extending from an a
There's obviously some flaws in the code still, and some things that I'm not sure about (how to apply the Law of Three to the Listener class?), but overall the code works exactly how I wanted it to, so I'm pretty satisfied. Since it's my first real project in C++ though, I'd really love any input and critique I could get on it though.
The Requirements
First and foremost, I wanted the system to be able to have callbacks of any type. Lambdas (with or without delegating to a member function), free functions, static functions, or member functions bound with std::bind. And I didn't want the listener to have to specify what kind of callback they were registering, or the event dispatcher to have to have any knowledge of what type of callback it was. I wanted the system to work exactly the same regardless of the kind of callback.
This introduced the next requirement. Lifetime handling, and the problems that came with passing delegates because of it. The undefined behavior from having a delegate get called for a deleted object would be a nightmare. So the listeners needed to be automatically disconnected from the event when they were destroyed, but be able to disconnect at a specific time if needed. And I didn't want them to have to worry about whether the object they had previously registered to was destroyed already, before disconnecting from it.
Event dispatchers needed to be able to have as many events as needed, without having to create a new event class extending from an a
Solution
If you have a class where it doesn't semantically make any sense for it to be copied (or moved), you can tell the compiler not to generate these constructors (or assignment operator overloads) by marking them as
So e.g.
= delete; in the class body. So e.g.
Listener::Listener(Listener& other) = delete;Context
StackExchange Code Review Q#143757, answer score: 3
Revisions (0)
No revisions yet.