Re: [Boost-users] Signals & Slots

From: Foster, Gareth (gareth.foster_at_[hidden])
Date: 2004-11-18 06:49:48

Doug,

This is what murray had to say on the GTKmm list (future correspondance, if
any, to be on the libsigc++ list), it's a very pleasing response I'm sure
you will agree.

Perhaps you could qualify you last statement though, that one seems to have
murray a little stumped.

Cheers!

Gaz

-----Original Message-----
From: Murray Cumming [mailto:murrayc_at_[hidden]] 
Sent: 18 November 2004 09:50
To: Foster, Gareth
Cc: 'gtkmm-list_at_[hidden]'; libsigc-list_at_[hidden]
Subject: Re: [Boost Signals & Slots] Vs [libsigc++]

Questions comparing boost::signal to libsigc++ belong on the libsigc++
mailing list. I'm CCing it.

boost::signal was developer in cooperation with Karl Nelson, the main
original libsigc++ developer. Also, the libsigc++ 2 API was redesigned to
be as much like boost::signal as possible, so that gtkmm can easily switch
to boost::signal if it becomes an API-stable dependency or it is added to
the C++ Standard Library. gtkmm has a long-standing policy of not
reimplementing things when we can just reuse them.

This part makes no sense to me. It would have to be explained properly
before we could comment:
"
Basically, libsigc++ is a monolithic entity covering single and
multiple-target callbacks, slots, and slot binding, Signals tackles
only the multiple-target callbacks, relying on other Boost libraries
(especially Function and Signals) to do most of the work, so it
integrates cleanly with the rest of Boost.
"

Murray

> Hello all,
>
> As you will see in the forward email below, I was chatting to a bloke who
> works on boost::signal, I wondered how this stacked up against libsigc++,
> and whether there was any chance it could be used in GTKmm and suchlike. A
> GTKmm developer did pop up on the boost list and make the valid point that
> API stability would be a major issue, nevertheless, I thought I'd send
> this
> out, and see what people here had to say. As I said on the boost list, I
> am
> thinking more ...
>
>> "hey, what do you think to this lads" than an outright "you should be
> using Boost heathens!"
>
> I hope such discussion isn't offtopic.
>
> Thanks all!
>
> Gaz
>
>
> -----Original Message-----
> From: boost-users-bounces_at_[hidden]
> [mailto:boost-users-bounces_at_[hidden]] On Behalf Of Doug Gregor
> Sent: 17 November 2004 15:49
> To: boost-users_at_[hidden]
> Subject: Re: [Boost-users] Signals & Slots
>
>
> On Nov 17, 2004, at 9:20 AM, Foster, Gareth wrote:
>> I was just reading some mention of bugs in boost::signal,
>
> They weren't actually bugs :)
>
>>  is this
>> implementation in competition with libsigc++? i.e. does it aim to do
>> the
>> same job, but under a different license, or is there perhaps some
>> fundamental design difference between the two?
>
> The Signals library aims to be much more flexible than libsigc++ and to
> have an interface that is more comfortable for Boost. For instance,
> slots are just function objects with similar signatures (like
> Boost.Function, because Function is used in Signals), one can combine
> the results of calling multiple slots into a single return value via an
> arbitrary function object, and the lifetime of signals & slots is
> automatically tied to "trackable" objects used in bind expressions to
> build slots.
>
> Basically, libsigc++ is a monolithic entity covering single and
> multiple-target callbacks, slots, and slot binding, Signals tackles
> only the multiple-target callbacks, relying on other Boost libraries
> (especially Function and Signals) to do most of the work, so it
> integrates cleanly with the rest of Boost.
>
> 	Doug
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list_at_[hidden]
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
>

Murray Cumming
murrayc_at_[hidden]
www.murrayc.com
www.openismus.com