On 9/26/2016 7:25 PM, Emil Dotchevski wrote:

On Mon, Sep 26, 2016 at 3:27 PM, Edward Diener wrote:

...

On 9/26/2016 3:46 PM, Emil Dotchevski wrote:

...

(Synapse is not part of Boost. I appreciate feedback as well as looking for someone willing to volunteer as review manager when Synapse is submitted for formal review.)

I am willing to be the review manager for Synapse.

I think highly of Synapse and feel that you can ask that it be put on the review queue, even if you are still adding some features as you specify below.

Sounds good. As for features, I prefer to have actual use cases before new features are implemented. Until this point the only thing that I personally had been missing was the ability to communicate with signals across different threads, which I have now implemented.

OK. I think you can ask that Synapse go on the review queue and have a date set for review. I don't think you should have to wait for feedback and use cases which might introduce changes to do that. Of course it is up to you if you want to wait for further input.

On Mon, Sep 26, 2016 at 4:40 PM, Rene Rivera wrote:

On Mon, Sep 26, 2016 at 2:46 PM, Emil Dotchevski

...

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 https://github.com/zajo/boost-synapse/blob/master/include/boost/synapse/emit..., 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 thread_local_queue.cpp.

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. Thanks, Emil