On Tue, Jun 18, 2013 at 6:41 PM, Niall Douglas
Now, nothing in proposed Boost.AFIO uses variadic templates in a way not replaceable with preprocessor programming. However it very /nearly/ did: I had this neato bit of evil variadic instantiation which let you convert an unknown set of trailing args into a std::tuple<> for storage, then /unpack/ said std::tuple<> back into an unknown set of trailing args, all with perfect forwarding. Effectively it was a compile-time std::function<> implementation.
[snip] I can already here you ranting about how variadic templates allows you to use an arbitrary number of parameters while the preprocessor solution can not.
"Ranting"? That's a little harsh don't you think? I am plenty aware that variadic templates have similar limits in parameter depth as recursive templates.
Sorry, I didn't mean to offend you. English isn't my native language and i sometimes use inappropriate words when I am excited about something :P
Actually that wasn't the problem I found. And yes, I am more than well aware of Boost's existing facilities in Phoenix et al. and thanks to everyone for pointing them out in depth.
That evil variadic template machinery gets rid of that problem. And its only replacement is std::function<> - you *cannot* implement that functionality (pure compile time std::function<>) without variadic templates because you can't properly unpack them without.
I'll quickly explain the problem I found just for the list's reference: I struggled to implement nested args-to-tuple => tuple-to-args expansion without variadic templates i.e. if I bind up a callable and a set of args into a compile time container, and then pass that itself as part of a set of unknown args, I kept running into instantiation limits in C++03 era compilers.
I'll entirely grant you, before anyone comments, that it could be entirely my own shoddy metaprogramming skills. And yes, I know you can tell some compilers to increase their hard limits.
Either way, with C++03 era compilers it just became easier to use a function<>, push the problem into the runtime and be done with it, especially as the preprocessor generated template specialisations are lengthy and substantially extend compile times, as other posts have mentioned.
That was the basis of my "quite bold statement" which you don't think holds: an earlier failure of mine in C++03 which was fairly straightforward to implement in C++11, and something I probably would have moved ahead with in Boost.AFIO if it weren't that I'm pretty sure we'll need to drop the variadic templates requirement. I accept, given the list's response, that the cause is likely my incompetence as a programmer and others on this list can perform magic I cannot. I therefore retract my earlier assertion.
You shouldn't resort to so much humbleness. I think, as a takeaway from this discussion we should appreciate that variadic templates are indeed superior to a preprocessor based solution (at least from the codeability aspect). Furthermore i believe that pushing that feature is also a good idea. However, that has many implications and everyone involved needs to be aware of those. I will support you in your efforts for going for a C++11 based solution under the condition that boost will move on and deprecate all libraries that will be unusable with a C++03 compiler. Maybe Boost.AFIO should be the library that advocates and pushes this breaking change.
Niall
--- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost