Boost logo

Boost :

From: vesa_karvonen (vesa_karvonen_at_[hidden])
Date: 2002-01-21 17:33:42

--- In boost_at_y..., "Gustavo Guerra" <gustavobt_at_m...> wrote:
> From: "vesa_karvonen" <vesa_karvonen_at_h...>
> > Currently the _R postfix is reserved for a
> > special use (see BOOST_PP_FOR() documentation)

> Do they really conflict? Isn't _R just used in BOOST_PP_FOR_R?

It is also used in BOOST_PP_LIST_FOR_EACH_R. I'd like to reserve the
_R and _D (and possibly _DR) postfixes to those specific functions
that are implemented in terms of BOOST_PP_FOR or BOOST_PP_WHILE,

The _R indicates that the BOOST_PP_LIST_FOR_EACH is implemented using
BOOST_PP_FOR. This way it is possible to call

I know that the _R and _D postfixes are not ideal, nor is invoking
functions directly using ##, nor is having two versions of a function
(with and without the postfix), but I think that it is the best that
can be done within the C++ preprocessor limitations.

Hey, I don't have to apologize for the C++ preprocessor! :)

> > Of course, I'm not ignoring the problem that it may be a little
> > bit more difficult to learn to use the data structures at first,
> > because the prefixes do give some cognitive context.
> Although I like short names, I think ommiting the type altogether
> might be confusing. I suggest BOOST_PPL_xxx for lists and
> BOOST_PPT_xxx for tuples?

I don't want to catenate the data structure prefix with the library
prefix. If we want to use single character prefixes, I'd pick:


"PP?" might be a nice prefix for some other library.

> For consistency, you could rename others to BOOST_PPA_xxx(or
> BOOST_PPI_xxx) for operations on aritmetic(or integer) types,
> BOOST_PPB_xxx for operations that expect boolean values, and
> so on?

hmm... It is difficult to say whether it would be worth it. I would
guess that at some point the library might include support for
arbitrary precision arithmetic (implemented using lists), but then it
would be possible to simply distinguish those macros from the
original token based arithmetic macros.

Thanks for bringing up the length issue. I have been concentrating on
other issues, so I have not paid much attention to the length of the
list macros. I think that BOOST_PP_TUPLE_ELEM and the list macros
should really be made shorter unless the shorter names are deemed too

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