Re: [sigc] Re: [Boost-users] Signals & Slots
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
Doug Gregor wrote:
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.
I still think that we need to explore the alternative approach of storing a weak_ptr in the function object and make the signal automatically disconnect on bad_weak_ptr. This ties automatic disconnection to shared_ptr+weak_ptr, but now they are part of TR1. The upside is no base classes and no visit_each. I'm not sure whether this line of thought should be continued to its natural conclusion, making the signal disconnect on any exception, not just bad_weak_ptr. bad_function_call, for example, is an obvious candidate. What is the current course of action when a slot throws?
On Jan 10, 2005, at 1:48 PM, Peter Dimov wrote:
Doug Gregor wrote:
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.
I still think that we need to explore the alternative approach of storing a weak_ptr in the function object and make the signal automatically disconnect on bad_weak_ptr. This ties automatic disconnection to shared_ptr+weak_ptr, but now they are part of TR1.
This is still a really good idea, and we should support it.
The upside is no base classes and no visit_each.
The downside is that you have to use shared_ptr + weak_ptr. Granted, that's a pretty common use case.
I'm not sure whether this line of thought should be continued to its natural conclusion, making the signal disconnect on any exception, not just bad_weak_ptr. bad_function_call, for example, is an obvious candidate. What is the current course of action when a slot throws?
The exception is propagated to the combiner (Boost terminology; it's accumulator in libsigc++), which may intercept it. The default combiner propagates it back to the signal caller. Doug
participants (2)
-
Doug Gregor -
Peter Dimov