Boost logo

Boost Users :

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


Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at