Re: slot returns it is connected to

[Federico Montesino Pouzols]

        About making signals thread safe, there is the sigslot library
(a project at sourceforge), which after a quick look seems really
interesting...

On Wed, Jan 14, 2004 at 08:47:57AM -0500, David Sugar wrote:
> 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/
> > 
> 
> 
> 
> _______________________________________________
> Bug-commoncpp mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-commoncpp