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

From: David Abrahams (dave_at_[hidden])
Date: 2004-11-20 10:28:10

Carl Nygard <cjnygard_at_[hidden]> writes:

> On Thu, 2004-11-18 at 14:09, Doug Gregor wrote:
>> On Nov 18, 2004, at 1:10 PM, Murray Cumming wrote:
>
>> I'm not in a position to do this at the moment, although possibly in 
>> the future. It would be *wonderful* if someone went off and studied 
>> both libraries in-depth to make this comparison, especially if that 
>> person was not intimately familiar with either library beforehand.
>> 
>
> Available: http://www.3sinc.com/opensource/boost.bind-vs-sigc2.html
>
> Updates for code samples from Chris Vine and Jonathan Brandmeyer will be
> forthcoming.
>
> I could use some suggestions on how to incorporate common code into the
> code comparison tables.
>
> And of course, any other comments, flames, etc. will be welcome.  I'm
> only doing this as a service for keeping track of comments.  

The syntax you're using for boost::function is a bit passe.

  // Signal with two args and int return value
  boost::signal2<int, float, string> sig;

Should be
 
  // Signal with two args and int return value
  boost::signal<int (float, string)> sig;

I think your analysis underestimates or ignores the importance of
syntax, most importantly the syntax for invoking a signal.  The fact
that the Boost signal is an ordinary function object that can be
called directly has important implications for interoperability (you
don't need binders).

  NOTE: Boost.Signals documentation states that there are exceptions
  to using boost::signals::trackable, specifically the trackable base
  class is unable to manage connections created using Boost.Function
  or Boost.Lambda. This problem is stated to be resolved in future
  versions.

  Trackable

  Boost.Signals is at a bit of a disadvantage because the trackable
  class doesn't work with Boost.Lambda and Boost.Function. In this
  bsense, SigC library's implementation seems superior, if only
  because you don't have to think about limitations.

Does libSigC++ not suffer from an analogous limitation, or did its
documentation simply fail to mention it, or is just requiring you to
do more work manually?

The equivalency table for slot binders is misleading, I think.
Boost.Signals has no direct coupling to Boost.Bind, and the fact that
Boost.Bind doesn't provide certain binders doesn't mean you can't get
them another way.  For example, I think you can use Boost.Lambda or
Phoenix to create them.

As for the retype ... stuff, I don't know what libSigC++ does there.
However, no explicit retyping is needed with Boost where the types
concerned are implicitly convertible to the expected types.

Hope this helps.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com