Tony Juricic wrote:
As for the constructive criticism of the library, I have signals in mind. Can you actually give any arguments (and concrete code examples) for why would anybody want to use signals library and what does it really do better than for ex. Java event handlers or C# delegates?
Don't know about the latter, but a real case where signals are perfect is to inform 'interested parties' when a child process has exited. Other asynchronous events also fit the bill perfectly here. John Torjo wrote:
Can you imagine and present a simple real-life application and prove all the claims in the chapter about comparisons with other Signal/Slot implemntations? For example, there was some talk here about using signals in boost GUI library. I tried to use it for a simplistic focus management and stumbled upon no-nos, which made me question the utility of the library as it stands now.
I certainly agree with you here. After reading the docs for boost::signal, I'm not sure what are its advantages over std::vector< boost::function<...> >
The primary advantage as I see it is that it won't dispatch to a class' member function when the "this" pointer has been destroyed. (So long as the class derives from boost::trackable.) Ie, Boost.Signals is safe where vector<boost::function<...> > is not. SigC++ has similar functionality. One signal library ( SigCX, http://libsigcx.sourceforge.net ) which derives from SigC++ will allow the user to tunnel signals between threads. Don't know how important this is in the real world, but it would give functionality similar to Windows messages, no? Unfortunates are the licence and the fact that the library is no longer maintained. (Private communication with author.) Regards, Angus