Re: hal++ announcement

[Daniel Elstner <daniel kitta googlemail com>]

Hi,

> On 11/26/06, Pierre THIERRY <nowhere man levallois eu org> wrote:
>         Mostly for curiosity and a bit for proselytism, did you
>         consider using
>         another library to manage signals? I used various Boost[1]
>         libraries
>         pretty much, and they are very well designed. Most are a very
>         good 
>         balance between power and ease of use.
>         
>         They have a Boost.Signals[2] library that I think gives much
>         more
>         flexibility. Specifically, it doesn't force the user to
>         subclass a
>         particular class. IIRC, any functor could be used as a
>         callback. 

Er, that's a misconception.  sigc++ does *not* force you to subclass
from sigc::trackable.  You only do that if you want automatic signal
management, such as breaking all connections if an object is destroyed.
Also, I think you should be able to use any functor as callback with
sigc++.  sigc::fun_ptr exists mainly to resolve ambiguous cases.

In fact, sigc++ was once a proposed implementation of the back then
future signaling library in boost.  Although that didn't work out, the
boost signaling was cleared inspired by sigc++.  sigc++ 2.2 even broke
the API in order to match boost conventions and style.

>         Would it be possible to use your library with Boost.Signals?

I don't think it would be a good idea if only hal++ switched to boost
and the other *mm libraries stay with sigc++.  You certainly don't want
to use two signal APIs at the same time.  If anything, the whole *mm
stack should switch in a joint move.  Of course, that could only be done
at the next big API break.  Also, we'd have to make sure that boost
provides the hooks required by gtkmm to be able to wrap GTK+ signals
transparently.  And someone would have to volunteer to do all the work,
of course.

Cheers,
--Daniel