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
> > "Andrei Alexandrescu" <andrewalex_at_[hidden]> wrote in message
> > news:aqf13l$f7e$1_at_main.gmane.org...
> > > 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
> > > 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
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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk