[Signal] Variadic template implementation of signal/slot
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? It seemed to me a natural evolution for the current library that is Signal\Signal2. I did not baseline from the current boost code; but, if the interest exists, I would love to submit my code for formal review and equally try to integrate and respect the design decisions that already fostered the growth for the other two versions. Regards, Kevin Brandon
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?
On Wed, May 20, 2009 at 12:44 PM, Kevin Brandon <staticrealm@gmail.com> 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?
It seemed to me a natural evolution for the current library that is Signal\Signal2. I did not baseline from the current boost code; but, if the interest exists, I would love to submit my code for formal review and equally try to integrate and respect the design decisions that already fostered the growth for the other two versions.
I think it would be really, really cool to have a version of Signals2 that uses variadic templates rather than preprocessor metaprogramming. For me, personally, I'd rather see it as an alternative implementation of exactly the same interface (switched based on BOOST_NO_VARIADIC_TEMPLATES) rather than a separate library. But, that's up to Frank :) - Doug
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 22 May 2009, Doug Gregor wrote:
I think it would be really, really cool to have a version of Signals2 that uses variadic templates rather than preprocessor metaprogramming. For me, personally, I'd rather see it as an alternative implementation of exactly the same interface (switched based on BOOST_NO_VARIADIC_TEMPLATES) rather than a separate library. But, that's up to Frank :)
That seems like the way to go. I was thinking it might be good to expose a separate variadic_signal which was completely free of preprocessor metaprogramming, instead of keeping it entirely as an implementation detail. But it seems to me now the existing signal interface might just need one change to be implementable without preprocessor metaprogramming. The arg1_type, arg2_type, etc typedefs need to be replaced with a template, so for example typedef signal<void (int)> sig_type; sig_type::arg1_type would look something like sig_type::arg<0>::type -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoXB5oACgkQ5vihyNWuA4VgdwCgjSgN47i0nI1wLR1PfTwB7YgL sakAn0AFMHpB/sl29O8uv4sjwpKm8ujo =9Sj2 -----END PGP SIGNATURE-----
On Fri, May 22, 2009 at 8:12 AM, Frank Mori Hess wrote:
If you like, you can try implementing a signals2/variadic_signal.hpp based on the preprocessor template code in signals2/detail/signal_template.hpp.
Last night I continued with my pursuits of using my class that I presented while I was waiting a response. For a test I created a signal that used a function that returned type void. It became clear to me as I researched the failing cause of trying to have template that returns a void, that I needed to use some template specialization. My c++ and c is strong; however, the last several years I have been pretty focused on Java. Template specialization, template meta programming, and the entirety of boosts functionality is pretty new to me. That said I still would really love to help with this effort... Although it seems like your running pretty well with the idea Frank, and signals2 is your baby. Fri, May 22, 2009 at 1:14 PM, Frank Mori Hess wrote:
But it seems to me now the existing signal interface might just need one change to be implementable without preprocessor metaprogramming So does this pretty much settle it? Would this be the variadic template implementation for Signals2?
On Fri, May 22, 2009 at 1:14 PM, Frank Mori Hess <frank.hess@nist.gov> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday 22 May 2009, Doug Gregor wrote:
I think it would be really, really cool to have a version of Signals2 that uses variadic templates rather than preprocessor metaprogramming. For me, personally, I'd rather see it as an alternative implementation of exactly the same interface (switched based on BOOST_NO_VARIADIC_TEMPLATES) rather than a separate library. But, that's up to Frank :)
That seems like the way to go. I was thinking it might be good to expose a separate variadic_signal which was completely free of preprocessor metaprogramming, instead of keeping it entirely as an implementation detail. But it seems to me now the existing signal interface might just need one change to be implementable without preprocessor metaprogramming. The arg1_type, arg2_type, etc typedefs need to be replaced with a template, so for example
typedef signal<void (int)> sig_type;
sig_type::arg1_type
would look something like
sig_type::arg<0>::type
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkoXB5oACgkQ5vihyNWuA4VgdwCgjSgN47i0nI1wLR1PfTwB7YgL sakAn0AFMHpB/sl29O8uv4sjwpKm8ujo =9Sj2 -----END PGP SIGNATURE----- _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've checked a variadic signal implementation into Boost.Signals2 on the svn trunk. It is used when boost detects variadic template support. The code still looks like macro hell, due to the continuing support for the non-variadic template implementation, but there is a noticeable improvement in compilation time. The little hello_world_slot.cpp example program compiled about 10%-15% faster with gcc 4.3 for example. However, the variadic Boost.Signals2 implementation still uses Boost.Function for its default SlotFunction and uses Boost.Bind, neither of which provide variadic templates implementations. Out of curiosity I tested replacing them locally with the variadic std::function and std::bind in gcc 4.3, and that also produced an additional reduction in compile time. I haven't updated the documentation yet, but the user-visible changes when using the variadic template implementation are as follows: 1) The "portable syntax" classes like signal0, signal1, etc are gone. 2) The member typedefs like "arg1_type", "arg2_type", etc are gone. They are replaced with a "arg" member template class, so instead of "sig_type::arg1_type" you would do "sig_type::arg<0>::type". For consistency the "arg" member template has also been added to the non-variadic implementation. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoe6kUACgkQ5vihyNWuA4UvJgCghW2dgyVPAJUhwfHJs+9X+A3f oCQAoLbW2yIz2Q7u2wWnsGYSaxe1leAA =NBge -----END PGP SIGNATURE-----
Frank Mori Hess wrote:
However, the variadic Boost.Signals2 implementation still uses Boost.Function for its default SlotFunction and uses Boost.Bind, neither of which provide variadic templates implementations. There should be a working variadic Function implementation in the C++0x BoostCon branch. I haven't updated the documentation yet, but the user-visible changes when using the variadic template implementation are as follows: 1) The "portable syntax" classes like signal0, signal1, etc are gone. 2) The member typedefs like "arg1_type", "arg2_type", etc are gone. They are replaced with a "arg" member template class, so instead of "sig_type::arg1_type" you would do "sig_type::arg<0>::type". For consistency the "arg" member template has also been added to the non-variadic implementation. The same limitations apply to the Function implementation on the branch. It might even have something like the arg member template; can't remember.
Sebastian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 28 May 2009, Sebastian Redl wrote:
There should be a working variadic Function implementation in the C++0x BoostCon branch.
Thanks, I wasn't aware of the sandbox/boost0x branch.
The same limitations apply to the Function implementation on the branch. It might even have something like the arg member template; can't remember.
It looks like it only provides the argument types for the N=1 and 2 cases, through std::unary_function or std::binary_function, but not the argument types in general (similar to std::function). I guess I should add those typedefs to the variadic Signals2, since I believe they are needed by some of the standard algorithms. Is providing typedefs for all the arguments in a generic way useful? I'm really only assuming it is, I don't have a specific use case in mind. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkof6sYACgkQ5vihyNWuA4XkHACfeSY37XaMVvWxi01BIshq/YBi LpIAn2mc6odGNLKGBnkq2s1b5tviCgGS =jizu -----END PGP SIGNATURE-----
participants (5)
-
Doug Gregor -
Frank Mori Hess -
Frank Mori Hess -
Kevin Brandon -
Sebastian Redl