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

[Carl Nygard <cjnygard fast net>]

On Fri, 2005-01-07 at 08:19 -0500, Douglas Gregor wrote:
> 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.

In that case, it's supported in Boost.Bind, so retype/retype_return() is
included with sigc::bind/compose/hide/group.  Correct?

> 
> > 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.

I couldn't find docs on boost.org for ptr_fun, just mem_fun.  What am I
missing?

> 
>    - 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).

Do you have a link to the TR?

> 
>    - 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.

No problem, as long as Murry or Martin agree.  I know kenelson wrote the
first version of SigC++, so I wasn't really clear on who-begat-who.