따로 찾기 귀찮아서 웹사이트에서 긁은 정보(주로 GCC 3.2 매뉴얼)를 모았습니다.
Standard Predefined Macros
__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.__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.__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".__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 option is used. This macro is not defined if the -traditional 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. GNU 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. You may be able to work around this sort of problem by using an -I option to cancel treatment of those headers as system headers. See 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 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. We hope to complete our implementation in the near future.
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:__OBJC__Another approach is to use the predefined macros to calculate a single number, then compare that against a threshold:/* Test for GCC > 3.2.0 */ #if __GNUC__ > 3 || \ (__GNUC__ == 3 && (__GNUC_MINOR__ > 2 || \ (__GNUC_MINOR__ == 2 && \ __GNUC_PATCHLEVEL__ > 0))Many people find this form easier to understand.#define GCC_VERSION (__GNUC__ * 10000 \ + __GNUC_MINOR__ * 100 \ + __GNUC_PATCHLEVEL__) ... /* Test for GCC > 3.2.0 */ #if GCC_VERSION > 30200
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.__GNUC__
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.__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.__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).__SIZE_TYPE__ __PTRDIFF_TYPE__ __WCHAR_TYPE__ __WINT_TYPE__
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.__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.
Function Names as Strings
GCC predefines two magic identifiers to hold the name of the current function. The identifier __FUNCTION__ holds the name of the function as it appears in the source. The identifier __PRETTY_FUNCTION__ holds the name of the function pretty printed in a language specific fashion.
These names are always the same in a C function, but in a C++ function they may be different. For example, this program:
extern "C" {
extern int printf (char *, ...);
}
class a {
public:
sub (int i)
{
printf ("__FUNCTION__ = %s\n", __FUNCTION__);
printf ("__PRETTY_FUNCTION__ = %s\n", __PRETTY_FUNCTION__);
}
};
int
main (void)
{
a ax;
ax.sub (0);
return 0;
}gives this output:
__FUNCTION__ = sub __PRETTY_FUNCTION__ = int a::sub (int)
The compiler automagically replaces the identifiers with a string literal containing the appropriate name. Thus, they are neither preprocessor macros, like __FILE__ and __LINE__, nor variables. This means that they catenate with other string literals, and that they can be used to initialize char arrays. For example char here = "Function " __FUNCTION__ " in " __FILE__; On the other hand, #ifdef __FUNCTION__ does not have any special meaning inside a function, since the preprocessor does not do anything special with the identifier __FUNCTION__.
Note that these semantics are deprecated, and that GCC 3.2 will handle __FUNCTION__ and __PRETTY_FUNCTION__ the same way as __func__. __func__ is defined by the ISO standard C99:
The identifier __func__ is implicitly declared by the translator as if, immediately following the opening brace of each function definition, the declaration
static const char __func__[] = "function-name";appeared, where function-name is the name of the lexically-enclosing function. This name is the unadorned name of the function. By this definition, __func__ is a variable, not a string literal. In particular, __func__ does not catenate with other string literals.
In C++, __FUNCTION__ and __PRETTY_FUNCTION__ are variables, declared in the same way as __func__.
Macros with a Variable Number of Arguments.
In the ISO C standard of 1999, 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 debug(format, ...) fprintf (stderr, format, __VA_ARGS__)Here ... is a variable argument. In the invocation of such a macro, it represents the zero or more tokens until the closing parenthesis that ends the invocation, including any commas. This set of tokens replaces the identifier __VA_ARGS__ in the macro body wherever it appears. See the CPP manual for more information.
GCC has long supported variadic macros, and used a different syntax that allowed you to give a name to the variable arguments just like any other argument. Here is an example:
#define debug(format, args...) fprintf (stderr, format, args)This is in all ways equivalent to the ISO C example above, but arguably more readable and descriptive.
GNU CPP has two further variadic macro extensions, and permits them to be used with either of the above forms of macro definition.
In standard C, you are not allowed to leave the variable argument out entirely; but you are allowed to pass an empty argument. For example, this invocation is invalid in ISO C, because there is no comma after the string:
debug ("A message")GNU CPP permits you to completely omit the variable arguments in this way. In the above examples, the compiler would complain, though since the expansion of the macro still has the extra comma after the format string.
To help solve this problem, CPP behaves specially for variable arguments used with the token paste operator, ##. If instead you write
#define debug(format, ...) fprintf (stderr, format, ## __VA_ARGS__)and if the variable arguments are omitted or empty, the ## operator causes the preprocessor to remove the comma before it. If you do provide some variable arguments in your macro invocation, GNU CPP does not complain about the paste operation and instead places the variable arguments after the comma. Just like any other pasted macro argument, these arguments are not macro expanded.
System별 predefine
Generated with gcc -E -dM:
Vaxstation
#define __vax__ 1
#define __vax 1
#define __unix 1
#define __unix__ 1
#define vax 1
#define __GNUC__ 2
#define unix 1Linux (i386)
#define __linux__ 1
#define linux 1
#define __i386__ 1
#define __i386 1
#define i386 1
#define __unix 1
#define __unix__ 1
#define __GNUC__ 2
#define __linux 1
#define unix 1NetBSD (i386)
#define __i386__ 1
#define __NetBSD__ 1
#define __i386 1
#define i386 1
#define __unix 1
#define __unix__ 1
#define __GNUC__ 2
#define unix 1NetBSD (sparc)
#define __GCC_NEW_VARARGS__ 1
#define __NetBSD__ 1
#define __sparc 1
#define sparc 1
#define __unix 1
#define __unix__ 1
#define __GNUC__ 2
#define __sparc__ 1
#define unix 1Decstation
#define __LANGUAGE_C 1
#define R3000 1
#define __SYSTYPE_BSD__ 1
#define SYSTYPE_BSD 1
#define __host_mips 1
#define ultrix 1
#define __MIPSEL__ 1
#define __ANSI_COMPAT 1
#define __MIPSEL 1
#define ___SYSTYPE_BSD 1
#define __mips__ 1
#define __mips 1
#define __host_mips__ 1
#define MIPSEL 1
#define __R3000__ 1
#define __ultrix__ 1
#define host_mips 1
#define __SYSTYPE_BSD 1
#define ___SYSTYPE_BSD__ 1
#define mips 1
#define __LANGUAGE_C__ 1
#define __unix 1
#define __R3000 1
#define __unix__ 1
#define __bsd4_2 1
#define __bsd4_2__ 1
#define __GNUC__ 2
#define __ultrix 1
#define LANGUAGE_C 1
#define _SYSTYPE_BSD 1
#define bsd4_2 1
#define unix 1RS-6000
#define ___AIX 1
#define ___IBMR2__ 1
#define _AIX 1
#define ___AIX32 1
#define __CHAR_UNSIGNED__ 1
#define ___IBMR2 1
#define ___AIX__ 1
#define ___AIX32__ 1
#define _AIX32 1
#define __GNUC__ 2
#define _IBMR2 1Sun (Solaris)
#define __GCC_NEW_VARARGS__ 1
#define __sparc 1
#define __svr4__ 1
#define __sun 1
#define sparc 1
#define __sun__ 1
#define __unix 1
#define __unix__ 1
#define sun 1
#define __GNUC__ 2
#define __sparc__ 1
#define unix 1Sun (SunOS)
#define __GCC_NEW_VARARGS__ 1
#define __sparc 1
#define __GNUC_MINOR__ 5
#define __sun 1
#define sparc 1
#define __sun__ 1
#define __unix 1
#define __unix__ 1
#define sun 1
#define __GNUC__ 2
#define __sparc__ 1
#define unix 1SGI
#define sgi 1
#define __EXTENSIONS__ 1
#define _SVR3 1
#define mips 1
#define unix 1HPUX
#define hp9k8 1
#define __hppa 1
#define __hpux 1
#define __hpux__ 1
#define hp9000s800 1
#define PWB 1
#define _PA_RISC1_1 1
#define __hp9000s700 1
#define __hp9000s800 1
#define __PWB__ 1
#define __GNUC_MINOR__ 7
#define hppa 1
#define hpux 1
#define _HPUX_SOURCE 1
#define __hp9k8__ 1
#define __hppa__ 1
#define __unix 1
#define __unix__ 1
#define __hp9k8 1
#define __GNUC__ 2
#define __hp9000s800__ 1
#define __PWB 1
#define unix 1Minimum and Maximum Operators in C++
It is very convenient to have operators which return the "minimum" or the "maximum" of two arguments. In GNU C++ (but not in GNU C),
a < b
is the minimum, returning the smaller of the numeric values a and b;
a > b
is the maximum, returning the larger of the numeric values a and b. These operations are not primitive in ordinary C++, since you can use a macro to return the minimum of two things in C++, as in the following example.
#define MIN(X,Y) ((X) < (Y) ? : (X) : (Y))You might then use int min = MIN (i, j); to set min to the minimum value of variables i and j.
However, side effects in X or Y may cause unintended behavior. For example, MIN (i++, j++) will fail, incrementing the smaller counter twice. A GNU C extension allows you to write safe macros that avoid this kind of problem (see Naming an Expression's Type). However, writing MIN and MAX as macros also forces you to use function-call notation for a fundamental arithmetic operation. Using GNU C++ extensions, you can write int min = i < j; instead.
Since < and > are built into the compiler, they properly handle expressions with side-effects; int min = i++ < j++; works correctly.
