Re: [boost] Re: Comments on the preprocessor list data structure

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-22 07:17:31

----- Original Message -----
From: "vesa_karvonen" <vesa_karvonen_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, January 22, 2002 4:45 AM
Subject: [boost] Re: Comments on the preprocessor list data structure

> --- In boost_at_y..., "Gustavo Guerra" <gustavobt_at_m...> wrote:
> [...]
> > 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've written a 2D repetition example that uses BOOST_PP_REPEAT_2ND()
> into the BOOST_PP_REPEAT() documentation. I plan to add a
> multidimensional repetition example into the BOOST_PP_FOR()
> documentation. Perhaps I'll write some documentation on the
> techniques used to avoid the limitations of the preprocessor.
>
> > > 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.
>
> I still think that the macro names are too long, but...

I would be willing to drop the _PP, as well. I have no problem with that:
ALL_CAPS names are implicitly preprocessor symbols, and I have no problem at
all saying that all other libraries (which aren't /about/ using the
preprocessor after all), should use some kind of namespacing for all
preprocessor symbols, e.g. BOOST_PYTHON_xxxxx.

-Dave