Re: [boost] Interest in non-intrusive signal/slot lib?

Subject: Re: [boost] Interest in non-intrusive signal/slot lib?
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2015-05-12 06:23:17

On Tue, May 12, 2015 at 12:49 AM, Gavin Lambert <gavinl_at_[hidden]>
wrote:

> On 12/05/2015 14:25, Emil Dotchevski wrote:
>
>> Documentation and source code released under the Boost license can be
>> found
>> here: http://www.revergestudios.com/boost-synapse/.
>>
>
> This looks interesting, though I've only looked at the docs so far.
>
> The incomplete struct return type seems a bit peculiar.  I assume it was
> required for some implementation-based reason?  It might be a blocker if
> you later do want to add support for signals with return values.
>

In my opinion the main use case for such a lib is when the caller doesn't
care if there are 0, 1 or many connected functions; and allowing return
values makes zero/many quite tricky to deal with. On the other hand,
passing a reference or a pointer to emit<> to return/accumulate values from
any number of connected functions fits nicely. So I think this is the best
compromise between expressive power and simplicity.

> The docs for connect seem to state that when either weak_ptr expires it is
> considered a disconnection but meta::disconnected is not called.  If this
> is intended it seems a little confusing.  Perhaps a different word should
> be used ("inactive", maybe?).
>

Yes, thank you for this comment. You're correct, meta::disconnected is
called when the connection object expires, not when the emitter or the
target expire.

> It seems like a non-uniformity to have connect() and other methods take a
> weak_ptr<emitter> while emit() and emitter_connection_count() take a bare
> pointer.  Looking at the header docs you do have an emit_weak() as well but
> maybe these should be the other way around?  (I assume current emit() is a
> convenience so that you can emit(this, ...) without needing
> shared_from_this() or similar.)
>

You're right, this allows emitting from a member function (this), but also
when working with 3rd party APIs (which is the most important use case for
me) it's quite common that you don't have weak/shared_ptr when calling
emit. For example, in
http://www.revergestudios.com/boost-synapse/using_Boost_Synapse_to_handle_events_from_an_OS_message_pump.html
emit is called directly with the HWND object; at that point there's no way
to get your hands on a weak_ptr. :)

Another consideration is that emit guarantees that the connected functions
are called (assuming the target weak_ptr hasn't expired). This guarantee is
quite useful sometimes.

So actually I consider emit_weak just a convenience function, syntactic
sugar for

if( shared_ptr<void const> sp=wp.lock() )
    emit<signal>(sp.get(),....);

> In the docs for translate(), I assume the Effects code:
>
>
> connect<OriginalSignal>(original_emitter,bind(&emit<TranslatedSignal>,_1,_2,...))
> was intended to be this instead:
>
>
> connect<OriginalSignal>(original_emitter,bind(&emit<TranslatedSignal>,translated_emitter,_1,_2,...))
>

Yes, thank you.

> The logging system example doesn't seem to include a way to actually
> generate log messages, unless you're expecting callers to just
> emit(severity(n), string) directly, which seems like a leaking abstraction.
>

Well, sure. The point of the example is to illustrate the use of connect
and translate, most definitely it isn't a complete logging system.

Thanks!
Emil