On 19/09/2016 10:53, Robert McInnis wrote:
On Sunday, September 18, 2016 6:50 AM, Bjorn Reese wrote:
What are the advantages of this library over Boost.Signals2 [1]?
Afaik, Signals2 is not meant to be associated with a single instance of a single object representing a particular event produced by that object.
I'm not sure I'm parsing that explanation correctly, but Signals2 is a generic thread-safe event-raising mechanism; it can thus be used to raise events from a single instance or static class-based, as desired. Typically the observee/publisher provides the event/signal, but other models can be possible with some finagling, if such is desired -- and it's fairly straightforward to build hybrid patterns with it such as subscribing to a container to indirectly subscribe to the container's contents (assuming that the container tracks insert/remove actions). It's also trivial to do things like give it a different mutex type, so you can have your atomic spinlock mutexes if you wish. (I usually do this myself.)
Observers are invoked while the mutex is locked, so observers cannot make calls on the subject.
Readers may read the value but updaters are restricted. Which is as it should be.
That's debatable, and imposes some limitations that can be irritating in practice. Signals2 does not have this restriction.