Re: [boost] first steps to submitting - boost :: observers

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.