-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] 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