RE: [boost] Re: Wave C++ Review Begins Today - February 7, 2005

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-02-09 17:43:51

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Hartmut Kaiser

> > ________________________________________________________
> > 3. preface.html: sentence
> > 
> > "...is by far one of the most powerful compile-time
> >     reflection/metaprogramming facilities that any
> >     language has ever supported."
> > 
> > may be questioned by those using Lisp ;-)
> 
> Haha! No religious war please!

Indeed. :) I think that is a partial quote from me.  Lisp and Scheme certainly
have powerful macro systems.  However, Lisp/Scheme macros cannot generate nor
deal with syntactically invalid code.  I.e. the C preprocessor, while certainly
not as powerful as the Lisp or Scheme macro systems, is more powerful in certain
areas--like the deferral of syntactic correctness.  A very simple example:

#define RBRACKET ]

int array[ RBRACKET = { ... };

This may not seem like it is very useful, but with preprocessor metaprogramming
it is.  Unlike the Lisp and Scheme macro systems, the preprocessor doesn't
manipulate/transform expressions (i.e. syntactic elements in general).  Instead,
it writes them as tokens in arbitrary order.  Combined with template
metaprogramming, it *is* one of the most powerful compile-time
reflection/metaprogramming facilities--though I agree that it isn't at the very
top of that list (which would more likely be Scheme's hygienic system in
particular).  An intentional environment would easily surpass all of these
languages.

> > ________________________________________________________
> > 5. Is it possible to set language mode (C99, C++98)
> >    per individual file (or directory)?
> 
> Should be possible, but I'll have to investigate this 
> further. Will report back on this later.

I'm not sure that this is a good idea.  I assume that you (Pavel) are referring
to inside a single translation unit, such as, for example, 'a.c' includes both
'b.h' and 'c.h' but includes 'b.h' as C++ and 'c.h' as C.  The differences in
the preprocessor between C and C++ are few, though C's is currently better.
You'd be better off just enabling the "new" C features in C++.

> > ________________________________________________________
> > 7. There should be example(s) with
> >    #pragma wave system
> >    in supported_pragmas.html.
> > 
> > (This feature may show _very_ useful, IMHO.)
> > 
> > Other pragmas may also have examples in docs.

Note, BTW, that one of the features of C99 that isn't present in C++ is the
_Pragma operator.  It acts just like #pragma, but it can be the result of macro
expansion.  Wave supports this and there are some pragmas that are executed
mid-macro expansion.  "system" is one of those.  Likewise, the "trace" pragma,
which can be used to trace macro expansion, is executed mid-expansion.

> Could you elaborate, please?
> 
> > ________________________________________________________
> > 12. Wishes:
> > 
> > a. Check for digraphs/trigraphs. Maybe driver could have
> >     option that checks presence of digraphs and trighraphs
> >     and reports error when it found some.
> > 
> >     It may be used e.g. to check computer generated
> >     random string tables.

Trigraphs are technically single characters (rather than token spellings).  They
are translated into their equivalents in phase one.  This is why trigraphs are
replaced inside string literals.  Digraphs, OTOH, are distinct tokens that
semantically mean the same thing as their equivalents.  They are not subject to
any kind of "replacement".  A would-be digraph in a string literal is simply not
a digraph.

> 
> This can be implemented by a special driver program which 
> analyses the tokens returned by the preprocessor iterators. 
> The trigraph tokens are flagged as such, so this should be 
> possible already.
> 
> > b. Sometimes it may be useful to be able to "partially
> >     preprocess" given source. E.g. I would like to
> >     have cleaner version of STLport just for my platform.
> > 
> >     It would be nice if I could specify list of
> >     #defines and #undefines to be processed, the rest
> >     left as is.
> 
> Hmmm, that's more complex, I'll have to think about this.

That is actually a lot more complex.  It implies a heavy duty dependency
analysis on, for example, macros.  I think that implementing this would be more
complex (to do correctly) than the entire preprocessor altogether.

Regards,
Paul Mensonides