-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Emil Dotchevski Sent: Sunday, December 04, 2016 5:45 AM To: boost@lists.boost.org Subject: Re: [boost] Synapse library review starts today December 2 Emil said:
- What is your evaluation of the potential usefulness of the
library?
I don't think it's that useful, but I guess I would still use boost.signals2 and boost::asio::io_service for interthread signaling. I'm not convinced this should be a distinct library, and not a feature of boost.signals2.
Synapse does not claim to be a "better" Signals2; its usefulness is not as
to Signals2 but as a solution to problems Signals2 cannot solve. Here are
an alternative three examples
of this, though I have many more:
http://zajo.github.io/boost-synapse/handling_events_from_an_OS_message_pump. html
http://zajo.github.io/boost-synapse/adding_custom_signals_to_Qt_objects_with out_MOCing.html
http://zajo.github.io/boost-synapse/using_meta_signals_to_connect_to_a_C-sty le_callback_API.html I disagree with this design style, which is to say I also disagree with the existing slot/signal style. As an example, what if we had a system with hundreds of thousands of numerics... each with a particular name. Then imagine a rule set that had to maintain integrity as any particular numeric were to be changed. With slots or synapses, you're forced to search for the object each time before applying the rules. This would bog down quickly as the number of updates per second increased (imagine 100k objects and 2-10k entwined rules being updated 2k times per second. That's a real world scenario) Objects should have events they can trigger or subjects they contain/manage which would trigger given a certain situation (value changes, particular event arrives, flag flips, whatever) and the observer(s), being unknown to the original object, would observe the event via a loose coupling mechanism. This allows for a system to have hundreds or thousands of objects all trigging events at random but only notifying the particular observers that are interested in that instance's event. This allows for a more flexible system while promoting dependency driven updates... which would result in the best performance for an event notification system. I've been using such a design since 1990 and posted a rendition of it to this group 3 months ago: https://github.com/tiny/boost_observers Regarding the real world scenario mentioned above, please check: https://github.com/tiny/boost_observers/blob/master/test/simple_numerics.cpp and https://github.com/tiny/boost_observers/blob/master/test/stockportfolio_nume rics.cpp