Re: [sigc] Re: [Boost-users] Signals & Slots
- From: Martin Schulze <martin-ml hippogriff de>
- To: Murray Cumming <murrayc murrayc com>
- Cc: Doug Gregor <dgregor cs indiana edu>, libsigc++ list <libsigc-list gnome org>, boost-users lists boost org
- Subject: Re: [sigc] Re: [Boost-users] Signals & Slots
- Date: Sat, 08 Jan 2005 10:50:37 +0000
Hi!
I will look at your questions later. Attached is an email that I posted
last year regarding this subject. I'm afraid my answers and remarks
didn't make it to the review at
http://www.3sinc.com/opensource/boost.bind-vs-sigc2.html
Regards,
Martin
Am 07.01.2005 12:12:11 schrieb(en) Murray Cumming:
On Mon, 2004-11-22 at 01:00 -0500, Carl Nygard wrote:
> http://www.3sinc.com/opensource/boost.bind-vs-sigc2.html
[snip]
> Docs updated.
[snip]
I thought I'd review this again, because I lost track of what changes
were made.
1. In several cases, you show
sig.connect(&Func);
but show
sig.connect(sigc::ptr_fun(&Func));
for the libsigc++ example.
But I believe (Am I correct, Martin?) that sig.connect(&Func) will
work
with both APIs, and I believe that boost has a ptr_fun() too. It does
not seem to be an API difference.
2. In "Automatic disconnection",
the use of operator() instead of a normal method will just cause
confusion.
3. In "Slot Binders"
Can you expand on this question: "TODO: answer questions: a) What's
up
with the No Clue entry, anyone?", please. In fact, please just ask
your
TODO questions on this mailing list.
4. Some of the "-ed" comments seem outdated now. It would be nice to
clean these up.
Thanks again.
--
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com
_______________________________________________
libsigc-list mailing list
libsigc-list gnome org
http://mail.gnome.org/mailman/listinfo/libsigc-list
Am 22.11.2004 07:00:46 schrieb(en) Carl Nygard:
> On Sun, 2004-11-21 at 20:09, Carl Nygard wrote:
> > On Sun, 2004-11-21 at 14:26, Murray Cumming wrote:
> > > On Sat, 2004-11-20 at 15:58 -0500, Carl Nygard wrote:
> > > > > 2. libsigc++2 uses sigc::signal<>, not
> sigc::signal[1/2/3/4/5]<>.
> > > >
> > > > Yup, and Boost.Signal has signal<void (float, string)> notation
> as
> > > > well. I was trying to keep the examples as identical as
> possible to
> > > > show commonalities, but I'll make a note.
> > >
> > > The API here seems to be different, so it would be useful to show
> that.
> > >
> > > I don't think anybody is interested in using some secondary API
> > > (probably semi-internal API) just because that API is similar in
> both
> > > libsigc++ and Boost.Signal.
> >
> > Sorry, I thought the reason for the comparisons was as a first step
> for
> > C++ standard library, so I figured the analysis should concentrate
> on
> > underlying implementation instead of syntactic conveniences...
> although
> > those conveniences go a long way toward making the library usable.
> I'll
> > update the docs...
>
>
> Docs updated. Fuller explanations added for Slots. Also reorganized
> the sections and simplified some of the examples. Significant
> changes
> to the Slot and SigMgmt sections.
>
> Questions that need answers:
>
> a) Can slots be used independently from signals as functors which
> hide
> the actual implementation? I can see that such an object would be
> useful, especially if it had the advantage of automatic disconnection
> on
> class dtor to protect from dangling pointers.
Yes.
> b) can libsigc++ take a plain functor object as parameter to
> connect()
Yes.
However it won't have a hint about the return type, then, so the return
value cannot be passed on. To my (limited) knowledge, the same is the
case with Boost.
libsigc++ has a work-around for this problem: You can specify the
return type of a generic functor type explicitely with
namespace sigc {
SIGC_FUNCTOR_TRAIT(<functor_type>, <return_type>)
}
(http://libsigc.sourceforge.net/libsigc2/docs/reference/html/group__functors.html)
> c) Can someone verify my comparison of Boost.Bind to the libsigc++
> Adaptor classes?
A few examples of how to use Boost.Bind would be helpful.
Further remarks:
d) (Slot Object)
"This seems also to be the case with libsigc++ slot objects, which are
also templatized. [-ed without looking too hard at the code, the
pattern of implementation (i.e. concrete base class with pimpl idiom,
derived template classes) seems the same, so I'm guessing they both
produce similar bloat factors. Someone correct me??]"
Correct.
e) (Slot Object)
Note that instead of
'sigc::mem_fun(obj, &Foo::Func)'
you should also be able to use
'sigc::bind(&Foo::Func, obj, sigc::_1, sigc::_2)'
However, 'sigc::mem_fun(obj, &Foo::Func)' will definately cause less
bloat. (It will also most certainly cause less bloat than 'boost::bind
(&Foo::Func, obj, _1, _2)').
e) (Slot Object)
"When connecting slots to signals, libsigc++ has a more explicit
syntax, requiring the use of sigc::mem_fun() or sigc::ptr_fun() to
construct the appropriate slot object. [-ed I'm a bit unclear about
functor objects, it seems they can just be passed in the
sigc::signal::connect() function??]"
Wrong. See b). Also passing plain function pointers works ('sig.connect
(&Func)').
f) (Automatic disconnection)
"sig.connect(sigc::ptr_fun(f, &Functee::operator()));
sig.connect(sigc::ptr_fun(g, &Functee::operator()));"
Bad syntax. Use:
'sig.connect(sigc::mem_fun(f, &Functee::operator());
sig.connect(sigc::mem_fun(g, &Functee::operator())'.
Or (loosing the return value):
'sig.connect(*f)
sig.connect(*g)'
Or (retaining the return value):
'namespace sigc {
SIGC_FUNCTOR_TRAIT(Functee, int)
}
sig.connect(*f)
sig.connect(*g)'
Thanks a lot for writing this very objective comparison! I will put a
link on the libsigc++ homepage, ASAP.
Regards,
Martin
_______________________________________________
libsigc-list mailing list
libsigc-list gnome org
http://mail.gnome.org/mailman/listinfo/libsigc-list
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]