Re: [sigc] Re: [Boost-users] Signals & Slots
- From: Martin Schulze <martin-ml hippogriff de>
- To: Douglas Gregor <dgregor cs indiana edu>
- 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: Sun, 09 Jan 2005 16:35:03 +0000
Am 07.01.2005 14:19:20 schrieb(en) Douglas Gregor:
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.
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.
> 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.
Well, I remember a benchmark posted some time ago ... :-)
- 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? 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()?
- 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?
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 for me. The API was intended to be similar to Boost's. E.g.
the accumulater API is borrowed from Boost.
Regards,
Martin
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]