| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A macro is a fragment of code which has been given a name. Whenever the name is used, it is replaced by the contents of the macro. There are two kinds of macros. They differ mostly in what they look like when they are used. Object-like macros resemble data objects when used, function-like macros resemble function calls.
You may define any valid identifier as a macro, even if it is a C
keyword. The preprocessor does not know anything about keywords. This
can be useful if you wish to hide a keyword such as const from an
older compiler that does not understand it. However, the preprocessor
operator defined (see section 4.2.3 Defined) can never be defined as a
macro, and C++'s named operators (see section 3.7.4 C++ Named Operators) cannot be
macros when you are compiling C++.
An object-like macro is a simple identifier which will be replaced by a code fragment. It is called object-like because it looks like a data object in code that uses it. They are most commonly used to give symbolic names to numeric constants.
You create macros with the `#define' directive. `#define' is followed by the name of the macro and then the token sequence it should be an abbreviation for, which is variously referred to as the macro's body, expansion or replacement list. For example,
#define BUFFER_SIZE 1024 |
defines a macro named BUFFER_SIZE as an abbreviation for the
token 1024. If somewhere after this `#define' directive
there comes a C statement of the form
foo = (char *) malloc (BUFFER_SIZE); |
then the C preprocessor will recognize and expand the macro
BUFFER_SIZE. The C compiler will see the same tokens as it would
if you had written
foo = (char *) malloc (1024); |
By convention, macro names are written in upper case. Programs are easier to read when it is possible to tell at a glance which names are macros.
The macro's body ends at the end of the `#define' line. You may continue the definition onto multiple lines, if necessary, using backslash-newline. When the macro is expanded, however, it will all come out on one line. For example,
#define NUMBERS 1, \
2, \
3
int x[] = { NUMBERS };
==> int x[] = { 1, 2, 3 };
|
The most common visible consequence of this is surprising line numbers in error messages.
There is no restriction on what can go in a macro body provided it decomposes into valid preprocessing tokens. Parentheses need not balance, and the body need not resemble valid C code. (If it does not, you may get error messages from the C compiler when you use the macro.)
The C preprocessor scans your program sequentially. Macro definitions take effect at the place you write them. Therefore, the following input to the C preprocessor
foo = X; #define X 4 bar = X; |
produces
foo = X; bar = 4; |
When the preprocessor expands a macro name, the macro's expansion replaces the macro invocation, then the expansion is examined for more macros to expand. For example,
#define TABLESIZE BUFSIZE
#define BUFSIZE 1024
TABLESIZE
==> BUFSIZE
==> 1024
|
TABLESIZE is expanded first to produce BUFSIZE, then that
macro is expanded to produce the final result, 1024.
Notice that BUFSIZE was not defined when TABLESIZE was
defined. The `#define' for TABLESIZE uses exactly the
expansion you specify--in this case, BUFSIZE---and does not
check to see whether it too contains macro names. Only when you
use TABLESIZE is the result of its expansion scanned for
more macro names.
This makes a difference if you change the definition of BUFSIZE
at some point in the source file. TABLESIZE, defined as shown,
will always expand using the definition of BUFSIZE that is
currently in effect:
#define BUFSIZE 1020 #define TABLESIZE BUFSIZE #undef BUFSIZE #define BUFSIZE 37 |
Now TABLESIZE expands (in two stages) to 37.
If the expansion of a macro contains its own name, either directly or via intermediate macros, it is not expanded again when the expansion is examined for more macros. This prevents infinite recursion. See section 3.10.5 Self-Referential Macros, for the precise details.
You can also define macros whose use looks like a function call. These are called function-like macros. To define a function-like macro, you use the same `#define' directive, but you put a pair of parentheses immediately after the macro name. For example,
#define lang_init() c_init()
lang_init()
==> c_init()
|
A function-like macro is only expanded if its name appears with a pair of parentheses after it. If you write just the name, it is left alone. This can be useful when you have a function and a macro of the same name, and you wish to use the function sometimes.
extern void foo(void); #define foo() /* optimized inline version */ ... foo(); funcptr = foo; |
Here the call to foo() will use the macro, but the function
pointer will get the address of the real function. If the macro were to
be expanded, it would cause a syntax error.
If you put spaces between the macro name and the parentheses in the macro definition, that does not define a function-like macro, it defines an object-like macro whose expansion happens to begin with a pair of parentheses.
#define lang_init () c_init()
lang_init()
==> () c_init()()
|
The first two pairs of parentheses in this expansion come from the
macro. The third is the pair that was originally after the macro
invocation. Since lang_init is an object-like macro, it does not
consume those parentheses.
Function-like macros can take arguments, just like true functions. To define a macro that uses arguments, you insert parameters between the pair of parentheses in the macro definition that make the macro function-like. The parameters must be valid C identifiers, separated by commas and optionally whitespace.
To invoke a macro that takes arguments, you write the name of the macro followed by a list of actual arguments in parentheses, separated by commas. The invocation of the macro need not be restricted to a single logical line--it can cross as many lines in the source file as you wish. The number of arguments you give must match the number of parameters in the macro definition. When the macro is expanded, each use of a parameter in its body is replaced by the tokens of the corresponding argument. (You need not use all of the parameters in the macro body.)
As an example, here is a macro that computes the minimum of two numeric values, as it is defined in many C programs, and some uses.
#define min(X, Y) ((X) < (Y) ? (X) : (Y)) x = min(a, b); ==> x = ((a) < (b) ? (a) : (b)); y = min(1, 2); ==> y = ((1) < (2) ? (1) : (2)); z = min(a + 28, *p); ==> z = ((a + 28) < (*p) ? (a + 28) : (*p)); |
(In this small example you can already see several of the dangers of macro arguments. See section 3.10 Macro Pitfalls, for detailed explanations.)
Leading and trailing whitespace in each argument is dropped, and all whitespace between the tokens of an argument is reduced to a single space. Parentheses within each argument must balance; a comma within such parentheses does not end the argument. However, there is no requirement for square brackets or braces to balance, and they do not prevent a comma from separating arguments. Thus,
macro (array[x = y, x + 1]) |
passes two arguments to macro: array[x = y and x +
1]. If you want to supply array[x = y, x + 1] as an argument,
you can write it as array[(x = y, x + 1)], which is equivalent C
code.
All arguments to a macro are completely macro-expanded before they are substituted into the macro body. After substitution, the complete text is scanned again for macros to expand, including the arguments. This rule may seem strange, but it is carefully designed so you need not worry about whether any function call is actually a macro invocation. You can run into trouble if you try to be too clever, though. See section 3.10.6 Argument Prescan, for detailed discussion.
For example, min (min (a, b), c) is first expanded to
min (((a) < (b) ? (a) : (b)), (c)) |
and then to
((((a) < (b) ? (a) : (b))) < (c) ? (((a) < (b) ? (a) : (b))) : (c)) |
(Line breaks shown here for clarity would not actually be generated.)
You can leave macro arguments empty; this is not an error to the
preprocessor (but many macros will then expand to invalid code).
You cannot leave out arguments entirely; if a macro takes two arguments,
there must be exactly one comma at the top level of its argument list.
Here are some silly examples using min:
min(, b) ==> (( ) < (b) ? ( ) : (b)) min(a, ) ==> ((a ) < ( ) ? (a ) : ( )) min(,) ==> (( ) < ( ) ? ( ) : ( )) min((,),) ==> (((,)) < ( ) ? ((,)) : ( )) min() error--> macro "min" requires 2 arguments, but only 1 given min(,,) error--> macro "min" passed 3 arguments, but takes just 2 |
Whitespace is not a preprocessing token, so if a macro foo takes
one argument, foo () and foo ( ) both supply it an
empty argument. Previous GNU preprocessor implementations and
documentation were incorrect on this point, insisting that a
function-like macro that takes a single argument be passed a space if an
empty argument was required.
Macro parameters appearing inside string literals are not replaced by their corresponding actual arguments.
#define foo(x) x, "x" foo(bar) ==> bar, "x" |
Sometimes you may want to convert a macro argument into a string constant. Parameters are not replaced inside string constants, but you can use the `#' preprocessing operator instead. When a macro parameter is used with a leading `#', the preprocessor replaces it with the literal text of the actual argument, converted to a string constant. Unlike normal parameter replacement, the argument is not macro-expanded first. This is called stringification.
There is no way to combine an argument with surrounding text and stringify it all together. Instead, you can write a series of adjacent string constants and stringified arguments. The preprocessor will replace the stringified arguments with string constants. The C compiler will then combine all the adjacent string constants into one long string.
Here is an example of a macro definition that uses stringification:
#define WARN_IF(EXP) \
do { if (EXP) \
fprintf (stderr, "Warning: " #EXP "\n"); } \
while (0)
WARN_IF (x == 0);
==> do { if (x == 0)
fprintf (stderr, "Warning: " "x == 0" "\n"); } while (0);
|
The argument for EXP is substituted once, as-is, into the
if statement, and once, stringified, into the argument to
fprintf. If x were a macro, it would be expanded in the
if statement, but not in the string.
The do and while (0) are a kludge to make it possible to
write WARN_IF (arg);, which the resemblance of
WARN_IF to a function would make C programmers want to do; see
3.10.3 Swallowing the Semicolon.
Stringification in C involves more than putting double-quote characters
around the fragment. The preprocessor backslash-escapes the quotes
surrounding embedded string constants, and all backslashes within string and
character constants, in order to get a valid C string constant with the
proper contents. Thus, stringifying p = "foo\n"; results in
"p = \"foo\\n\";". However, backslashes that are not inside string
or character constants are not duplicated: `\n' by itself
stringifies to "\n".
All leading and trailing whitespace in text being stringified is ignored. Any sequence of whitespace in the middle of the text is converted to a single space in the stringified result. Comments are replaced by whitespace long before stringification happens, so they never appear in stringified text.
There is no way to convert a macro argument into a character constant.
If you want to stringify the result of expansion of a macro argument, you have to use two levels of macros.
#define xstr(s) str(s)
#define str(s) #s
#define foo 4
str (foo)
==> "foo"
xstr (foo)
==> xstr (4)
==> str (4)
==> "4"
|
s is stringified when it is used in str, so it is not
macro-expanded first. But s is an ordinary argument to
xstr, so it is completely macro-expanded before xstr
itself is expanded (see section 3.10.6 Argument Prescan). Therefore, by the time
str gets to its argument, it has already been macro-expanded.
It is often useful to merge two tokens into one while expanding macros.
This is called token pasting or token concatenation. The
`##' preprocessing operator performs token pasting. When a macro
is expanded, the two tokens on either side of each `##' operator
are combined into a single token, which then replaces the `##' and
the two original tokens in the macro expansion. Usually both will be
identifiers, or one will be an identifier and the other a preprocessing
number. When pasted, they make a longer identifier. This isn't the
only valid case. It is also possible to concatenate two numbers (or a
number and a name, such as 1.5 and e3) into a number.
Also, multi-character operators such as += can be formed by
token pasting.
However, two tokens that don't together form a valid token cannot be
pasted together. For example, you cannot concatenate x with
+ in either order. If you try, the preprocessor issues a warning
and emits the two tokens. Whether it puts white space between the
tokens is undefined. It is common to find unnecessary uses of `##'
in complex macros. If you get this warning, it is likely that you can
simply remove the `##'.
Both the tokens combined by `##' could come from the macro body, but you could just as well write them as one token in the first place. Token pasting is most useful when one or both of the tokens comes from a macro argument. If either of the tokens next to an `##' is a parameter name, it is replaced by its actual argument before `##' executes. As with stringification, the actual argument is not macro-expanded first. If the argument is empty, that `##' has no effect.
Keep in mind that the C preprocessor converts comments to whitespace before macros are even considered. Therefore, you cannot create a comment by concatenating `/' and `*'. You can put as much whitespace between `##' and its operands as you like, including comments, and you can put comments in arguments that will be concatenated. However, it is an error if `##' appears at either end of a macro body.
Consider a C program that interprets named commands. There probably needs to be a table of commands, perhaps an array of structures declared as follows:
struct command
{
char *name;
void (*function) (void);
};
struct command commands[] =
{
{ "quit", quit_command },
{ "help", help_command },
...
};
|
It would be cleaner not to have to give each command name twice, once in the string constant and once in the function name. A macro which takes the name of a command as an argument can make this unnecessary. The string constant can be created with stringification, and the function name by concatenating the argument with `_command'. Here is how it is done:
#define COMMAND(NAME) { #NAME, NAME ## _command }
struct command commands[] =
{
COMMAND (quit),
COMMAND (help),
...
};
|
A macro can be declared to accept a variable number of arguments much as a function can. The syntax for defining the macro is similar to that of a function. Here is an example:
#define eprintf(...) fprintf (stderr, __VA_ARGS__) |
This kind of macro is called variadic. When the macro is invoked,
all the tokens in its argument list after the last named argument (this
macro has none), including any commas, become the variable
argument. This sequence of tokens replaces the identifier
__VA_ARGS__ in the macro body wherever it appears. Thus, we
have this expansion:
eprintf ("%s:%d: ", input_file, lineno)
==> fprintf (stderr, "%s:%d: ", input_file, lineno)
|
The variable argument is completely macro-expanded before it is inserted into the macro expansion, just like an ordinary argument. You may use the `#' and `##' operators to stringify the variable argument or to paste its leading or trailing token with another token. (But see below for an important special case for `##'.)
If your macro is complicated, you may want a more descriptive name for
the variable argument than __VA_ARGS__. CPP permits
this, as an extension. You may write an argument name immediately
before the `...'; that name is used for the variable argument.
The eprintf macro above could be written
#define eprintf(args...) fprintf (stderr, args) |
using this extension. You cannot use __VA_ARGS__ and this
extension in the same macro.
You can have named arguments as well as variable arguments in a variadic
macro. We could define eprintf like this, instead:
#define eprintf(format, ...) fprintf (stderr, format, __VA_ARGS__) |
This formulation looks more descriptive, but unfortunately it is less flexible: you must now supply at least one argument after the format string. In standard C, you cannot omit the comma separating the named argument from the variable arguments. Furthermore, if you leave the variable argument empty, you will get a syntax error, because there will be an extra comma after the format string.
eprintf("success!\n", );
==> fprintf(stderr, "success!\n", );
|
GNU CPP has a pair of extensions which deal with this problem. First, you are allowed to leave the variable argument out entirely:
eprintf ("success!\n")
==> fprintf(stderr, "success!\n", );
|
Second, the `##' token paste operator has a special meaning when placed between a comma and a variable argument. If you write
#define eprintf(format, ...) fprintf (stderr, format, ##__VA_ARGS__) |
and the variable argument is left out when the eprintf macro is
used, then the comma before the `##' will be deleted. This does
not happen if you pass an empty argument, nor does it happen if
the token preceding `##' is anything other than a comma.
eprintf ("success!\n")
==> fprintf(stderr, "success!\n");
|
The above explanation is ambiguous about the case where the only macro parameter is a variable arguments parameter, as it is meaningless to try to distinguish whether no argument at all is an empty argument or a missing argument. In this case the C99 standard is clear that the comma must remain, however the existing GCC extension used to swallow the comma. So CPP retains the comma when conforming to a specific C standard, and drops it otherwise.
C99 mandates that the only place the identifier __VA_ARGS__
can appear is in the replacement list of a variadic macro. It may not
be used as a macro name, macro argument name, or within a different type
of macro. It may also be forbidden in open text; the standard is
ambiguous. We recommend you avoid using it except for its defined
purpose.
Variadic macros are a new feature in C99. GNU CPP has supported them
for a long time, but only with a named variable argument
(`args...', not `...' and __VA_ARGS__). If you are
concerned with portability to previous versions of GCC, you should use
only named variable arguments. On the other hand, if you are concerned
with portability to other conforming implementations of C99, you should
use only __VA_ARGS__.
Previous versions of CPP implemented the comma-deletion extension much more generally. We have restricted it in this release to minimize the differences from C99. To get the same effect with both this and previous versions of GCC, the token preceding the special `##' must be a comma, and there must be white space between that comma and whatever comes immediately before it:
#define eprintf(format, args...) fprintf (stderr, format , ##args) |
See section 11.4 Differences from previous versions, for the gory details.
Several object-like macros are predefined; you use them without supplying their definitions. They fall into three classes: standard, common, and system-specific.
In C++, there is a fourth category, the named operators. They act like predefined macros, but you cannot undefine them.
3.7.1 Standard Predefined Macros 3.7.2 Common Predefined Macros 3.7.3 System-specific Predefined Macros 3.7.4 C++ Named Operators
The standard predefined macros are specified by the relevant language standards, so they are available with all compilers that implement those standards. Older compilers may not provide all of them. Their names all start with double underscores.
__FILE__
"/usr/local/include/myheader.h" is a possible expansion of this
macro.
__LINE__
__FILE__ and __LINE__ are useful in generating an error
message to report an inconsistency detected by the program; the message
can state the source line at which the inconsistency was detected. For
example,
fprintf (stderr, "Internal error: "
"negative string length "
"%d at %s, line %d.",
length, __FILE__, __LINE__);
|
An `#include' directive changes the expansions of __FILE__
and __LINE__ to correspond to the included file. At the end of
that file, when processing resumes on the input file that contained
the `#include' directive, the expansions of __FILE__ and
__LINE__ revert to the values they had before the
`#include' (but __LINE__ is then incremented by one as
processing moves to the line after the `#include').
A `#line' directive changes __LINE__, and may change
__FILE__ as well. See section 6. Line Control.
C99 introduces __func__, and GCC has provided __FUNCTION__
for a long time. Both of these are strings containing the name of the
current function (there are slight semantic differences; see the GCC
manual). Neither of them is a macro; the preprocessor does not know the
name of the current function. They tend to be useful in conjunction
with __FILE__ and __LINE__, though.
__DATE__
"Feb 12 1996". If the day of the
month is less than 10, it is padded with a space on the left.
If GCC cannot determine the current date, it will emit a warning message
(once per compilation) and __DATE__ will expand to
"??? ?? ????".
__TIME__
"23:59:01".
If GCC cannot determine the current time, it will emit a warning message
(once per compilation) and __TIME__ will expand to
"??:??:??".
__STDC__
This macro is not defined if the `-traditional-cpp' option is used.
On some hosts, the system compiler uses a different convention, where
__STDC__ is normally 0, but is 1 if the user specifies strict
conformance to the C Standard. CPP follows the host convention when
processing system header files, but when processing user files
__STDC__ is always 1. This has been reported to cause problems;
for instance, some versions of Solaris provide X Windows headers that
expect __STDC__ to be either undefined or 1. See section 12. Invocation.
__STDC_VERSION__
yyyymmL where yyyy and
mm are the year and month of the Standard version. This signifies
which version of the C Standard the compiler conforms to. Like
__STDC__, this is not necessarily accurate for the entire
implementation, unless GNU CPP is being used with GCC.
The value 199409L signifies the 1989 C standard as amended in
1994, which is the current default; the value 199901L signifies
the 1999 revision of the C standard. Support for the 1999 revision is
not yet complete.
This macro is not defined if the `-traditional-cpp' option is used, nor when compiling C++ or Objective-C.
__STDC_HOSTED__
__cplusplus
__cplusplus to test whether a header is compiled by a C compiler
or a C++ compiler. This macro is similar to __STDC_VERSION__, in
that it expands to a version number. A fully conforming implementation
of the 1998 C++ standard will define this macro to 199711L. The
GNU C++ compiler is not yet fully conforming, so it uses 1
instead. We hope to complete our implementation in the near future.
__OBJC__
__OBJC__ to test whether a header is compiled
by a C compiler or a Objective-C compiler.
__ASSEMBLER__
The common predefined macros are GNU C extensions. They are available with the same meanings regardless of the machine or operating system on which you are using GNU C. Their names all start with double underscores.
__GNUC__
__GNUC_MINOR__
__GNUC_PATCHLEVEL__
__GNUC__ to 3,
__GNUC_MINOR__ to 2, and __GNUC_PATCHLEVEL__ to 1. They
are defined only when the entire compiler is in use; if you invoke the
preprocessor directly, they are not defined.
__GNUC_PATCHLEVEL__ is new to GCC 3.0; it is also present in the
widely-used development snapshots leading up to 3.0 (which identify
themselves as GCC 2.96 or 2.97, depending on which snapshot you have).
If all you need to know is whether or not your program is being compiled
by GCC, you can simply test __GNUC__. If you need to write code
which depends on a specific version, you must be more careful. Each
time the minor version is increased, the patch level is reset to zero;
each time the major version is increased (which happens rarely), the
minor version and patch level are reset. If you wish to use the
predefined macros directly in the conditional, you will need to write it
like this:
/* Test for GCC > 3.2.0 */
#if __GNUC__ > 3 || \
(__GNUC__ == 3 && (__GNUC_MINOR__ > 2 || \
(__GNUC_MINOR__ == 2 && \
__GNUC_PATCHLEVEL__ > 0))
|
Another approach is to use the predefined macros to calculate a single number, then compare that against a threshold:
#define GCC_VERSION (__GNUC__ * 10000 \
+ __GNUC_MINOR__ * 100 \
+ __GNUC_PATCHLEVEL__)
...
/* Test for GCC > 3.2.0 */
#if GCC_VERSION > 30200
|
Many people find this form easier to understand.
__GNUG__
(__GNUC__ && __cplusplus).
__STRICT_ANSI__
__BASE_FILE__
__INCLUDE_LEVEL__
__ELF__
__VERSION__
__OPTIMIZE__
__OPTIMIZE_SIZE__
__NO_INLINE__
__OPTIMIZE__ is
defined in all optimizing compilations. __OPTIMIZE_SIZE__ is
defined if the compiler is optimizing for size, not speed.
__NO_INLINE__ is defined if no functions will be inlined into
their callers (when not optimizing, or when inlining has been
specifically disabled by `-fno-inline').
These macros cause certain GNU header files to provide optimized definitions, using macros or inline functions, of system library functions. You should not use these macros in any way unless you make sure that programs will execute with the same effect whether or not they are defined. If they are defined, their value is 1.
__CHAR_UNSIGNED__
char is
unsigned on the target machine. It exists to cause the standard header
file `limits.h' to work correctly. You should not use this macro
yourself; instead, refer to the standard macros defined in `limits.h'.
__WCHAR_UNSIGNED__
__CHAR_UNSIGNED__, this macro is defined if and only if the
data type wchar_t is unsigned and the front-end is in C++ mode.
__REGISTER_PREFIX__
m68k-aout environment it
expands to nothing, but in the m68k-coff environment it expands
to a single `%'.
__USER_LABEL_PREFIX__
m68k-aout environment it expands to an `_', but in the
m68k-coff environment it expands to nothing.
This macro will have the correct definition even if `-f(no-)underscores' is in use, but it will not be correct if target-specific options that adjust this prefix are used (e.g. the OSF/rose `-mno-underscores' option).
__SIZE_TYPE__
__PTRDIFF_TYPE__
__WCHAR_TYPE__
__WINT_TYPE__
size_t, ptrdiff_t, wchar_t, and wint_t
typedefs, respectively. They exist to make the standard header files
`stddef.h' and `wchar.h' work correctly. You should not use
these macros directly; instead, include the appropriate headers and use
the typedefs.
__CHAR_BIT__
char data type. It exists to make the standard header given
numerical limits work correctly. You should not use
this macro directly; instead, include the appropriate headers.
__SCHAR_MAX__
__WCHAR_MAX__
__SHRT_MAX__
__INT_MAX__
__LONG_MAX__
__LONG_LONG_MAX__
signed char, wchar_t,
signed short,
signed int, signed long, and signed long long types
respectively. They exist to make the standard header given numerical limits
work correctly. You should not use these macros directly; instead, include
the appropriate headers.
__USING_SJLJ_EXCEPTIONS__
setjmp and longjmp for exception
handling.
__NEXT_RUNTIME__
__LP64__
_LP64
long int and pointer both use 64-bits and
int uses 32-bit.
The C preprocessor normally predefines several macros that indicate what
type of system and machine is in use. They are obviously different on
each target supported by GCC. This manual, being for all systems and
machines, cannot tell you what their names are, but you can use
cpp -dM to see them all. See section 12. Invocation. All system-specific
predefined macros expand to the constant 1, so you can test them with
either `#ifdef' or `#if'.
The C standard requires that all system-specific macros be part of the
reserved namespace. All names which begin with two underscores,
or an underscore and a capital letter, are reserved for the compiler and
library to use as they wish. However, historically system-specific
macros have had names with no special prefix; for instance, it is common
to find unix defined on Unix systems. For all such macros, GCC
provides a parallel macro with two underscores added at the beginning
and the end. If unix is defined, __unix__ will be defined
too. There will never be more than two underscores; the parallel of
_mips is __mips__.
When the `-ansi' option, or any `-std' option that requests strict conformance, is given to the compiler, all the system-specific predefined macros outside the reserved namespace are suppressed. The parallel macros, inside the reserved namespace, remain defined.
We are slowly phasing out all predefined macros which are outside the
reserved namespace. You should never use them in new programs, and we
encourage you to correct older code to use the parallel macros whenever
you find it. We don't recommend you use the system-specific macros that
are in the reserved namespace, either. It is better in the long run to
check specifically for features you need, using a tool such as
autoconf.
In C++, there are eleven keywords which are simply alternate spellings of operators normally written with punctuation. These keywords are treated as such even in the preprocessor. They function as operators in `#if', and they cannot be defined as macros or poisoned. In C, you can request that those keywords take their C++ meaning by including `iso646.h'. That header defines each one as a normal object-like macro expanding to the appropriate punctuator.
These are the named operators and their corresponding punctuators:
| Named Operator | Punctuator |
and | && |
and_eq | &= |
bitand | & |
bitor | | |
compl | ~ |
not | ! |
not_eq | != |
or | || |
or_eq | |= |
xor | ^ |
xor_eq | ^= |
If a macro ceases to be useful, it may be undefined with the `#undef' directive. `#undef' takes a single argument, the name of the macro to undefine. You use the bare macro name, even if the macro is function-like. It is an error if anything appears on the line after the macro name. `#undef' has no effect if the name is not a macro.
#define FOO 4 x = FOO; ==> x = 4; #undef FOO x = FOO; ==> x = FOO; |
Once a macro has been undefined, that identifier may be redefined as a macro by a subsequent `#define' directive. The new definition need not have any resemblance to the old definition.
However, if an identifier which is currently a macro is redefined, then the new definition must be effectively the same as the old one. Two macro definitions are effectively the same if:
These definitions are effectively the same:
#define FOUR (2 + 2) #define FOUR (2 + 2) #define FOUR (2 /* two */ + 2) |
#define FOUR (2 + 2) #define FOUR ( 2+2 ) #define FOUR (2 * 2) #define FOUR(score,and,seven,years,ago) (2 + 2) |
If a macro is redefined with a definition that is not effectively the same as the old one, the preprocessor issues a warning and changes the macro to use the new definition. If the new definition is effectively the same, the redefinition is silently ignored. This allows, for instance, two different headers to define a common macro. The preprocessor will only complain if the definitions do not match.
Occasionally it is convenient to use preprocessor directives within the arguments of a macro. The C and C++ standards declare that behavior in these cases is undefined.
Versions of CPP prior to 3.2 would reject such constructs with an error message. This was the only syntactic difference between normal functions and function-like macros, so it seemed attractive to remove this limitation, and people would often be surprised that they could not use macros in this way. Moreover, sometimes people would use conditional compilation in the argument list to a normal library function like `printf', only to find that after a library upgrade `printf' had changed to be a function-like macro, and their code would no longer compile. So from version 3.2 we changed CPP to successfully process arbitrary directives within macro arguments in exactly the same way as it would have processed the directive were the function-like macro invocation not present.
If, within a macro invocation, that macro is redefined, then the new definition takes effect in time for argument pre-expansion, but the original definition is still used for argument replacement. Here is a pathological example:
#define f(x) x x f (1 #undef f #define f 2 f) |
which expands to
1 2 1 2 |
with the semantics described above.
In this section we describe some special rules that apply to macros and macro expansion, and point out certain cases in which the rules have counter-intuitive consequences that you must watch out for.
When a macro is called with arguments, the arguments are substituted into the macro body and the result is checked, together with the rest of the input file, for more macro calls. It is possible to piece together a macro call coming partially from the macro body and partially from the arguments. For example,
#define twice(x) (2*(x))
#define call_with_1(x) x(1)
call_with_1 (twice)
==> twice(1)
==> (2*(1))
|
Macro definitions do not have to have balanced parentheses. By writing an unbalanced open parenthesis in a macro body, it is possible to create a macro call that begins inside the macro body but ends outside of it. For example,
#define strange(file) fprintf (file, "%s %d",
...
strange(stderr) p, 35)
==> fprintf (stderr, "%s %d", p, 35)
|
The ability to piece together a macro call can be useful, but the use of unbalanced open parentheses in a macro body is just confusing, and should be avoided.
You may have noticed that in most of the macro definition examples shown above, each occurrence of a macro argument name had parentheses around it. In addition, another pair of parentheses usually surround the entire macro definition. Here is why it is best to write macros that way.
Suppose you define a macro as follows,
#define ceil_div(x, y) (x + y - 1) / y |
whose purpose is to divide, rounding up. (One use for this operation is
to compute how many int objects are needed to hold a certain
number of char objects.) Then suppose it is used as follows:
a = ceil_div (b & c, sizeof (int));
==> a = (b & c + sizeof (int) - 1) / sizeof (int);
|
This does not do what is intended. The operator-precedence rules of C make it equivalent to this:
a = (b & (c + sizeof (int) - 1)) / sizeof (int); |
What we want is this:
a = ((b & c) + sizeof (int) - 1)) / sizeof (int); |
Defining the macro as
#define ceil_div(x, y) ((x) + (y) - 1) / (y) |
provides the desired result.
Unintended grouping can result in another way. Consider sizeof
ceil_div(1, 2). That has the appearance of a C expression that would
compute the size of the type of ceil_div (1, 2), but in fact it
means something very different. Here is what it expands to:
sizeof ((1) + (2) - 1) / (2) |
This would take the size of an integer and divide it by two. The
precedence rules have put the division outside the sizeof when it
was intended to be inside.
Parentheses around the entire macro definition prevent such problems.
Here, then, is the recommended way to define ceil_div:
#define ceil_div(x, y) (((x) + (y) - 1) / (y)) |
Often it is desirable to define a macro that expands into a compound
statement. Consider, for example, the following macro, that advances a
pointer (the argument p says where to find it) across whitespace
characters:
#define SKIP_SPACES(p, limit) \
{ char *lim = (limit); \
while (p < lim) { \
if (*p++ != ' ') { \
p--; break; }}}
|
Here backslash-newline is used to split the macro definition, which must be a single logical line, so that it resembles the way such code would be laid out if not part of a macro definition.
A call to this macro might be SKIP_SPACES (p, lim). Strictly
speaking, the call expands to a compound statement, which is a complete
statement with no need for a semicolon to end it. However, since it
looks like a function call, it minimizes confusion if you can use it
like a function call, writing a semicolon afterward, as in
SKIP_SPACES (p, lim);
This can cause trouble before else statements, because the
semicolon is actually a null statement. Suppose you write
if (*p != 0) SKIP_SPACES (p, lim); else ... |
The presence of two statements--the compound statement and a null
statement--in between the if condition and the else
makes invalid C code.
The definition of the macro SKIP_SPACES can be altered to solve
this problem, using a do ... while statement. Here is how:
#define SKIP_SPACES(p, limit) \
do { char *lim = (limit); \
while (p < lim) { \
if (*p++ != ' ') { \
p--; break; }}} \
while (0)
|
Now SKIP_SPACES (p, lim); expands into
do {...} while (0);
|
which is one statement. The loop executes exactly once; most compilers generate no extra code for it.
Many C programs define a macro min, for "minimum", like this:
#define min(X, Y) ((X) < (Y) ? (X) : (Y)) |
When you use this macro with an argument containing a side effect, as shown here,
next = min (x + y, foo (z)); |
it expands as follows:
next = ((x + y) < (foo (z)) ? (x + y) : (foo (z))); |
where x + y has been substituted for X and foo (z)
for Y.
The function foo is used only once in the statement as it appears
in the program, but the expression foo (z) has been substituted
twice into the macro expansion. As a result, foo might be called
two times when the statement is executed. If it has side effects or if
it takes a long time to compute, the results might not be what you
intended. We say that min is an unsafe macro.
The best solution to this problem is to define min in a way that
computes the value of foo (z) only once. The C language offers
no standard way to do this, but it can be done with GNU extensions as
follows:
#define min(X, Y) \
({ typeof (X) x_ = (X); \
typeof (Y) y_ = (Y); \
(x_ < y_) ? x_ : y_; })
|
The `({ ... })' notation produces a compound statement that acts as an expression. Its value is the value of its last statement. This permits us to define local variables and assign each argument to one. The local variables have underscores after their names to reduce the risk of conflict with an identifier of wider scope (it is impossible to avoid this entirely). Now each argument is evaluated exactly once.
If you do not wish to use GNU C extensions, the only solution is to be
careful when using the macro min. For example, you can
calculate the value of foo (z), save it in a variable, and use
that variable in min:
#define min(X, Y) ((X) < (Y) ? (X) : (Y))
...
{
int tem = foo (z);
next = min (x + y, tem);
}
|
(where we assume that foo returns type int).
A self-referential macro is one whose name appears in its definition. Recall that all macro definitions are rescanned for more macros to replace. If the self-reference were considered a use of the macro, it would produce an infinitely large expansion. To prevent this, the self-reference is not considered a macro call. It is passed into the preprocessor output unchanged. Let's consider an example:
#define foo (4 + foo) |
where foo is also a variable in your program.
Following the ordinary rules, each reference to foo will expand
into (4 + foo); then this will be rescanned and will expand into
(4 + (4 + foo)); and so on until the computer runs out of memory.
The self-reference rule cuts this process short after one step, at
(4 + foo). Therefore, this macro definition has the possibly
useful effect of causing the program to add 4 to the value of foo
wherever foo is referred to.
In most cases, it is a bad idea to take advantage of this feature. A
person reading the program who sees that foo is a variable will
not expect that it is a macro as well. The reader will come across the
identifier foo in the program and think its value should be that
of the variable foo, whereas in fact the value is four greater.
One common, useful use of self-reference is to create a macro which expands to itself. If you write
#define EPERM EPERM |
then the macro EPERM expands to EPERM. Effectively, it is
left alone by the preprocessor whenever it's used in running text. You
can tell that it's a macro with `#ifdef'. You might do this if you
want to define numeric constants with an enum, but have
`#ifdef' be true for each constant.
If a macro x expands to use a macro y, and the expansion of
y refers to the macro x, that is an indirect
self-reference of x. x is not expanded in this case
either. Thus, if we have
#define x (4 + y) #define y (2 * x) |
then x and y expand as follows:
x ==> (4 + y)
==> (4 + (2 * x))
y ==> (2 * x)
==> (2 * (4 + y))
|
Each macro is expanded when it appears in the definition of the other macro, but not when it indirectly appears in its own definition.
Macro arguments are completely macro-expanded before they are substituted into a macro body, unless they are stringified or pasted with other tokens. After substitution, the entire macro body, including the substituted arguments, is scanned again for macros to be expanded. The result is that the arguments are scanned twice to expand macro calls in them.
Most of the time, this has no effect. If the argument contained any macro calls, they are expanded during the first scan. The result therefore contains no macro calls, so the second scan does not change it. If the argument were substituted as given, with no prescan, the single remaining scan would find the same macro calls and produce the same results.
You might expect the double scan to change the results when a self-referential macro is used in an argument of another macro (see section 3.10.5 Self-Referential Macros): the self-referential macro would be expanded once in the first scan, and a second time in the second scan. However, this is not what happens. The self-references that do not expand in the first scan are marked so that they will not expand in the second scan either.
You might wonder, "Why mention the prescan, if it makes no difference? And why not skip it and make the preprocessor faster?" The answer is that the prescan does make a difference in three special cases:
We say that nested calls to a macro occur when a macro's argument
contains a call to that very macro. For example, if f is a macro
that expects one argument, f (f (1)) is a nested pair of calls to
f. The desired expansion is made by expanding f (1) and
substituting that into the definition of f. The prescan causes
the expected result to happen. Without the prescan, f (1) itself
would be substituted as an argument, and the inner use of f would
appear during the main scan as an indirect self-reference and would not
be expanded.
If an argument is stringified or concatenated, the prescan does not occur. If you want to expand a macro, then stringify or concatenate its expansion, you can do that by causing one macro to call another macro that does the stringification or concatenation. For instance, if you have
#define AFTERX(x) X_ ## x #define XAFTERX(x) AFTERX(x) #define TABLESIZE 1024 #define BUFSIZE TABLESIZE |
then AFTERX(BUFSIZE) expands to X_BUFSIZE, and
XAFTERX(BUFSIZE) expands to X_1024. (Not to
X_TABLESIZE. Prescan always does a complete expansion.)
This can cause a macro expanded on the second scan to be called with the wrong number of arguments. Here is an example:
#define foo a,b #define bar(x) lose(x) #define lose(x) (1 + (x)) |
We would like bar(foo) to turn into (1 + (foo)), which
would then turn into (1 + (a,b)). Instead, bar(foo)
expands into lose(a,b), and you get an error because lose
requires a single argument. In this case, the problem is easily solved
by the same parentheses that ought to be used to prevent misnesting of
arithmetic operations:
#define foo (a,b) or #define bar(x) lose((x)) |
The extra pair of parentheses prevents the comma in foo's
definition from being interpreted as an argument separator.
The invocation of a function-like macro can extend over many logical lines. However, in the present implementation, the entire expansion comes out on one line. Thus line numbers emitted by the compiler or debugger refer to the line the invocation started on, which might be different to the line containing the argument causing the problem.
Here is an example illustrating this:
#define ignore_second_arg(a,b,c) a; c
ignore_second_arg (foo (),
ignored (),
syntax error);
|
The syntax error triggered by the tokens syntax error results in
an error message citing line three--the line of ignore_second_arg---
even though the problematic code comes from line five.
We consider this a bug, and intend to fix it in the near future.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |