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

[Doug Gregor <dgregor cs indiana edu>]

On Jan 9, 2005, at 11:35 AM, Martin Schulze wrote:
> Am 07.01.2005 14:19:20 schrieb(en) Douglas Gregor:
> > 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.
>
> I'm afraid, you're wrong here. Implicit conversions do work. 
> retype(_return) is for explicit conversions.
> However, using implicit conversions in libsigc++-2.0 without 
> retype(_return) can cause troubles (at least warnings) with some 
> compilers.

Okay, good. Then I don't have to try to motivate the need for implicit 
conversions :)

> >    - 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).
>
> Is there a way to deduce the return type of the bind functor object 
> that is part of the TR?

Yes. It's called "result_of" in the Library TR.

>  Will it be possible to "visit the targets" that are stored in the 
> bind functor object with a function like Boost::visit_each() or 
> sigc::visit_each()?

This functionality was not included because it was not necessary for 
anything in the Library TR (and would otherwise be hard to motivate). 
We could propose this as part of a signals 'n' slots system, of course.

> >    - 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.
>
> I always thought that Boost had quite some influence on standard 
> proposal? Who come that the TR is in a bad shape for a signal system, 
> then?

I wouldn't say that it is in bad shape for a signal system. The problem 
with {boost:: or tr1::}function and a signals system is that they both 
do the same thing: erase the static type of a function object so that 
it can be called through an entity that does not encode that type. The 
problem is that we need to call visit_each before we erase that type: 
'function' shouldn't do it all the time, because that could be costly, 
and the signal/slot can't do it because the type is gone. We can 
probably come up with a not-too-painful solution, if we're clever 
enough.

	Doug