[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: slot returns it is connected to
From: |
Federico Montesino Pouzols |
Subject: |
Re: slot returns it is connected to |
Date: |
Wed, 14 Jan 2004 19:23:39 +0100 |
User-agent: |
Mutt/1.5.5.1+cvs20040105i |
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