Boost logo

Boost :

Subject: Re: [boost] (Boost) Synapse update
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2016-09-26 20:49:06

On Mon, Sep 26, 2016 at 4:40 PM, Rene Rivera <grafikrobot_at_[hidden]> wrote:

> On Mon, Sep 26, 2016 at 2:46 PM, Emil Dotchevski <emildotchevski_at_[hidden]
> >
> wrote:
> > Synapse is a signal-programming library similar to the Qt signal/slot
> > system and Boost Signals 2. The difference is that Synapse is
> > non-intrusive: any object of any static type whatsoever can serve as an
> > emitter.
> I'm all for alternatives in this area.. And because I happen to have needed
> to implement a quick and dirty signal class for a use case I have. So
> perhaps you can help me out in answering some questions (that I didn't see
> answered immediately in the docs)..
> What are the dependencies of the library?

>From Boost, it uses shared_ptr, weak_ptr, function. It can easily be
configured to use their standard equivalents.

Currently it also needs a relatively modern C++ compiler, since it depends
on thread-safe initialization of local static objects and uses
thread_local, lambda, <thread>, <atomic>. I'm open to workarounds if it is
deemed important to support older compilers.

> You mention ignoring the return value of connected functions, aka slots.
> What if I need to not ignore those return values and do something special?
> In my use case I need to short circuit the dispatch on true (bool) returns.
> Can I alter the dispatching?

If you just want to stop the dispatch, currently the only way to do this is
to throw an exception. Perhaps it does make sense to allow for boolean
returns, and maybe add an option to stop the emit loop early.

In other cases (that is, if you don't need to "short circuit" the dispatch
but you still want to propagate a return value), the solution is to add an
extra parameter passed by reference or by pointer.

> How lightweight is the resulting code? In my use case I prefer less code &
> lower memory use, for example I look for opportunities to use small-object
> / embedded-object.

The library does use templates and depending on the number of the different
signals you emit more code will be generated, but this should be minimal:
static types are erased as soon as possible, all of the machinery is
entirely contained in cpp files. I suspect that almost all of the template
bloat would come from,
look at the args_binder specializations.

Other than that, Synapse is a very small library and it is very modular. If
you only need to connect/emit signals, you just have to link connect.cpp
which is ~400 lines. If you call block(), you need to link block.cpp, which
is another ~200 lines. If you want interthread communication, you also need
to link thread_local_queue.cpp which is ~300 lines.

> I don't need multi-thread safety at all. Is your code flexible enough to
> remove that safety code?

The library isn't exception-safe in the traditional sense, all connections
are thread-local so there is no thread-safety overhead. And if you don't
need interthread communication, just link interthread_stub.cpp instead of

> And if you are wondering.. My use case is implementing a web application
> client front-end in C++ by compiling with emscripten, with possibly other
> non-web client UIs with shared code base. Which means I'm implementing an
> abstract UI and application system to deal with this.

I think Synapse is a good match for this, it is specifically designed to
freely cross API boundaries. The original motivation for Synapse was to let
me seamlessly integrate my own, Qt-independent code into Qt applications
without requiring MOCing or any dependencies on Qt.


Boost list run by bdawes at, gregod at, cpdaniel at, john at