[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
slot returns it is connected to
From: |
Marc Boris Dürner |
Subject: |
slot returns it is connected to |
Date: |
Wed, 14 Jan 2004 14:05:33 +0100 (MET) |
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
- slot returns it is connected to,
Marc Boris Dürner <=