slot returns it is connected to

[Marc Boris Dürner]

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/ 
 

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