Re: Signals/Slots for CommonC++

[Marc Boris Dürner]

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/ 

-- 
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net