Re: [boost] Preprocessor Docs Comments

From: Darren Cook (darren_at_[hidden])
Date: 2003-10-14 06:20:16

Thanks for the reply, and the example.

> The library is effectively a programming language.

I guess I'm after the "O'Reilly Boost.Preprocessor Cookbook" in that case :-).

> It does have a consistent layout and style.  Both of these two issues
> are the result of viewing the page outside of the frame 

Sorry I didn't think about that - I tend to open most links in a new tab. I 
still think frames should have descriptive titles though. Also useful for 
search engines.

>>      a) What feature each of the three headers is loading in.
> 
> <inc.hpp> brings in BOOST_PP_INC, <comma_if.hpp> brings in
> BOOST_PP_COMMA_IF, and <repetition.hpp> brings in BOOST_PP_REPEAT and
> BOOST_PP_ENUM_PARAMS.  These things should be self-evident though.

Yes, I worked out three, but BOOST_PP_ENUM_PARAMS is non-obvious. I just 
wanted more hand-holding as this was the first example I'd come to.

>>      c) If "MAX_IS_FUNCTION_TESTER_PARAMS" is required, or
>>if 15 can be 
>>directly embedded, e.g.:
>>        BOOST_PP_REPEAT(BOOST_PP_INC(15), IS_FUNCTION_TESTER, _)
> 
> Yes, it can be.  However, the intent is to make the code expand to some
> arity specified elsewhere as a configuration option.
> MAX_IS_FUNCTION_TESTER_PARAMS is just used for a default value.

In that case maybe that is the intermediate step I was suggesting - first 
with 15 hard-coded (keeping the example shorter and less intimidating), and 
then a revision to show how to use a configuration option and supply a default.

> by a library element.  Also, I don't recommend using all-caps
> identifiers for *temporary* macro names--using all-caps here actually
> *increases* the likelihood of a name conflict.

Interesting - it seemed very strange however to see lower-case defines in 
your example. I'm not sure I could get used to that!

Darren