On Sun, Dec 4, 2016 at 4:52 PM, Klemens Morgenstern < klemens.morgenstern@gmx.net> wrote:
I suppose if it is elaborate enough you'd rediscover Synapse, but with a different low level machinery, though I suspect that both libraries contain incompatible intricacies which make sense in the different approaches they take, since non-intrusiveness (in the way Synapse is non-intrusive) was not a design goal of Signals2. That may be true; there are lots of problems, which look somewhat easy from the outside but if you try to actually implement a solution you discover a horrible mess of details. I'm just wondering that, and I think you're in a situation where it would be very beneficial to explain this more, since boost.signals2 exists.
I added a new documentation page discussing the similarities and differences between Signals2 and Synapse: http://zajo.github.io/boost-synapse/Comparison_between_Boost_Signals2_and_Sy... (here I would like to apologize if I got something about Signals2 wrong, please someone do correct me if I did.) To answer your concerns: First, in Signals2 signals are objects while in Synapse they are types. The notion of emitter does not exist in Signals2, the signal object does the emitting, but the emitter (in the traditional sense) would be the object the signal object is a member of. This makes sense in Signals2 because it has no use of emitters as such, but in Synapse the concept of the emitter object is central. Both designs make sense independently, but there is a clash of terms that would be next impossible to communicate to the average user. Second, while it may be possible to use Signals2 signal objects simply as a storage for connected functions to call (in a supposed attempt to use Signals2 as a sort of back-end for Synapse, or to "Synapsify" Signals2), that in itself would be little more than a list of functions. Since Synapse organizes all connections of a given type into a single data structure, it's probably possible to turn this into a list Signals2 signal objects per Synapse signal type, but I don't see the benefit (and there would be the big downside of Signals2 being a dependence of Synapse.) Third, the two libraries take a different and incompatible approach to thread safety. The connection list maintained by Signals2 signal objects must be thread-safe, but the Synapse connection lists need not, since they use thread_local storage. And, there is nothing in Signals2 that resembles the interthread communication supported by Synapse (I do agree that the ability to change the thread affinity of connection objects can be useful and should probably be added to Synapse.) This is not to say that there is anything wrong with Signals2. The search Synapse must do when emit<S> is called could be a deal breaker in some use cases. On the other hand Synapse makes emitting signals from a third-party object simple and elegant. Thanks, Emil