Re: [boost] [Fusion] port to c++0x

Subject: Re: [boost] [Fusion] port to c++0x
From: Christopher Schmidt (mr.chr.schmidt_at_[hidden])
Date: 2009-09-30 14:28:58

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