On 22/04/14 18:38, Solal wrote: > I've got ideas for improve the preprocessor with specific features. > > The basic idea is to make the preprocessing language a complete > programming language. > That can be useful for includes things like Autotools and advanced > Makefiles directly in the source code, and have just a tiny Makefile for > compile. > > 0. Multiple defines on one variable. > The "constants" will be transformed in "variables". > > 1. Assertions > #assert <CONDITION> <COMMAND-TO-EXECUTE-CONDITION-IS-FALSE> > will be transformed in : > #if !<CONDITION> > #<CMD> > #endif > (And will be of course re-preprocessed.) > > 2. Calculating > #calculate <VAR> <CALCUL> > will be transformed in : > #define <VAR> <RESULT> > (And will be of course re-preprocessed.) > Example : > #calculate N 1+1 > will be transformed in : > #define N 2 > (That can works with any type : bools, etc.)
Much is already handled by the compiler today - "#define N (1 + 1)" will work just as well as "#define N 2". I think a lot of the potential advanced uses of such pre-processor "magic" can be better handled by C++ "constexpr" (and possibly template calculations). For my 2 cents, I would think it would be a far better idea to make a gcc extension to C to support C++ "constexpr" in C mode. It would have much more potential uses, be consistent with C++, and be consistent with the gcc extension tradition of supporting useful C and C++ features for both languages. > > 3. Executing shell commands > #exec-sh <VAR> <SHELL-COMMAND> > The shell command <SHELL-COMMAND> while be executed and the result > (stdout) of the shell command will be putted in <VAR> This screams "security hole" so loudly that it could never be considered. People understand that running "make" can call arbitrary programs - people do not expect /compilers/ to do so. > > 4. Read and write files > #read-file <VAR> <FILENAME> > will put the content of the file <FILENAME> in <VAR>, and if <VAR> is > modified, <FILENAME> is modified too. > Again, this is stepping /way/ outside the appropriate bounds of a built-in pre-processor. I don't disagree with the idea of improving upon autotools. But I don't think adding features to the pre-processor is the way to go. The C pre-processor is a historic relic that exists because C/C++ does not have proper modules (hence "#include"), it did not have proper constants (hence "#define ARRAY_SIZE 100" macros), it did not have inline functions (hence "#define VECTOR_SIZE(x, y) sqrt((x), (y))" macros), and it did not have templates, typedefs, and many other features of modern C and C++. It would be far more useful to work towards eliminating the use of the pre-processor, rather than extending it. Some of that can be done by porting C++ features into C (as gcc extensions, until the happy day when they hopefully get included in the standards) - "constexpr" is one, and the greater flexibility of "const" and "static const" as compile-time constants (for things like array size and switch labels, which are legal in C++ but not C). The big step would be to support modules in cooperation with LLVM, and thus eliminate "#include": <http://clang.llvm.org/docs/Modules.html> <http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf>
