Boost logo

Boost :

From: Gustavo Guerra (gustavobt_at_[hidden])
Date: 2002-01-21 18:11:20


> 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! :)

No, you do not :)

I still didn't get quite well that _D and _R stuff (neither the REPEAT_2ND
and REPEAT_3RD FWIW). I think you should try to explain those a little
better on your docs, and how one can take advantage on that. Or maybe I'm
just slow :)

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

Uhm, maybe, but I doubt it. But that BOOST_PP_?_xxx just doesn't look good
to me.

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

Well, I think I'm just lazy and don't like to type much :) I think the big
problem was solved with the switch from PREPROCESSOR to PP. The stuff I had
using the old names were almost incomprehensible, but now it looks good. So,
don't worry too much on small differences of 2 ou 3 characters between
names.

Regards
Gustavo Guerra


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk