Re: Signals/Slots for CommonC++

[David Sugar]

This was the kind of background answer I was looking for.  Yes, the
portability question is also important.   We could put the preliminary
one you have into cvs (it's a template class?  maybe under Common C++
templates?) to give a chance for people to work on it.

On Wed, 2004-01-14 at 05:57, "Marc Boris Dürner" wrote:
> On Wednesday 14 January 2004 04:51, David Sugar wrote: 
> > Is libsigc++ threadsafe?  Are there potential threading/synchronization 
> > issues/implications in slots/signal libraries?  These are the first two 
> > questions that came to my mind. 
>  
> No its not thread safe and the signals from boost aren't either. Another
> problem is that 
> boost-signals and SigC-signals dont work well with Qt. For boost there is a
> workaround, 
> for SigC I don't think so (guess why...) 
>  
> For SigC there are also portability issues I think, considering that
> ComonC++ tries to 
> support as many platforms as possible. 
>  
> CommonC++ signals are of course heavily influenced by boost-signals and SigC
> signals, 
> but easier to use. We have control over the code directly and when signals
> make it in the 
> c++ stdlib we can still decide to port to it. 
>  
> signals/slots isnt exactly rocket sience, so a CommonC++ version is
> absolutely feasable. 
> Compatibility between SigC-signals, boost-signals and CommonC++ signals is a
> no 
> problem, since all three create functors from a callback. So connecting a
> SigC signal to a 
> CommonC++ class or connecting a CommonC++ signal to a gtkmm function is
> possible. 
> Connecting a CommonC++ signal to a Qt slot should work out f the box, since
> we can 
> avoid Qt moc keywords. 
>  
> regards, 
> Marc  
>  
> 
> > 
> > David 
> > 
> > On Tuesday 13 January 2004 07:49 pm, Alex Pavloff wrote: 
> > > For signals/slots, I would suggest just folding in the libsgic++ library
> 
> > > that the gtkmm people created for help with making the C++ bindings for 
> > > gtk. 
> > > 
> > > http://libsigc.sourceforge.net/