Event Dispatcher

Getting trapped by looking at other implementations. Looks like people roll their own instead of relying on a library.

https://codereview.stackexchange.com/questions/98564/event-listener-implementation https://codereview.stackexchange.com/questions/245219/java-like-listeners-in-c https://codereview.stackexchange.com/questions/259525/c-generic-callback-class-with-removable-listeners-by-unique-id

First of all, cool that there’s a Stack Exchange for Code Review.

Second, I’ve lots to learn,

E.g., std::make_shared to initialize a resource that will be used outside of the current scope (I think?) and std::shared_ptr which is an older and slightly less performant version of the same, I believe? One problem noted about make_shared is that it allocates the control block (tracking information for the pointer) and the actual object being referenced in the same block. This means that a std::weak_ptr can prevent the block from being deallocated… apparently. Still haven’t quite wrapped my head around this. I haven’t heard of any of those before.

Third, do I even need to use an event listener model? Theoretically the simulation could have other classes listening for changes to it. The only one I have right now is the simulation renderer. I guess pretty soon I will probably have charts to report on what happened in the sim over time.

Simulation will have loads of different events, reckon. So maybe I can just register simulation listeners and consumers can filter by event type for now? It means lots of callbacks being invoked for things that don’t care about it but it would be simpler for now.

Okay, I’m’a just implement the listeners for boids in the same way that I implemented food sources. I can factor it out later as needed.

Now that I have Eigen::Vector2f I should use those to represent everything in the simulation. Use sf::Vector2d only for the rendering layer.

• Factor out sf::Keyboard code from Simulation class, too.

That’s pretty cool that Eigen::Vector2f::x() and y() return the address of the value so I can actually assign values to it like:

vec.x() += 5;

I did not think that would work and when it did work, I realized the return type is the address/reference, not the value. Cool beans.