From: Angus Leeming (angus.leeming_at_[hidden])
Date: 2005-03-10 09:18:43
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.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk