C语言预处理器指南

需积分: 0 197 浏览量更新于2024-06-19 收藏 461KB PDF 举报

“The C Preprocessor”是关于C语言预处理器的指南，适用于GCC版本13.1.0（GCC）。该文档由Richard M. Stallman和Zachary Weinberg编写，主要讨论了C语言预处理的各个方面，包括字符集、初步处理、标记化、预处理语言、头文件的使用等。在C语言中，预处理器是编译过程的第一步，它负责处理源代码中的宏定义、条件编译指令和其他特殊指令。以下是预处理器涉及的关键知识点： 1. **字符集**：C语言支持ASCII字符集，包括字母、数字、标点符号和控制字符。预处理器会处理这些字符，如宏替换和条件编译时，会考虑字符编码。 2. **初步处理**：这个阶段，预处理器会进行以下操作： - 处理`#define`定义的宏，将宏名替换为它们的定义。 - 扩展`#include`指令，将头文件的内容插入到源文件中。 - 处理`#if`、`#ifdef`、`#ifndef`、`#else`、`#elif`和`#endif`等条件编译指令，根据条件决定是否包含或跳过某些代码块。 - 处理`#undef`，取消宏定义。 3. **标记化**：预处理器将源代码分解成一个个称为“标记”的单元，如标识符、关键字、常量、运算符和分隔符。这些标记是编译器进一步处理的基础。 4. **预处理语言**：预处理器有自己的简单语言，包括宏定义、条件编译指令等。宏可以有参数，允许动态生成代码，而条件编译则用于根据特定条件包含或排除代码。 5. **头文件**：头文件通常包含函数声明、常量定义和宏定义，用于共享代码和数据结构。预处理器通过`#include`指令来引入头文件。 - **Include语法**：`#include <file>`用于系统头文件，`#include "file"`用于用户头文件。 - **Include操作**：预处理器查找并插入指定的头文件。 - **搜索路径**：编译器会按照特定的路径顺序查找头文件，这些路径可以通过编译选项 `-I` 来添加或修改。 - **一次-only头文件**：`#pragma once`或`#ifndef`/`#define`/`#endif`组合用于确保头文件只被包含一次，防止重复定义问题。 - **替代wrapper#ifndef**：除了传统的`#ifndef`方法，还可以使用其他技术如`__has_include`来避免头文件重复包含。 - **计算式#include**：通过宏和条件编译，可以实现基于某些条件的动态头文件包含。 - **包装头文件**：有时为了控制头文件的包含，会使用包装头文件，它们通常包含`#ifndef`/`#define`/`#endif`结构，确保头文件仅被包含一次。预处理器是C语言开发中不可或缺的一部分，理解和掌握这些概念对于编写高效、可维护的代码至关重要。通过熟练使用预处理器，开发者可以实现代码重用、条件编译和简化复杂逻辑，同时，理解预处理过程也有助于调试和优化程序。

Chapter 2: Header Files 9

ﬁle could even contain the beginning of a statement that is concluded in the containing ﬁle,

or the end of a statement that was started in the including ﬁle. However, an included ﬁle

must consist of complete tokens. Comments and string literals which have not been closed

by the end of an included ﬁle are invalid. For error recovery, they are considered to end at

the end of the ﬁle.

To avoid confusion, it is best if header ﬁles contain only complete syntactic units—

function declarations or deﬁnitions, type declarations, etc.

The line following the ‘#include’ directive is always treated as a separate line by the C

preprocessor, even if the included ﬁle lacks a ﬁnal newline.

2.3 Search Path

By default, the preprocessor looks for header ﬁles included by the quote form of the directive

#include "file" ﬁrst relative to the directory of the current ﬁle, and then in a precon-

ﬁgured list of standard system directories. For example, if /usr/include/sys/stat.h

contains #include "types.h", GCC looks for types.h ﬁrst in /usr/include/sys, then in

its usual search path.

For the angle-bracket form #include <file>, the preprocessor’s default behavior is to

look only in the standard system directories. The exact search directory list depends on the

target system, how GCC is conﬁgured, and where it is installed. You can ﬁnd the default

search directory list for your version of CPP by invoking it with the -v option. For example,

cpp -v /dev/null -o /dev/null

There are a number of command-line options you can use to add additional directories to

the search path. The most commonly-used option is -Idir, which causes dir to be searched

after the current directory (for the quote form of the directive) and ahead of the standard

system directories. You can specify multiple -I options on the command line, in which case

the directories are searched in left-to-right order.

If you need separate control over the search paths for the quote and angle-bracket forms

of the ‘#include’ directive, you can use the -iquote and/or -isystem options instead of

-I. See Chapter 12 [Invocation], page 58, for a detailed description of these options, as well

as others that are less generally useful.

If you specify other options on the command line, such as -I, that aﬀect where the

preprocessor searches for header ﬁles, the directory list printed by the -v option reﬂects the

actual search path used by the preprocessor.

Note that you can also prevent the preprocessor from searching any of the default system

header directories with the -nostdinc option. This is useful when you are compiling an

operating system kernel or some other program that does not use the standard C library

facilities, or the standard C library itself.

2.4 Once-Only Headers

If a header ﬁle happens to be included twice, the compiler will process its contents twice.

This is very likely to cause an error, e.g. when the compiler sees the same structure deﬁnition

twice. Even if it does not, it will certainly waste time.

The standard way to prevent this is to enclose the entire real contents of the ﬁle in a

conditional, like this:

Chapter 2: Header Files 10

/* File foo. */

#ifndef FILE_FOO_SEEN

#define FILE_FOO_SEEN

the entire file

#endif /* !FILE_FOO_SEEN */

This construct is commonly known as a wrapper #ifndef. When the header is included

again, the conditional will be false, because FILE_FOO_SEEN is deﬁned. The preprocessor

will skip over the entire contents of the ﬁle, and the compiler will not see it twice.

CPP optimizes even further. It remembers when a header ﬁle has a wrapper ‘#ifndef’.

If a subsequent ‘#include’ speciﬁes that header, and the macro in the ‘#ifndef’ is still

deﬁned, it does not bother to rescan the ﬁle at all.

You can put comments outside the wrapper. They will not interfere with this optimiza-

tion.

The macro FILE_FOO_SEEN is called the controlling macro or guard macro. In a user

header ﬁle, the macro name should not begin with ‘_’. In a system header ﬁle, it should

begin with ‘__’ to avoid conﬂicts with user programs. In any kind of header ﬁle, the macro

name should contain the name of the ﬁle and some additional text, to avoid conﬂicts with

other header ﬁles.

2.5 Alternatives to Wrapper #ifndef

CPP supports two more ways of indicating that a header ﬁle should be read only once.

Neither one is as portable as a wrapper ‘#ifndef’ and we recommend you do not use them

in new programs, with the caveat that ‘#import’ is standard practice in Objective-C.

CPP supports a variant of ‘#include’ called ‘#import’ which includes a ﬁle, but does

so at most once. If you use ‘#import’ instead of ‘#include’, then you don’t need the

conditionals inside the header ﬁle to prevent multiple inclusion of the contents. ‘#import’

is standard in Objective-C, but is considered a deprecated extension in C and C++.

‘#import’ is not a well designed feature. It requires the users of a header ﬁle to know

that it should only be included once. It is much better for the header ﬁle’s implementor to

write the ﬁle so that users don’t need to know this. Using a wrapper ‘#ifndef’ accomplishes

this goal.

In the present implementation, a single use of ‘#import’ will prevent the ﬁle from ever

being read again, by either ‘#import’ or ‘#include’. You should not rely on this; do not

use both ‘#import’ and ‘#include’ to refer to the same header ﬁle.

Another way to prevent a header ﬁle from being included more than once is with the

‘#pragma once’ directive (see Chapter 7 [Pragmas], page 49). ‘#pragma once’ does not

have the problems that ‘#import’ does, but it is not recognized by all preprocessors, so you

cannot rely on it in a portable program.

2.6 Computed Includes

Sometimes it is necessary to select one of several diﬀerent header ﬁles to be included into

your program. They might specify conﬁguration parameters to be used on diﬀerent sorts

of operating systems, for instance. You could do this with a series of conditionals,

#if SYSTEM_1

Chapter 2: Header Files 11

# include "system_1.h"

#elif SYSTEM_2

# include "system_2.h"

#elif SYSTEM_3

...

#endif

That rapidly becomes tedious. Instead, the preprocessor oﬀers the ability to use a macro

for the header name. This is called a computed include. Instead of writing a header name

as the direct argument of ‘#include’, you simply put a macro name there instead:

#define SYSTEM_H "system_1.h"

...

#include SYSTEM_H

SYSTEM_H will be expanded, and the preprocessor will look for system_1.h as if the

‘#include’ had been written that way originally. SYSTEM_H could be deﬁned by your

Makeﬁle with a -D option.

You must be careful when you deﬁne the macro. ‘#define’ saves tokens, not text.

The preprocessor has no way of knowing that the macro will be used as the argument of

‘#include’, so it generates ordinary tokens, not a header name. This is unlikely to cause

problems if you use double-quote includes, which are close enough to string constants. If

you use angle brackets, however, you may have trouble.

The syntax of a computed include is actually a bit more general than the above. If

the ﬁrst non-whitespace character after ‘#include’ is not ‘"’ or ‘<’, then the entire line is

macro-expanded like running text would be.

If the line expands to a single string constant, the contents of that string constant are the

ﬁle to be included. CPP does not re-examine the string for embedded quotes, but neither

does it process backslash escapes in the string. Therefore

#define HEADER "a\"b"

#include HEADER

looks for a ﬁle named a\"b. CPP searches for the ﬁle according to the rules for double-

quoted includes.

If the line expands to a token stream beginning with a ‘<’ token and including a ‘>’

token, then the tokens between the ‘<’ and the ﬁrst ‘>’ are combined to form the ﬁlename

to be included. Any whitespace between tokens is reduced to a single space; then any space

after the initial ‘<’ is retained, but a trailing space before the closing ‘>’ is ignored. CPP

searches for the ﬁle according to the rules for angle-bracket includes.

In either case, if there are any tokens on the line after the ﬁle name, an error occurs and

the directive is not processed. It is also an error if the result of expansion does not match

either of the two expected forms.

These rules are implementation-deﬁned behavior according to the C standard. To min-

imize the risk of diﬀerent compilers interpreting your computed includes diﬀerently, we

recommend you use only a single object-like macro which expands to a string constant.

This will also minimize confusion for people reading your program.

2.7 Wrapper Headers

Sometimes it is necessary to adjust the contents of a system-provided header ﬁle without

editing it directly. GCC’s fixincludes operation does this, for example. One way to do

Chapter 2: Header Files 12

that would be to create a new header ﬁle with the same name and insert it in the search

path before the original header. That works ﬁne as long as you’re willing to replace the old

header entirely. But what if you want to refer to the old header from the new one?

You cannot simply include the old header with ‘#include’. That will start from the

beginning, and ﬁnd your new header again. If your header is not protected from multiple

inclusion (see Section 2.4 [Once-Only Headers], page 9), it will recurse inﬁnitely and cause

a fatal error.

You could include the old header with an absolute pathname:

#include "/usr/include/old-header.h"

This works, but is not clean; should the system headers ever move, you would have to edit

the new headers to match.

There is no way to solve this problem within the C standard, but you can use the GNU

extension ‘#include_next’. It means, “Include the next ﬁle with this name”. This directive

works like ‘#include’ except in searching for the speciﬁed ﬁle: it starts searching the list

of header ﬁle directories after the directory in which the current ﬁle was found.

Suppose you specify -I /usr/local/include, and the list of directories to search

also includes /usr/include; and suppose both directories contain signal.h. Ordinary

#include <signal.h> ﬁnds the ﬁle under /usr/local/include. If that ﬁle contains

#include_next <signal.h>, it starts searching after that directory, and ﬁnds the ﬁle in

/usr/include.

‘#include_next’ does not distinguish between <file> and "file" inclusion, nor does it

check that the ﬁle you specify has the same name as the current ﬁle. It simply looks for the

ﬁle named, starting with the directory in the search path after the one where the current

ﬁle was found.

The use of ‘#include_next’ can lead to great confusion. We recommend it be used

only when there is no other alternative. In particular, it should not be used in the headers

belonging to a speciﬁc program; it should be used only to make global corrections along the

lines of fixincludes.

2.8 System Headers

The header ﬁles declaring interfaces to the operating system and runtime libraries often can-

not be written in strictly conforming C. Therefore, GCC gives code found in system headers

special treatment. All warnings, other than those generated by ‘#warning’ (see Chapter 5

[Diagnostics], page 47), are suppressed while GCC is processing a system header. Macros

deﬁned in a system header are immune to a few warnings wherever they are expanded. This

immunity is granted on an ad-hoc basis, when we ﬁnd that a warning generates lots of false

positives because of code in macros deﬁned in system headers.

Normally, only the headers found in speciﬁc directories are considered system headers.

These directories are determined when GCC is compiled. There are, however, two ways to

make normal headers into system headers:

• Header ﬁles found in directories added to the search path with the -isystem and

-idirafter command-line options are treated as system headers for the purposes of

diagnostics.

Chapter 3: Macros 13

• There is also a directive, #pragma GCC system_header, which tells GCC to consider

the rest of the current include ﬁle a system header, no matter where it was found. Code

that comes before the ‘#pragma’ in the ﬁle is not aﬀected. #pragma GCC system_header

has no eﬀect in the primary source ﬁle.

On some targets, such as RS/6000 AIX, GCC implicitly surrounds all system headers

with an ‘extern "C"’ block when compiling as C++.

3 Macros

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 diﬀer 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 deﬁne any valid identiﬁer 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 [Deﬁned], page 44) can never be deﬁned as a macro,

and C++’s named operators (see Section 3.7.4 [C++ Named Operators], page 34) cannot be

macros when you are compiling C++.

3.1 Object-like Macros

An object-like macro is a simple identiﬁer 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

deﬁnes 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 uppercase. 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 deﬁnition

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, \

int x[] = { NUMBERS };

7→ int x[] = { 1, 2, 3 };

剩余85页未读，继续阅读

weixin_35661127

粉丝: 2
资源: 3

C语言预处理器指南

The C preprocessor

The C Preprocessor.rar

C, GNUC GCC 预处理《The C Preprocessor》

Red Hat Enterprise Linux 3 Using cpp, the C Preprocessor

C预处理器详解：GCC版本4.5.2与《The C Preprocessor》

The Tree Preprocessor

Opening Up The C/C++ Preprocessor Black Box

Tips and tricks using the preprocessor 1

Tips and tricks using the preprocessor 2

最新资源