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
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__
This macro expands to the name of the current input file, in the form of
a C string constant. This is the path by which the preprocessor opened
the file, not the short name specified in #include or as the
input file name argument. For example,
"/usr/local/include/myheader.h" is a possible expansion of this
macro.
__LINE__
This macro expands to the current input line number, in the form of a
decimal integer constant. While we call it a predefined macro, it's
a pretty strange macro, since its "definition" changes with each
new line of source code.
__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. Chapter 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__
This macro expands to a string constant that describes the date on which
the preprocessor is being run. The string constant contains eleven
characters and looks like "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__
This macro expands to a string constant that describes the time at
which the preprocessor is being run. The string constant contains
eight characters and looks like "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__
In normal operation, this macro expands to the constant 1, to signify
that this compiler conforms to ISO Standard C. If GNU CPP is used with
a compiler other than GCC, this is not necessarily true; however, the
preprocessor always conforms to the standard unless the
-traditional-cpp option is used.
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. Chapter 12 Invocation.
__STDC_VERSION__
This macro expands to the C Standard's version number, a long integer
constant of the form 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__
This macro is defined, with value 1, if the compiler's target is a
hosted environment. A hosted environment has the complete
facilities of the standard C library available.
__cplusplus
This macro is defined when the C++ compiler is in use. You can use
__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. It is hoped to complete the implementation of standard C++
in the near future.
__OBJC__
This macro is defined, with value 1, when the Objective-C compiler is in
use. You can use __OBJC__ to test whether a header is compiled
by a C compiler or a Objective-C compiler.
__ASSEMBLER__
This macro is defined with value 1 when preprocessing assembly
language.
3.7.2. Common Predefined Macros
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__
These macros are defined by all GNU compilers that use the C
preprocessor: C, C++, and Objective-C. Their values are the major
version, minor version, and patch level of the compiler, as integer
constants. For example, GCC 3.2.1 will define __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:
The GNU C++ compiler defines this. Testing it is equivalent to
testing (__GNUC__ && __cplusplus).
__STRICT_ANSI__
GCC defines this macro if and only if the -ansi switch, or a
-std switch specifying strict conformance to some version of ISO C,
was specified when GCC was invoked. It is defined to 1.
This macro exists primarily to direct GNU libc's header files to
restrict their definitions to the minimal set found in the 1989 C
standard.
__BASE_FILE__
This macro expands to the name of the main input file, in the form
of a C string constant. This is the source file that was specified
on the command line of the preprocessor or C compiler.
__INCLUDE_LEVEL__
This macro expands to a decimal integer constant that represents the
depth of nesting in include files. The value of this macro is
incremented on every #include directive and decremented at the
end of every included file. It starts out at 0, it's value within the
base file specified on the command line.
__ELF__
This macro is defined if the target uses the ELF object format.
__VERSION__
This macro expands to a string constant which describes the version of
the compiler in use. You should not rely on its contents having any
particular form, but it can be counted on to contain at least the
release number.
__OPTIMIZE__, __OPTIMIZE_SIZE__, __NO_INLINE__
These macros describe the compilation mode. __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__
GCC defines this macro if and only if the data type 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__
Like __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__
This macro expands to a single token (not a string constant) which is
the prefix applied to CPU register names in assembly language for this
target. You can use it to write assembly that is usable in multiple
environments. For example, in the m68k-aout environment it
expands to nothing, but in the m68k-coff environment it expands
to a single %.
__USER_LABEL_PREFIX__
This macro expands to a single token which is the prefix applied to
user labels (symbols visible to C code) in assembly. For example, in
the 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).
These macros are defined to the correct underlying types for the
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__
Defined to the number of bits used in the representation of the
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.
Defined to the maximum value of the 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__
This macro is defined, with value 1, if the compiler uses the old
mechanism based on setjmp and longjmp for exception
handling.
__NEXT_RUNTIME__
This macro is defined, with value 1, if (and only if) the NeXT runtime
(as in -fnext-runtime) is in use for Objective-C. If the GNU
runtime is used, this macro is not defined, so that you can use this
macro to determine which runtime (NeXT or GNU) is being used.
__LP64__, _LP64
These macros are defined, with value 1, if (and only if) the compilation
is for a target where long int and pointer both use 64-bits and
int uses 32-bit.
3.7.3. System-specific Predefined Macros
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. Chapter 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.
3.7.4. C++ Named Operators
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:
