Re: Preprocessor library updates (Re: [boost] PREPROCESSOR -> PP ?)

From: Vesa Karvonen (vesa.karvonen_at_[hidden])
Date: 2002-01-03 06:55:39

From: "Greg Colvin" <gcolvin_at_[hidden]>
> From: "Vesa Karvonen" <vesa.karvonen_at_[hidden]>

> > I have also continued R&D of list functionality. The following primitives
are
> > now implemented, but not added to CVS.
> >
> >     BOOST_PP_LIST_NIL
> >     BOOST_PP_LIST_CONS(H,T)
> >     BOOST_PP_LIST_IS_CONS(L)
> >     BOOST_PP_LIST_IS_NIL(L)
> >     BOOST_PP_LIST_HEAD(L)
> >     BOOST_PP_LIST_TAIL(L)
> >
> >     BOOST_PP_LIST_APPEND(L,R)
> >     BOOST_PP_LIST_AT(L,I)
> >     BOOST_PP_LIST_CAT(L)
> >     BOOST_PP_LIST_FOLD_LEFT(F,R,L)
> >     BOOST_PP_LIST_FOLD_RIGHT(F,L,R)
> >     BOOST_PP_LIST_ITER(F,P,L)
> >     BOOST_PP_LIST_MAP(F,P,L)
> >     BOOST_PP_LIST_REVERSE(L)
> >     BOOST_PP_LIST_SIZE(L)
> >
> > (The names are a mix of Lisp, Ocaml and C++.)
>
> Such a motley collection of languages.

True. I definitely try to make the names as sensible as possible. I'll see if
I can use naming similar to the one used in MPL. The MPL data structures /
algorithms are, of course, somewhat more sophisticated. Similar techniques
(namely separating iteration from the data structure) could be used with the
preprocessor, but it is difficult to see considerable benefit in doing so.

I've found some potential use for the list primitives. See this:

    http://www.boost.org/libs/preprocessor/doc/tutorial.htm#Token%20Look-Up

Using the list functionality, the token look-up function could be replaced by
a single list:

  #define ARITHMETIC_TYPES\
    BOOST_PP_LIST_CONS(bool,\
    BOOST_PP_LIST_CONS(char,\
    BOOST_PP_LIST_CONS(signed char,\
    BOOST_PP_LIST_CONS(unsigned char,\
    BOOST_PP_LIST_CONS(short,\
    BOOST_PP_LIST_CONS(unsigned short,\
    BOOST_PP_LIST_CONS(int,\
    BOOST_PP_LIST_CONS(unsigned int,\
    BOOST_PP_LIST_CONS(long,\
    BOOST_PP_LIST_CONS(unsigned long,\
    BOOST_PP_LIST_CONS(float,\
    BOOST_PP_LIST_CONS(double,\
    BOOST_PP_LIST_CONS(long double,\
    BOOST_PP_LIST_NIL)))))))))))))

And then LIST_ITER can be used to generate code using the list:

  #define BOOST_PP_DEF(I,_,T)\
    catch (T t)              \
    { report_typeid(t);      \
      report_value(t);       \
    }
  BOOST_PP_LIST_ITER(BOOST_PP_DEF,_,ARITHMETIC_TYPES)
  #undef BOOST_PP_DEF

The advantage in using this technique is that a smaller number of macro
definitions is needed for the look-up data.

> > The next thing on my list is to implement arithmetic operations using a
list
> > representation of numbers so that arithmetic performance may be improved.

I made a shot at implementing ADD using a list representation, but the results
were not very promising. It was not faster enough on an EDG based compiler
that it would be worth replacing the current implementation. However, there
are many ways in which the code could have been optimized, so I'll probably
retry when I have time.

> So does this mean that the C preproccessor is Turing-complete?

It is impossible to create a finite preprocessor program that does not
terminate (at least if we ignore compiler bugs).