On Mon, Jun 17, 2013 at 11:54 PM, Niall Douglas
I wasn't suggesting making the library strictly C++03-compatible. My main point was that the library has to be compatible with _todays_ and even better - _yesterdays_ compilers to be actually useful. My choice of "reasonable" time frame is 3-5 years, as I mentioned. That includes VS 2008 and VS 2010, which already had some C++11 features, including rvalue references. Making VS 2013 absolute minimum is a no-go, IMHO.
I don't think anyone is making VS2013 an absolute minimum - rather they're making variadic templates an absolute minimum. Something which any other compiler than VS has had for years, and something which unlike many, if not most other C++11 language features is something which lets you write a ton of stuff you simply can't write without them.
Now that is quite a bold statement. I don't think it holds. For example how about compile time O(1) access to the passed parameters?
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.
That is *very* easily achievable with the preprocessor. The outstanding feature here, IMHO, is the perfect forwarding, which is of course not possible with C++03. In any case, I couldn't think of how you'd unpack the tuple to call the function without the preprocessor. Could you please show me a code snippet how this could be done? FWIW, i just very recently wrote an implementation of the very same features you are talking about, just using the preprocessor (See here: https://github.com/STEllAR-GROUP/hpx/blob/master/hpx/lcos/local/dataflow.hpp). You might also want to take a look at Phoenix which does the very same thing (Granted, without perfect forwarding). 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. Unfortunately, that isn't true as well, the number of variadics is limited by the compiler. That number is of course higher than what you can do with the preprocessor (to overcome this limitation we make heavy use of wave to partially preprocess our headers), and you safe some time in parsing. If anything, variadics just make your life as a library author easier than if you wanted to achieve the same with Preprocessor meta programming.
As proposed Boost.AFIO is also a closure execution engine where that closure can take arbitrary args and return arbitrary returns, that evil variadic template machinery was really useful because it lets you skip using std::function<> with its implied virtual function call. As proposed Boost.AFIO currently nests, in the worst case scenario, a fully bound std::function<> calling a partially bound std::function<> calling a partially bound std::function<>, that's three nested virtual indirect function calls. Recent Intel CPUs can prefetch and branch predict two nesting levels, but they can't cope with three, so performance takes a real nose dive and hence one of the reasons we currently see a peak 80k IOPS. 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.
See above. 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