Re: Comments on the preprocessor list data structure

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

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

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:

  BOOST_PP_T_xxx
  BOOST_PP_L_xxx

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