[sigc] Re: [Boost Signals & Slots] Vs [libsigc++]
- From: "Murray Cumming" <murrayc murrayc com>
- To: "Foster, Gareth" <gareth foster siemens com>
- Cc: libsigc-list gnome org, "'gtkmm-list gnome org'" <gtkmm-list gnome org>
- Subject: [sigc] Re: [Boost Signals & Slots] Vs [libsigc++]
- Date: Thu, 18 Nov 2004 10:50:23 +0100 (CET)
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 lists boost org
> [mailto:boost-users-bounces lists boost org] On Behalf Of Doug Gregor
> Sent: 17 November 2004 15:49
> To: boost-users lists boost org
> 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 lists boost org
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
>
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]