Boost logo

Boost :

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]
> [...]
> [...]
> 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

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

> 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.

> > - 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.



Boost list run by bdawes at, gregod at, cpdaniel at, john at