Re: [boost] [Signal] Variadic template implementation of signal/slot
On Wednesday 20 May 2009, Frank Mori Hess wrote:
On Wednesday 20 May 2009, Kevin Brandon wrote:
Would anyone be interested in seeing my implementation of Signals/Slots that uses the variadic template capability that will be a part of c++0x
standard? Sure. Can you give an outline of how you are using variadic templates and the interface changes?
I've submitted my template to the vault, under * Home / variadic_templates/Signal.hpp I know that my implementation does not take advantage of the useful templates boost provides like functional, variant, any, etc... So my apologies for that; however, here is a summary of it ... Imagine... template<typename Result, typename ... Args> class Signal { Result operator ()(Args... args); template<class T> void connect(T* objPtr, Result (T::*memPtr)(Args...)); void connect(Result (*funcPtr)(Args...)); void disconnect(); void disconnect(T* objPtr, Result (T::*memPtr)(Args...)); void disconnect(Result (*funcPtr)(Args...)); } Which does allow for this.... Signal<float, int, int> signal; signal.connect(&foo_function_pointer); signal.connect(&foo, Bar::&bar_member_function_pointer); float foo = signal(1,2); One neat feature that my implementation does allow for is that both functions and function pointers are considered "slots" and all can connect to the signal of the correct signature. Its still infantile, but I thought that was going in a neat direction. There is still quite a bit to do; however, I figured I'd find out it had enough merit to share. I did not make it threaded, thinking that I would leave that to the functions themselves to thread or not. In that same spirit I did not implement a block or unblock mechanism. I did not create the += operator, of which I saw that it was vote down for the boost Signal and Signal2 libraries. As I mentioned before, if the interest exists, I will try to integrate and respect the design decisions that already made in the other versions... This is my first venture into sharing to the open source community, so my apologies if it all seems a little wet behind the ears :P Thanks for your time and audience, Kevin Brandon
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 21 May 2009, Kevin Brandon wrote:
One neat feature that my implementation does allow for is that both functions and function pointers are considered "slots" and all can connect to the signal of the correct signature.
But your interface only supports a subset of the slot types supported by Boost.Signals, since it doesn't support functor objects such as those returned by boost::bind. However, your Signal class does highlight the fact that the boost signal0, signal1, ..., signalN classes might be implemented through a single variadic template class when compiling with a C++0x compiler. This might reduce compile time overhead, since the compiler wouldn't have to generate and parse all the individual signalN classes. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoVldQACgkQ5vihyNWuA4WUawCfbowj1FoBKHLqNqH1c1h3p/Nd b3MAnieiVGk5pvW6rFYcGbzy4J0rXolW =nLxw -----END PGP SIGNATURE-----
On Thu, May 21, 2009 at 10:56 AM, Frank Mori Hess <frank.hess@nist.gov> wrote:
On Thursday 21 May 2009, Kevin Brandon wrote:
One neat feature that my implementation does allow for is that both functions and function pointers are considered "slots" and all can connect to the signal of the correct signature.
But your interface only supports a subset of the slot types supported by Boost.Signals, since it doesn't support functor objects such as those returned by boost::bind.
I should have said is that I did not baseline at all off of Signals or Signals2. I did peruse through them while I was searching for examples of Signal and Slots. I did like what I saw; however, my thought and intention was how to make a variadic template version of what I was seeing. So in effort what I created was a proof of concept, not a full fledged enhancement of Signals or Signals2. Once I had success, I thought it would be fun and interesting to see if I could help implementing this through Boosts Signals if it was desired.
However, your Signal class does highlight the fact that the boost signal0, signal1, ..., signalN classes might be implemented through a single variadic template class when compiling with a C++0x compiler. This might reduce compile time overhead, since the compiler wouldn't have to generate and parse all the individual signalN classes.
And less code to maintain! :P
So with this all said, would there be any interest in having an attempt of Signals/Signals2 in varaidic template form?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 21 May 2009, Kevin Brandon wrote:
So with this all said, would there be any interest in having an attempt of Signals/Signals2 in varaidic template form?
If you like, you can try implementing a signals2/variadic_signal.hpp based on the preprocessor template code in signals2/detail/signal_template.hpp. I guess you'll have to wrap all the non-signature template parameters for the signal in a policy class that can be passed as the first template parameter to variadic_signal, since the variadic template parameter pack has to be last. I played around a bit with replacements for the arg1_type, arg2_type, etc typedefs, see the "signature" template in the attached file. It lets you extract the arity and individual argument types from the template parameter pack. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoWwPAACgkQ5vihyNWuA4WfCwCdF0RBo3aaeDcmCkj88x17rABw 28AAn37J3491L+aLk2SZzOo/2iI1pE2g =jkM+ -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 22 May 2009, Frank Mori Hess wrote:
I guess you'll have to wrap all the non-signature template parameters for the signal in a policy class that can be passed as the first template parameter to variadic_signal, since the variadic template parameter pack has to be last.
Actually, after playing around with variadic templates a bit more and looking at the spec of the variadic std::function in c++0x, it looks like you can use partial template specialization and function types to match how the current signal class looks. Something like: template<typename Signature, typename DefaultedType=int> class myclass; template<typename DefaultedType, typename R, ... Args> class myclass<R(Args...), DefaultedType> { //... } -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoXA/YACgkQ5vihyNWuA4UrpgCeOwo0x2T1K8cRQIhl71bJlFfu 6EEAn3wQVEGiYz2hPeT1O4E5raC9ohEO =DdBz -----END PGP SIGNATURE-----
participants (2)
-
Frank Mori Hess -
Kevin Brandon