C预处理器详解：GCC 11.1.0版及其工作原理

需积分: 9 79 浏览量更新于2024-07-09 收藏 466KB PDF 举报

C预处理器是C语言编译过程中的一个关键组件，它在源代码编译之前对文本进行处理，以执行宏定义、条件编译、包含头文件等功能。本文档主要针对GCC版本11.1.0，由Richard Stallman和Zachary Weinberg撰写，版权归属Free Software Foundation。文档遵循GNU Free Documentation License Version 1.3或更高版本，强调了复制、分发和修改的自由。 1. **概述** - **字符集**: C预处理器支持多种字符集，包括ASCII、ISO Latin-1等，以处理不同编码的源代码。 - **初始处理**: 预处理器首先处理输入，识别并转换行结束符（如Unix的换行符或Windows的CR+LF），确保跨平台兼容性。 - **词法分析（Tokenization）**: 将源代码分解成可识别的基本单元（tokens），如标识符、关键字、运算符等。 2. **头文件管理** - **包含语法**: #include指令用于引入其他源文件，提供所需的功能和声明。 - **包含操作**: 预处理器查找指定路径中的头文件，并将其中的内容插入到源代码中。 - **搜索路径**: 编译器有预定义的搜索路径，用于寻找包含文件，也可以通过命令行选项自定义。 - **一次仅包含（Once-Only Headers）**: 防止重复包含同一个头文件的机制，如#ifndef/define/endif结构。 - **替代方案**: 提供了其他方式来避免头文件重复，比如条件编译的替代方法。 - **计算包含（Computed Includes）**: 使用宏进行动态头文件路径的计算，增加代码的灵活性。 - **包装头文件（Wrapper Headers）**: 一种策略，用包含检查来控制代码的可见性，防止无意的循环依赖。 C预处理器不仅仅是简单的文本替换，它的作用远超乎普通文本编辑器的功能，它能根据编译时的环境变量和条件语句改变代码的行为。理解并正确使用预处理器是C程序员必备的技能，因为它能帮助编写更模块化、灵活且高效的代码。掌握预处理器的细节对于编写高性能、可维护的程序至关重要。

Chapter 2: Header Files 9

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 57, 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 47). ‘#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,

Chapter 2: Header Files 11

#if SYSTEM_1

# 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 46), 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.

剩余84页未读，继续阅读

0x30

粉丝: 1
资源: 9

C预处理器详解：GCC 11.1.0版及其工作原理

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

Node.js中的C预处理器实现与探讨

C语言预处理器指南

The C Preprocessor

The C Preprocessor.rar

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

C Preprocessor for ActionScript-开源

Red Hat Enterprise Linux 3 Using cpp, the C Preprocessor

cannot find C preprocessor cl.exe

awesome-c-preprocessor:很棒的C预处理器清单

最新资源