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

From: Doug Gregor (dgregor_at_[hidden])
Date: 2005-01-10 11:45:11

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