[signals] slot with no SlotFunction template parameter
I'm implementing a more feature-full slot class with some of the things that have been discussed recently. In particular, it is templated only on signature. It uses a templated constructor to store the slot function in a pimpl object that is templated by both signature and slot function type. So now I'm about to rip out the SlotFunction parameter everywhere from thread_safe_signals, as there no longer seems to be any need for it. I feel like I might be overlooking something though. Is there any reason to keep it? -- Frank
On Monday 26 February 2007 16:19 pm, you wrote:
I'm implementing a more feature-full slot class with some of the things that have been discussed recently. In particular, it is templated only on signature. It uses a templated constructor to store the slot function in a pimpl object that is templated by both signature and slot function type. So now I'm about to rip out the SlotFunction parameter everywhere from thread_safe_signals, as there no longer seems to be any need for it. I feel like I might be overlooking something though. Is there any reason to keep it?
After a little more reflection, it seems what I have done to get rid of the SlotFunction template parameter from the slot class has pretty much the same effects as if I just hard-coded the SlotFunction to be boost::functionN. So my question is: what is the point of having the SlotFunction be parametrizable, and are we going to miss it? -- Frank
Frank Mori Hess wrote:
After a little more reflection, it seems what I have done to get rid of the SlotFunction template parameter from the slot class has pretty much the same effects as if I just hard-coded the SlotFunction to be boost::functionN. So my question is: what is the point of having the SlotFunction be parametrizable, and are we going to miss it?
There's more than one implementation for generalized callbacks and while Boost.Function has the tr1 interface, it will not necessarily be the implementation used by a signal client. Mixing different implementations involves a performance and memory usage penalty, so I would keep it somewhere at the end of each parameter list, defaulting to Boost.Function at least as a transition helper until there is a std::function. As you say yourself: it's unproblematic implementation- wise. Regards Timmo Stange
participants (2)
-
Frank Mori Hess -
Timmo Stange