On Tue, May 12, 2015 at 12:49 AM, Gavin Lambert
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_ev... 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