This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C PreProcessor GCC-specific features ideas.

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
> 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":


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]