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

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
> > >
> > > Yup, and Boost.Signal has signal<void (float, string)> notation
> > > 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
> >
> > I don't think anybody is interested in using some secondary API
> > (probably semi-internal API) just because that API is similar in
> > libsigc++ and Boost.Signal.
> Sorry, I thought the reason for the comparisons was as a first step
> C++ standard library, so I figured the analysis should concentrate
> underlying implementation instead of syntactic conveniences...
> those conveniences go a long way toward making the library usable.
> update the docs...

Docs updated.  Fuller explanations added for Slots.  Also reorganized
the sections and simplified some of the examples.  Significant
to the Slot and SigMgmt sections.

Questions that need answers:

a) Can slots be used independently from signals as functors which
the actual implementation?  I can see that such an object would be
useful, especially if it had the advantage of automatic disconnection
class dtor to protect from dangling pointers.


b) can libsigc++ take a plain functor object as parameter to


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>)


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??]"


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):

Or (retaining the return value):
'namespace sigc {


Thanks a lot for writing this very objective comparison! I will put a link on the libsigc++ homepage, ASAP.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]