Re: [boost] [c++11]

On 06/18/13 05:21, Thomas Heller wrote:> On Tue, Jun 18, 2013 at 11:37 AM, Jonathan Wakely

wrote:

...

On 18 June 2013 08:33, Thomas Heller wrote:

...

On Mon, Jun 17, 2013 at 11:54 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.

Hmm... Pack into tuple, then unpack. Sounds similar to what: http://svn.boost.org/svn/boost/sandbox/variadic_templates/boost/composite_st... except before packing each element in the tuple, it "reifies" the element into its "concrete" (or most derived) type using single dispatch or Watanabe's switch. Then, when all the packing is done, it unpacks into a variadic concrete argument list using (a technique similar to Jonathan's n3658 method below) apply_unpack (from same location as reify_apply.hpp). However, because it uses recursive temples, it's slow to compile time.

...

...

...

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?

Very, very easily, see the apply() example in [intseq.general] in the C++14 draft, taken from http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3658.html

Doing that with the preprocessor instead would be ... I don't have a polite way to say it.

[snip]

My point is that saying this is impossible without variadic templates is plainly wrong. Of course, and I said this in my previous message as well, variadics ease the way to write such code. A preprocessor (with the help of partial preprocessing) based solution might be more efficient though, because no template recursions are needed.

Agreed(based on my experience), template recursions are slow and the boost PP as a solution has been mentioned before: http://article.gmane.org/gmane.comp.lib.boost.devel/189900 [snip] -regards, Larry