Re: Comments on the preprocessor list data structure

From: vesa_karvonen (vesa_karvonen_at_[hidden])
Date: 2002-01-22 04:45:51

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

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

I guess I'll just commit the list data structure with the LIST prefix
so that people can test it out. It should be possible to provide or 
change to using shorter names later.