Steve Lorimer wrote:
a way to create a generalised version of my "event" class, would be to have a single "event" class which has a boost::function to store a functor created using boost::bind on my object and member funciton.
This is what I gleaned from your previous post, yes: the idea that you can define a single boost::function signature for your queue items because all the binding really happens on the producer side.
I'd then use templatised helper functions for the general forms of using boost::bind.
Well, let me ask you this question. How important is it to you to hide use of boost::bind (or std::tr1::bind?) from your coders? My organization had a big discussion about this a couple years ago. Those who came to C++ from Java, and had no experience with (e.g.) Python, found function/bind upsetting and magical and wanted it safely buried beneath an API layer of our own. Those who have grown accustomed to the power of the Callable concept are used to boost::bind() expressions. We ultimately decided that reading boost::bind() expressions was less ugly than the code it would take to conceal them. The call to our API would resemble the boost::bind() call anyway. That said, boost::signals2::slot (in boost/signals2/slot.hpp) does wrap a bind() call in a way that you might adapt if this is what you want.