Macros and Templates

C macros (#defines) typically are entirely expanded by the preprocessor, so that the declarations of the macros become inaccessible to the parser and compiler. In C++ inline procedures and templates allow to define some kind of less transparent macros, whose definitions are accessible to the compiler. A cross compiler from C into other languages also should be capable of accessing macro definitions, so that macros can be translated into named constants, procedures or other elements of the target language. This document describes an attempt to wrap C macros into some kind of templates.

General Idea

The general idea is a multi-level macro definition and evaluation, with a template-like wrapper around a macro. The wrapper has 2 purposes:

Macro Definition

The macro definition is recorded according to the C specs, and then is wrapped into a template. After the definition a one-time expansion of the definition may be required, so that the parser can e.g. recognize the macro as the definition of a named constant or (inline) procedure.

Macro Expansion

In most cases a wrapped macro is never expanded again, instead the name and optional argument lists are passed through to the parser without modifications. This mechanism disallows the use of preprocessor operators (# and ##) in the macro bodies, because such operators are evaluated during macro expansion. One workaround for this restriction might result in additional arguments to the original macro argument list, which receive the evaluated expressions. The macro wrapper then must evaluate the preprocessor expressions and put the results into the extended macro argument list. Then the macro identifier and the extended argument list can be passed to the parser, just as the expanded macro would be passed for not-wrapped macros. Currently no such special treatment will be implemented, because it would be easier to write according wrappers as already available C macros.

The occurence of a wrapped macro symbol in the source code will usually trigger no special actions, no macro expansion is required.

Operation Sequence

A macro can be wrapped before or after its definition. Wrapping before definition may sound strange, but that's just the preferable way. When the wrapping occurs somewhere between the macro definition and its first use, then the according instructions (#pragma) must be inserted into the source files, best immediately following the macro definition. But when then another version of the same source file becomes available, all the changes must be inserted into that new file again. That's a lot of work <sigh, I know that>, which is not required when macros can be wrapped before their definition.

So the macro wrappers shall be constructed first and entered into the preprocessor symbol table, as placeholders for the macro definitions to come. After a subsequent macro definition the existence of an wrapper of the same name can be detected, whereupon the definition is inserted into the wrapper, not into the symbol table. An #undef must be handled in the same way.

The wrapper definitions can be separated from the related source files, e.g. the wrappers for foo.h can be placed into foo.h.wrap. When then a source file is #included, the preprocessor can automagically detect the existence of an associated wrapper file, and can process that wrapper file before the source file.

As outlined above, the definition of a wrapped macro will result in a one-time expansion of the wrapper and macro, in a form that is understandable to the C parser.

Syntax

The C++ template definitions are hard to parse, due to the overloaded uses of angle brackets '<' and '>'. Since I don't want to implement an C++ parser now, the #define syntax also should be used with macro wrappers. The most obvious modification is the substitution of "#define" by e.g. "#pragma Define", the remaining parts (argument list and body) can be treated as with #define. Inside the wrapper definition special tokens must be reserved or defined, for references to the macro name and the macro body. Herefore the already defined preprocessor operators can be overloaded, with '#' for the macro name and '##' for the macro body.

Another pragma may be useful to define standard wrappers, so that the translation of a macro definition must not be repeated for every single #define. This pragma can be named #pragma Template.

Here some examples for the intended use of macro wrappers:

Simple Named Constants

#pragma Template __Const const # = ##;
#pragma Define ACONST __Const
#define ACONST 88

will result in

const ACONST = 88;

Typed Constants

#pragma Template __TypedConst(t) const t # = ##;
#pragma Define TCONST __TypedConst(char *)
#define TCONST "version 1.5"

will result in

const char * TCONST = "version 1.5";

For more complex types the macro name placeholder may be inserted explicitly into the type specification:

#pragma Template __ComplexConst(n) const n = ##;
#pragma Define TCONST __ComplexConst(char *#[dim])

It may be useful do specifiy the types of the wrapper arguments, so that e.g. "type t" can be recognized and treated like an anonymous declarator. But then the type specification must be parsed by the preprocessor, so that the argument name can be inserted in the appropriate place.

Procedures

For procedures the definition of the appropriate result type and argument types may be required. This can be done in arguments to the Define pragma, which either can be position dependent, or which can be distinguished by parentheses around the argument list. When an argument list is specified, it is automatically inserted after the macro name placeholder.

#pragma Template __Proc inline void # {##; };
#pragma Template __Func(t) inline t # { return ##; };
#pragma Define foo __Proc((const char *s))
#pragma Define min __Func(int, (int a, int b))
#define foo(s) puts(s)
#define min(a,b) (a) <= (b) ? (a) : (b)

will result in

inline void foo(s) { puts(s); };
inline int min(int a, int b) { return (a) <= (b) ? (a) : (b); };

Alternatively the old-style procedure declaration syntax can be used, with only argument names in the argument list, and argument declarations being inserted between the procedure declarator and body.

#pragma Template __Func(t, args...) inline t # args { return ##; };
#pragma Define min __Func(int, int a;, int b;)

resulting in

inline int min(a, b) int a; int b; { return (a) <= (b) ? (a) : (b); };

But then both the Define and the expansion don't look very nice.

Implementation

According to the above suggestions the following items have to be implemented:

Pragma recognition
Treatment of #defines
Wrapper templates
Wrapper arguments and placeholders
Wrapper expansion
Handling of constant expressions

In a first implementation the wrapper templates will be implemented as macros, which are expanded when the wrapper is expanded.

A #pragma "Define" must be recognized, which triggers the usual processing for a #define. The type of the crated macro object must be an appropriate wrapper object (subclass of the macro class). The wrapper object is specially marked in the preprocessor symbol table, for appropriate handling of a subsequent #define of the same name.

The wrapper arguments and placeholders may require modifications of the standard macro methods, both during the definition and expansion of an wrapper. Wrapper arguments may not be subject to a prescan or automatical expansion, the arguments themselves can be wrapped into an expander macro whenever an expansion may be required, e.g. #define _(x) x. During wrapper expansion the wrapper placeholders have a special meaning, perhaps best implemented in virtual methods of the macro/wrapper classes.

Wrapper objects are automatically expanded after a #define of the same name. The macro object, created by the #define, is stored in a field inside the wrapper object.

The handling of constant expressions in the preprocessor and parser may deserve modifications. The preprocessor should access the expanded values of all macros, even when the macros are wrapped. The parser instead should not normally try to evaluate constant expressions, instead expressions should be parsed literally to the compiler, with unexpanded wrapped macros. Unwrapped macros of course are expanded by the preprocessor, it's up to the user to specifiy which macros deserve expansion by the preprocessor, and which macros should be wrapped for handling in the compiler. With regards to the preprocessor, the handling of wrapped macros can be reduced to the mere fact that wrapped macros never must be expanded. All further handling of wrapped macros then can be implemented in the compiler. OTOH the compiler then must know about the macro objects, as created by the preprocessor. This requires at least a specific macro interface for use by the compiler, and then the usability of the already existing macro methods by the compiler is desireable.

Extensions

Some extensions to the outlined wrapping mechanism can be useful. A first extension should allow to convert multiple #defines into an Enum. The implementation of such a feature requires one or two additional pragmas, indicating the begin and end of the synthetic enum definition. The #defines for the enum members deserve special handling, so that the final enum definition can be passed to the parser in correct C syntax. OTOH it may be easier to construct the enum on the fly, bypassing the C parser.

A related extension is the definition of Sets, when the target language supports both enums and sets. In this case all related #defines with values of 2^n are converted into enum members of ordinality n. Other values must be translated into set constants of the underlaying enum.