From: vesa_karvonen (vesa_karvonen_at_[hidden])
Date: 2002-03-08 10:11:50
--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> From: "vesa_karvonen" <vesa_karvonen_at_h...>
> > hmm... I've tried to use the same one character names for every
> > macro parameter used for the same purpose in the library, but
> > there are still many exceptions to the rules. I'll try to fix
> > those exceptions and add a separate page that explicitly explains
> > the naming of parameters.
>
> I'm sorry; I don't see how that's relevant.
Don't worry about it :). I'm just trying to find ways to minimize the
amount of documentation needed while making the documentation
accessible.
> My point was that the user needs to choose something to be passed
> for R when she invokes BOOST_PP_LIST_FOR_EACH_I(). In general,
> almost anything will do.
BOOST_PP_LIST_FOR_EACH_I(F,P,L) takes 3 parameters none of which is
named R. This is why I explained the difference between the generated
R and D parameters and the user specified P parameter.
The root cause for all this confusion is really the design of the C
preprocessor which does not allow recursion. The technique of passing
around explicit recursion depths (R and D parameters) is a technique
for overcoming this limitation of the C preprocessor.
> > > You could look at boost/python/converter/from_python_data.hpp
> > > for what I ended up with.
[...]
> > I think that it should be possible to achieve the same effect
> > using only MPL, which might be preferable.
>
> Trust me, the PP library was a last resort. It was too slow with
> various EDG compilers when I just used template metaprogramming.
That is quite interesting. Are you really saying that iteration using
BOOST_PP_LIST_FOR_EACH_I() in this case is faster than when using
boost::mpl::accumulate<>? The template metaprogramming version
potentially does the iteration many more times than the pp
metaprogramming version, but still it sounds quite odd. I suppose
that with precompiled headers, the pp metaprogramming version should
clearly be faster, because the iteration is then "unrolled".