Boost logo

Boost :

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-11-07 22:02:46

"Edward Diener" <eddielee_at_[hidden]> wrote in message
> "Paul Mensonides" <pmenso57_at_[hidden]> wrote in message
> news:001601c286c9$64eedf40$6401a8c0_at_c161550b...
> > "Andrei Alexandrescu" <andrewalex_at_[hidden]> wrote in message
> > news:aqf13l$f7e$
> > > A very nice Spirit code sample would be the proverbial dogfood that
> > eats
> > > itself. To clarify:
> > >
> > > 1. How about an open-source C++ preprocessor (that takes care of
> > and
> > > #include) written in Spirit? Then that preprocessor could be compared
> with
> > > existing preprocessors in terms of speed and conformance.
> >
> > This one I'd like to see, but it might be too easy. There isn't much to
> > Cpp.
> Having tried it many years ago in C++ using Yacc/Lex, it is not nearly as
> easy as it looks. The most difficult area is macro expansion and
> substitution.

It may be difficult with a framework like that, but it isn't particularly
difficult doing it manually. Tokenizing is trivial, far simpler than
regular C++, and the syntax for macro expansion is also very simple. The
most "difficult" parsing that needs to be done is arithmetic expressions in
#if/#elif directives.

> The other thing to look out for, which is a non-standard
> problem, is that every compiler of which I know defines their own macros
> based on compiler options and programmers often use these macros to
> or not include lines of code. Finally there is the recursive inclusion of
> header files, each with their own preprocessor directives.

Yes. This is a problem. The only real way to handle it is to define those
symbols externally so they can be setup by a user.

> Of course it is much easier than the rest of the C++ language but I don't
> think anyone should underestimate how difficult it might be.

Don't overestimate it either. :) Of course, dealing with regular C++ on the
other hand....

Paul Mensonides

Boost list run by bdawes at, gregod at, cpdaniel at, john at