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 [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.