comments inline... Larry Evans schrieb: ...
Also the lookup process should scale commensurate to N.
Is that not true with my tuple? AFAICT, it's not dependent on N. OOPS, wait, because the number of template instantiations depends on N, and the lookup time is dependent on the number of template instantiations, the lookup time is dependent on N, but AFAICT, it's commensurate (if by that you mean linear time complexity). Is that what you mean by commensurate?
I cannot see how this should be faster than a controlled meta-recursion with a break condition.
What's "controlled meta-recursion" and what's "a break condition". Is "a break condition" just the template recursion termination condition? Is "controlled meta-recursion" the recursion every 4 (or whatever) elements while for those 4 elements boost_pp is used to generate the member variables and access one of those 4 elements?
I expressed the above inartfully. I was just referring to the recursive at-metafunction of the vertical implementation that terminates once the relevant index is reached. The decltype-meta-at in a horizontal implementation visits every public baseclass as part of the lookup process. Even if a matching baseclass is found, the others will still be visited. This is not much of a problem, though. In most cases N is <15, and so this should not be relevant. It is much more important that the decltype-meta-at is not plain meta. As mentioned above, the argument matching process should be a lot more expensive than the simple meta-recursion.
On top of that your implementation is limited to compiler with decltype support. I tried to avoid implementations in which certain c++0x features depend on others. A user, whose compiler does support variadic templates but not decltype, should still be able to enjoy the variadic template candy. This is not much of a problem in our specific case but in other cases an independent implementation is crucial.
I hadn't thought that was important because I'd assumed that by the time variadic templates were adopted, decltype would surely be adopted.
From what I have heard, VC 10 does not support decltype. (AFAIK it does not support variadic templates either.) Anyway, the core language additions are way to complex to be adapted within one release cycle. Especially when it comes to more exotic compiler (such as IBM's C++ compiler for z/OS mainframes) adopting the full extend of c++0x will probably take decades.
Either way, there are tons of pros and cons for both of our implementations. I really do like your implementation. It looks and feels native. Maybe it faster than mine. Maybe it is not. Who knows? Compiler are too different to let one state performance predictions a priori. I judge compile-time performance of an expression by the number steps (and their orders of growth) involved into evaluating it, because I think, this is what comes closest to actual real-life performance in most cases. This led to my conclusion that an unrolled recursive implementation might be faster.
I attached a test driver to this post. The testcase instantiates 25*25 distinct tuples (either vertical or horizontal ones) with 0 to 10 elements. Then optionally a type (meta-at) and/or object lookup (at) is done on each element.
Very nice! I love the way you've filtered out anything that's "extraneous" both in the "vertical" (i.e. the boost_pp method) and the "horizontal" (the tagged multiple inheritance method). This makes it easier to see what's going on. However, I did have a hard time understanding how the test cases were generated. I added several comments which I hope make it clearer. I could upload this extra commented version to the boost vault under the variadic_template directory if you're interested.
Yeah, the code is a mess. Sorry. Go ahead and upload your version. It definitely will be helpful for other developers.
...
Yes. Thanks very much. I would like to see this test case as part of the fusion documentation so that others could see the advantage of BOOST_PP vs the Tagged MI option. Maybe it should be relegated to a separate directory for documentation of the implementation instead of including it in the user docs. That way it would be available for future maintainers but wouldn't distract current users.
That a good idea. Once (if?) I merge my branch to the trunk, I will get back to you.
...
Also, I've a strong suspicion that other's will suggest the code be modified, using maybe some BOOST_PP magic, to lessen the number of template instantiations. In particular, I suspect this will be suggested for where foldr_pack is used in the supertypes of the sequences. In particular, I'd think the technique you used in your test driver( in the VERTICAL part) could be used with some benefit there. The interesting thing is, the original mpl didn't do that, instead it used just plain template recursion. OTOH, maybe it wouldn't really be much use, but who knows?
I think both methods (unpacked vertical, horizontal) should be implemented and enabled/disabled on-the-fly based on empirically determined test results of the specific compiler (version). At least it makes sense in fusion as only the implementation of fusion::vector would need to be adjusted. Regards -Christopher