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

[Martin Schulze <martin-ml hippogriff de>]

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