Subject: Re: [boost] first steps to submitting - boost :: observers
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-09-18 21:54:28
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 ?
> 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
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk