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

Subject: Re: [boost] [Fusion] port to c++0x
From: Larry Evans (cppljevans_at_[hidden])
Date: 2009-09-24 10:44:40

On 09/23/09 14:47, Christopher Schmidt wrote:
 > Larry Evans schrieb:
 >> by using the "tagged multiple inheritance"(TMI) method shown
 >> around here:
 >>
 >> 
https://svn.boost.org/trac/boost/browser/sandbox/variadic_templates/libs/mpl/sandbox/tuple_non_recur.package_range_c.cpp#L53 

 >>
 > ...
 >>
 >> The only other objection might be to limit the number of instantiations
 >> because the more template instantiations, the slower the compile
 >> time; however, Doug Gregor suggested he wasn't too worried
 >> about that at the bottom of:
 >>
 >>   http://groups.google.com/group/comp.std.c++/msg/6449d909fd3d5cdc
 >>
 >> -regards,
 >> Larry
 >
 > Thank you very much for your feedback.
 >
 > I did consider that specific method. I decided against using it due to
 > the enormous amount of template instantiations and the expensive
 > type_at. The current implementation is 4-unrolled recursive. I am pretty
 > certain that it is faster - there are about 4 to 8 times less template
 > instantiations.

There's no type_at in:

 
https://svn.boost.org/trac/boost/browser/sandbox/variadic_templates/libs/mpl/sandbox/tuple_non_recur.package_range_c.cpp

There is, however, a tuple<,>::at_type<I> nested struct.  Is that what
you're referring to?  If so, I don't understand why that would be
expensive since neither at_type or what it calls, at_elem, use
recursion. Could you explain why at_type would be expensive?  Or maybe
you've run some timing tests on it.  If so, could you provide the test
driver so I could test to see why it's so expensive?

Now, AFAICT, the number of template instantiations is, neglecting
those needed for the package_range_c at:

https://svn.boost.org/trac/boost/browser/sandbox/variadic_templates/libs/mpl/sandbox/tuple_non_recur.package_range_c.cpp#L54

which (as Doug mentioned near the bottom of his 12 Jan 2009 post) are
amortized, the number of "overhead" template instantiations is N+C
where N is the number of elements and C is a small constant.  I think
C would be around 1, i.e. 1 for _Tuple_impl.  The N is for the N
_Tuple_element<Tag,Value> values where Tag is some instance of
mpl::integral_c<IndexType,IndexValue>.  By "overhead" I means the
number needed besides the N for each element in the tuple and the 1
for the overall tuple (in the case of vector, that would be
mpl::vector).

Does that make sense?

TIA.

-Larry