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