Re: slot returns it is connected to

[David Sugar]

I am leaving shortly for Aachen, but I may get a chance to look at it
while there over the weekend.  Perhaps Federico will also have some
input to suggest on it...

David

On Wed, 2004-01-14 at 08:05, "Marc Boris Dürner" wrote:
> OK, I will write some docs for it and send it again in a few days. I
> optimised it to a point 
> where I think it is reasonable to expand it to more signal/slot classes with
> 2,3,4,5 etc 
> arguments being transmitted. 
> Can you help me out with making it thread safe? 
>  
> There is two more features that I want to look at: 
>  
> - connecting a signal to a function that is not part of a class  
> - make the signal return what the return value of the slot function 
>  
> I dont expect these two features to be used much, but for the sake of
> completeness... 
>  
> I have to make one correction though wrt SigC and portability. SigC is
> portable, but 
> requires a really good C++ compiler. Thats what I meant by porting issues.
> Commonc++ 
> tries to also support weaker compilers and having our own implementation
> enables us to 
> adapt as needed quickly. 
>  
> As a side effect there is a PtrList template class available too now ;) 
>  
> Marc 
>  
> 
> On Wednesday 14 January 2004 13:43, you wrote: 
> > 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/
>