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

From: Douglas Gregor (dgregor_at_[hidden])
Date: 2005-01-07 08:19:20

On Jan 7, 2005, at 6:12 AM, Murray Cumming wrote:
> 3. In "Slot Binders"
> Can you expand on this question: "TODO: answer questions: a) What's up
> with the No Clue entry, anyone?", please. In fact, please just ask your
> TODO questions on this mailing list.

So the intent of retype() and retype_return() is to allow casting of 
the argument and return types of a function. Are these also required 
when performing implicit conversions? For instance, will the following 
work?

   long Func3(double val, string str);

   sigc::signal<int, float, string> sig;
   sig.connect(sigc::ptr_fun(&Func3));

If I'm right in assuming that the code will not compile (because the 
signatures do not match exactly), then the "No Clue" could be replaced 
by "Not Applicable", because
Signals performs all of the implicit conversions.

> 4. Some of the "-ed" comments seem outdated now. It would be nice to
> clean these up.

Replying to some of the -ed comments:

   - Regarding implementing the preferred syntax from Boost.Signals in 
libsigc++: it should  be trivial, although support for writing function 
types is not as portable as we'd like.

   - Regarding bloat factors: they're probably about the same in both 
libraries. The only thing we know to do to improve the situation is use 
function pointers instead of virtual functions, and to try to be 
careful about factoring our templates properly.

   - About ptr_fun/mem_fun: you can use them in either library, if you'd 
like to be more explicit.

   - About bind: bind is now in the C++ Library TR (an addendum to the 
standard, which should be approved in the near future), so we're forced 
to build on it to create any signals & slots library for the standards 
committee. (We'll have a long, uphill battle if we try to introduce our 
own special binders and don't support bind).

   - Regarding libsigc++'s specialization for T_accumulator=nil: We 
don't need to discuss this in a standards proposal, because it's 
entirely a quality-of-implementation issue.

   - Regarding Signals and Function: They don't play well together, but 
we're going to have to deal with this one way or another because 
Function is also part of the C++ Library TR.

And one minor quibble: if we're going to explicitly qualify 
Boost.Signals by saying that it was strongly influenced by the work of 
Karl Nelson (that's true), I think it's only fair to point out that 
libsigc++-2.0's interface was influenced by Boost.Signals.

        Doug