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

需积分: 5 35 浏览量更新于2024-06-14 收藏 508KB PDF 举报

C预处理器是C语言编译流程中的关键组件，它在编译器gcc（GNU Compiler Collection）的早期版本4.5.2中扮演着重要角色，特别是在Sourcery G++ Lite 2011.03-38这一编译工具包中。由Richard Stallman和Zachary Weinberg合著的"The C Preprocessor"一书详细阐述了这个预处理器的工作原理。 C预处理器的主要任务是在正式编译之前对源代码进行一系列处理，以扩展和修改输入的程序。预处理包括以下几个重要概念： 1. **字符集**：预处理器处理的是文本，因此理解不同字符集对于正确解析源代码至关重要。不同的字符集可能影响宏定义、字符串处理以及文件包含操作。 2. **初始处理**：预处理器首先会读取源代码，进行一些基本的清理工作，如去除空白字符，处理注释等。这为后续的处理奠定了基础。 3. **词法分析（Tokenization）**：预处理器将源代码分割成一个个有意义的单元，这些单元被称为"token"，包括标识符、常量、运算符、关键字等。这是语法解析的前提。 4. **预处理语言**：预处理器有自己的编程语言，称为预处理器语言，它支持宏定义、条件编译（#ifdef/#ifndef/#if/#else/#elif）、文件包含（#include）等指令。这些指令允许程序员编写可扩展且可重用的代码片段。 **Header Files**部分进一步介绍了预处理器处理头文件的相关内容： - **包含语法（Include Syntax）**：`#include`指令用于引入其他源文件中的内容，使当前源文件能够使用外部库或自定义函数。预处理器负责解析这个指令并替换实际的文件内容。 - **包含操作（Include Operation）**：当遇到`#include`时，预处理器会查找指定的文件路径，读取并替换该文件中的内容，这可能会影响程序的行为和依赖关系。在整个C语言开发过程中，预处理器是不可或缺的一部分，它简化了代码复用、条件编译和平台特定代码的管理。理解预处理器的工作原理有助于程序员更高效地编写和维护C代码。版权信息表明，这本书遵循GNU Free Documentation License，允许用户自由复制、分发和修改文档，同时也支持通过购买由Free Software Foundation出版的书籍来支持GNU项目的开发。

Chapter 2: Header Files 10

with quote marks. Directories after ‘-I-’ are searched for all headers. Second, the directory

containing the current ﬁle is not searched for anything, unless it happens to be one of the

directories named by an ‘-I’ switch. ‘-I-’ is deprecated, ‘-iquote’ should be used instead.

‘-I. -I-’ is not the same as no ‘-I’ options at all, and does not cause the same behavior

for ‘<>’ includes that ‘""’ includes get with no special options. ‘-I.’ searches the compiler’s

current working directory for header ﬁles. That may or may not be the same as the directory

containing the current ﬁle.

If you need to look for headers in a directory named ‘-’, write ‘-I./-’.

There are several more ways to adjust the header search path. They are generally less

useful. See Chapter 12 [Invocation], page 55.

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:

/* 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

Chapter 2: Header Files 11

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. If ‘#pragma once’ is seen when scanning a header ﬁle, that ﬁle

will never be read again, no matter what.

‘#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

# 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

Chapter 2: Header Files 12

#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

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 10), 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.

Chapter 3: Macros 13

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 43), 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.

The ‘-isystem’ command line option adds its argument to the list of directories to search

for headers, just like ‘-I’. Any headers found in that directory will be considered system

headers.

All directories named by ‘-isystem’ are searched after all directories named by ‘-I’, no

matter what their order was on the command line. If the same directory is named by both

‘-I’ and ‘-isystem’, the ‘-I’ option is ignored. GCC provides an informative message when

this occurs if ‘-v’ is used.

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 will not be aﬀected. #pragma GCC system_header

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

On very old systems, some of the pre-deﬁned system header directories get even more

special treatment. GNU C++ considers code in headers found in those directories to be

surrounded by an extern "C" block. There is no way to request this behavior with a

‘#pragma’, or from the command line.

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 41) can never be deﬁned as a macro,

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

macros when you are compiling C++.

剩余80页未读，继续阅读

rtoax

粉丝: 2763
资源: 218

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

GNU C编译器选项详解GCC中文手册

GNU C/C++编译器GCC中文手册

GNU C与C++编译器GCC中文手册详解

The C Preprocessor

GCC中文手册 - GNU C/C++编译器详解

GCC中文手册：GNU C/C++编译器详解

GCC中文手册 - GNU C/C++ 编译器详解

GCC中文使用手册：GNU C编译器选项解析

GCC中文手册：GNU C/C++编译器选项解析

精细金属掩模板(FMM)行业研究报告 显示技术核心部件FMM材料产业分析与市场应用

最新资源

精细金属掩模板(FMM)行业研究报告显示技术核心部件FMM材料产业分析与市场应用