Re: [boost] Review: preprocessor library

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-06-29 10:27:53

On Friday 29 June 2001 09:29, you wrote:
> From: "Douglas Gregor" <gregod_at_[hidden]>
>
> > I believe that the preprocessor library should be accepted into Boost.
> >
> > As a reasonable testcase for the preprocessor library, I converted
> > Boost.Function to use the preprocessor library. I'll relate my
> > experiences when performing this conversion first, and then I have a set
> > of specific comments.
>
> Thank you very much for your review, testcase and comments.
>
> [snip lots of stuff]
>
> >       typename R BOOST_PREPROCESSOR_IF(BOOST_FUNCTION_NUM_ARGS, \
> >                    BOOST_PREPROCESSOR_COMMA,                    \
> >                    BOOST_PREPROCESSOR_EMPTY)()                  \
>
> [...]
>
> >                 BOOST_PREPROCESSOR_IF(i,                        \
> >                   BOOST_PREPROCESSOR_COMMA,                     \
> >                   BOOST_PREPROCESSOR_EMPTY)()                   \
>
> [...]
>
> BTW, you could use BOOST_PREPROCESSOR_COMMA_IF() here.

But that would have made things so much less interesting :)

> > ----------Specific Comments--------
> >
> > Usage & headers:
> > - The enumeration of shifted parameters should go from 1 to n, not 1 to
> > (n-1). The current behavior is quite surprising and I don't see any
>
> rationale
>
> > behind it.
>
> This can be changed if so desired. I agree that without considering a
> specific application of the shifted parameter enumeration macro, this seems
> like an inconsistency. Another solution would perhaps be to rename
> ENUM_SHIFTED_PARAMS. The following decribes the rationale behind the
> current implementation.
>
> The rationale, which I failed to include in the rationale documentation, is
> that repetition from 1 to N-1 makes it easier to perform "parameter
> shifting" (hence "SHIFTED") of actual rather than formal parameters, which
> is the intended application of ENUM_SHIFTED_PARAMS. Parameter shifting is a
> rather general technique for implementing metaprogramming primitives that
> take lists of types. Parameter shifting can often help to avoid syntactic
> clutter (while using) and avoid O(N**N) repetition (while implementing).
>
> Consider the following (longish, but actual) example, which is an
> implementation of a "type match" control structure, which is a generalized
> version of meta switch case. Among other interesting uses, the type match
> control structure can, with suitable predicates and other helpers, be used
> as a replacement for the (IF and) SWITCH and EVAL_DEPENDENCY_TABLE
> primitives presented in Czarnecki & Eisenecker.
>
> I have added a couple of comments to document the design, but I assume that
> readers are familiar with template metaprogramming.
>
[snip code]
>
> As you can see, if the shifted parameter enumeration macro would repeat
> from 1 to N, it would be necessary to explicitly decrement the
> BOOST_TMPL_TYPE_MATCH_MAX before passing it to
> BOOST_PREPROCESSOR_ENUM_SHIFTED_PARAMS.

I see. A little bit of documentation on the 
BOOST_PREPROCESSOR_ENUM_SHIFTED_PARAMS will clear everything up, then.

> > - Perhaps a "enumerate shifted parameters with defaults" should be added,
> > to be consistent with the unshifted version.
>
> This can be done if so desired. Considering:
> - preference of 0-based indexing and 1-based naming, and
> - the use of shifted enumeration on actual rather than formal parameters,
> this issue may need further discussion.

I see no reason to add the "enumerate shifted parameters with defaults" macro 
given the explanation of the meaning of "shifted" parameters.

> Another solution might be to rename ENUM_SHIFTED_PARAMS to something like
> ENUM_SHIFTED_ACTUAL_PARAMS in order to hilite the intent.

I would advise against this if only because the macro names are already quite 
long.

> However, if there really is use for shifted formal parameters, then IMO,
> shifted enumeration with detaults should be supported.

I was just being adamant about using 1-based parameter names. It really 
doesn't matter either way.

[snip]
> > - The macro names in the tutorial don't have the BOOST_PREPROCESSOR_
> > prefix, but they probably should.
>
> Ok. The intention was to make the examples more readable, by omitting the
> prefixes, but it probably makes the examples less readable, and certainly
> harder to try them out.

Or you could state somewhere that the prefix as been omitted to make the 
examples more readable.

[snip]

        Doug