Re: [sigc] Re: [Boost-users] Signals & Slots
- From: Doug Gregor <dgregor cs indiana edu>
- To: Martin Schulze <martin-ml hippogriff de>
- Cc: libsigc++ list <libsigc-list gnome org>, boost-users lists boost org, Murray Cumming <murrayc murrayc com>
- Subject: Re: [sigc] Re: [Boost-users] Signals & Slots
- Date: Mon, 10 Jan 2005 11:45:11 -0500
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]