Re: [boost] [synapse] Review

David Sankel wrote:

No, there should only be one signal type and Boost.Signal made the correct choice of using a so-called intrusive design.

I'm curious whether you can justify this opinion, because the answer is not as obvious to me. In fact, on its surface, the non-intrusive design is so much more flexible that one naturally tends to view it as the correct one. For example, Boost.Signal works well for this design: class window { private: // state public: window( ... ); ~window(); // ... }; We just need to add a few signals at //...: signal on_create; signal on_paint; Synapse however works equally well with this: class window; window* create_window( ... ); void destroy_window( window* ); // ... And with this: class window { public: virtual ~window() = 0; // other abstract methods }; window* create_window( ... ); And with this: class window { private: class impl; impl * pimpl_; public: window( ... ); ~window(); // ... }; You could, of course, use Boost.Signals with all of those: signal& on_window_create( window* ); signal& on_window_paint( window* ); // and so on but with Synapse, all that boilerplate is unnecessary. (You still need to declare the signals, of course, but that's all.) And, you can use Synapse even with this: HWND CreateWindow( ... ); void DestroyWindow( HWND ); To get back to what you wrote,

No, there should only be one signal type...

Except there isn't; but with Synapse, you can add a bit of scaffolding so that a library that uses its own signal type (or uses no signals at all but some other way of communicating, such as Windows messages or C callbacks) emits Synapse signals. Since you don't need to solve the problem of where to put the signal<> object, this is a relatively easy task. Whether the Synapse approach is clearly better may be arguable; whether it's a legitimate alternative design isn't.