Re: [sigc] Re: [Boost-users] Signals & Slots

[Martin Schulze <martin-ml hippogriff de>]

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