Back to General and Gameplay Programming

Very, very fast event library

Sneftel · 2007-09-11T05:02:10

When profiling some code I'd been working on recently, I was surprised and dismayed to see boost::signals functions floating to the top. For those of you who are unaware, boost::signals is a wonderfully useful signal/slot library which can be used alongside boost::bind for delegate-based event handling such as one sees in C#. It is robust, featureful, and flexible. It is also, I have learned, incredibly, terrifyingly slow. For a lot of people who use boost::signals this is fine because they call events very seldom. I was calling several events per frame per object, with predictable results. So I wrote my own. Slightly less flexible and featureful. It's optimized for how everyone tends to actually use events. And event invocation is fifteen to eighty times faster than boost::signals. The library relies upon Don Clugston's excellent FastDelegate library and upon the deliciously evil, horribly useful boost::preprocessor library. The former is included; the latter is not, so you'll need to have Boost installed and its headers available to the compiler. A basic usage guide is as follows: #include <event.h> #include <string> #include <iostream> class Subject { public: // events::Event is parameterized by the argument list passed to the event handlers. // I like to make events public and mutable. If you want you can hide them behind // mutators instead. mutable events::Event<std::string const&> NameChangedEvent; // I've decided not to make events invocable via operator(). It's too easy to // accidentally invoke an event in this way. void SetName(std::string const& name) { m_name = name; NameChangedEvent.Invoke(m_name); } private: std::string m_name; }; class Observer { public: Observer(Subject const& subject) : m_subject(subject) { // Registers the OnNameChanged function of this object as a listener, and // stores the resultant connection object in the listener's connection set. // This is all you need to do for the most common case, where you want the // connection to be broken when the Observer is destroyed. m_cs.Add(m_subject.NameChangedEvent.Register(*this, &Observer::OnNameChanged)); } private: // I like to make my event handler functions private, delegating to public functions // as necessary. void OnNameChanged(std::string const& newName) { std::cout << "The subject's name is now " << newName << "." << std::endl; } // The connection set is a utility class which manages connection lifetimes for // you. It's similar in functionality to boost::signals::trackable, but provides // slightly more flexibility over connection lifetimes. For the normal case, // you only need one connection set per listening object (no matter how many // things it listens to) and you never need to do anything with it except call Add(). events::ConnectionSet m_cs; Subject const& m_subject; }; int main() { Subject s; Observer o(s); s.SetName("Joe"); } This is beta-quality software, and its interface and implementation are both still in flux. It's intended primarily to get ideas flowing here on what form the ideal event library would take. Is this library too much or too little? Are there widely useful features it's missing? In particular, I'm interested to hear whether the ConnectionSet system is reasonable. download (ver 0.08) [Edited by - Sneftel on July 28, 2007 12:59:58 AM]

General and Gameplay Programming Programming

Started by Sneftel July 21, 2007 03:47 PM

53 comments, last by Iftah 16 years, 7 months ago

sipickles

240

September 03, 2007 11:59 AM

Since the connectionSet::Clear() function merely calls a std::vector::clear(), would it not be safe to iterate, copying all but erased connection?

SiCrane

11,840

September 03, 2007 03:06 PM

By reseting your connections I meant if you had a Connection d just doing d = Connection(). If you had two connections that refer to the same signal/slot combo, then do it to both of them. This obviously won't work if you're using a ConnetionSet (but I'm not a big fan of the ConnectionSet class if you couldn't tell from the rest of this thread).

Sneftel

1,788

Author

September 07, 2007 01:46 PM

Yeh, either keep the Connection around by itself and set it to an empty connection, or remove it from whatever container you're keeping it around in. ConnectionSet is primarily used as a detail class right now; there's no reason to use it if you need functionality it doesn't offer.

owl

376

September 07, 2007 01:54 PM

Quote:Original post by Promit
I'd like to take this time to suggest a promotion for SiCrane from Staff to Total Badass Developer.

I support the motion.

[size="2"]I like the Walrus best.

Iftah

413

September 11, 2007 05:02 AM

Thank you for the interesting article and great library!

I think Don Clugston's library could be made a little bit more portable (across gcc compilers) if he had used the gcc extension 6.6 to extract the function address from the member function pointer without any nasty structure and algorithm.
But his way is cooler [smile]

Very, very fast event library

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Very, very fast event library

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines