[boost] Re: Re: What I Hate About How We Abstract System Dependence

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.)

Regards,
Angus