cpp.texi

理解和实践操作系统的一本好书

@cindex header file
A header file is a file containing C declarations and macro definitions
(@pxref{Macros}) to be shared between several source files.  You request
the use of a header file in your program by @dfn{including} it, with the
C preprocessing directive @samp{#include}.

Header files serve two purposes.

@itemize @bullet
@item
@cindex system header files
System header files declare the interfaces to parts of the operating
system.  You include them in your program to supply the definitions and
declarations you need to invoke system calls and libraries.

@item
Your own header files contain declarations for interfaces between the
source files of your program.  Each time you have a group of related
declarations and macro definitions all or most of which are needed in
several different source files, it is a good idea to create a header
file for them.
@end itemize

Including a header file produces the same results as copying the header
file into each source file that needs it.  Such copying would be
time-consuming and error-prone.  With a header file, the related
declarations appear in only one place.  If they need to be changed, they
can be changed in one place, and programs that include the header file
will automatically use the new version when next recompiled.  The header
file eliminates the labor of finding and changing all the copies as well
as the risk that a failure to find one copy will result in
inconsistencies within a program.

In C, the usual convention is to give header files names that end with
@file{.h}.  It is most portable to use only letters, digits, dashes, and
underscores in header file names, and at most one dot.

@menu
* Include Syntax::
* Include Operation::
* Search Path::
* Once-Only Headers::
* Computed Includes::
* Wrapper Headers::
* System Headers::
@end menu

@node Include Syntax
@section Include Syntax

@findex #include
Both user and system header files are included using the preprocessing
directive @samp{#include}.  It has two variants:

@table @code
@item #include <@var{file}>
This variant is used for system header files.  It searches for a file
named @var{file} in a standard list of system directories.  You can prepend
directories to this list with the @option{-I} option (@pxref{Invocation}).

@item #include "@var{file}"
This variant is used for header files of your own program.  It
searches for a file named @var{file} first in the directory containing
the current file, then in the quote directories and then the same
directories used for @code{<@var{file}>}.  You can prepend directories
to the list of quote directories with the @option{-iquote} option.
@end table

The argument of @samp{#include}, whether delimited with quote marks or
angle brackets, behaves like a string constant in that comments are not
recognized, and macro names are not expanded.  Thus, @code{@w{#include
<x/*y>}} specifies inclusion of a system header file named @file{x/*y}.

However, if backslashes occur within @var{file}, they are considered
ordinary text characters, not escape characters.  None of the character
escape sequences appropriate to string constants in C are processed.
Thus, @code{@w{#include "x\n\\y"}} specifies a filename containing three
backslashes.  (Some systems interpret @samp{\} as a pathname separator.
All of these also interpret @samp{/} the same way.  It is most portable
to use only @samp{/}.)

It is an error if there is anything (other than comments) on the line
after the file name.

@node Include Operation
@section Include Operation

The @samp{#include} directive works by directing the C preprocessor to
scan the specified file as input before continuing with the rest of the
current file.  The output from the preprocessor contains the output
already generated, followed by the output resulting from the included
file, followed by the output that comes from the text after the
@samp{#include} directive.  For example, if you have a header file
@file{header.h} as follows,

@smallexample
char *test (void);
@end smallexample

@noindent
and a main program called @file{program.c} that uses the header file,
like this,

@smallexample
int x;
#include "header.h"

int
main (void)
@{
  puts (test ());
@}
@end smallexample

@noindent
the compiler will see the same token stream as it would if
@file{program.c} read

@smallexample
int x;
char *test (void);

int
main (void)
@{
  puts (test ());
@}
@end smallexample

Included files are not limited to declarations and macro definitions;
those are merely the typical uses.  Any fragment of a C program can be
included from another file.  The include file could even contain the
beginning of a statement that is concluded in the containing file, or
the end of a statement that was started in the including file.  However,
an included file must consist of complete tokens.  Comments and string
literals which have not been closed by the end of an included file are
invalid.  For error recovery, they are considered to end at the end of
the file.

To avoid confusion, it is best if header files contain only complete
syntactic units---function declarations or definitions, type
declarations, etc.

The line following the @samp{#include} directive is always treated as a
separate line by the C preprocessor, even if the included file lacks a
final newline.

@node Search Path
@section Search Path

GCC looks in several different places for headers.  On a normal Unix
system, if you do not instruct it otherwise, it will look for headers
requested with @code{@w{#include <@var{file}>}} in:

@smallexample
/usr/local/include
@var{libdir}/gcc/@var{target}/@var{version}/include
/usr/@var{target}/include
/usr/include
@end smallexample

For C++ programs, it will also look in @file{/usr/include/g++-v3},
first.  In the above, @var{target} is the canonical name of the system
GCC was configured to compile code for; often but not always the same as
the canonical name of the system it runs on.  @var{version} is the
version of GCC in use.

You can add to this list with the @option{-I@var{dir}} command line
option.  All the directories named by @option{-I} are searched, in
left-to-right order, @emph{before} the default directories.  The only
exception is when @file{dir} is already searched by default.  In
this case, the option is ignored and the search order for system
directories remains unchanged.

Duplicate directories are removed from the quote and bracket search
chains before the two chains are merged to make the final search chain.
Thus, it is possible for a directory to occur twice in the final search
chain if it was specified in both the quote and bracket chains.

You can prevent GCC from searching any of the default directories with
the @option{-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.
@option{-I} options are not ignored as described above when
@option{-nostdinc} is in effect.

GCC looks for headers requested with @code{@w{#include "@var{file}"}}
first in the directory containing the current file, then in the
directories as specified by @option{-iquote} options, then in the same
places it would have looked for a header requested with angle
brackets.  For example, if @file{/usr/include/sys/stat.h} contains
@code{@w{#include "types.h"}}, GCC looks for @file{types.h} first in
@file{/usr/include/sys}, then in its usual search path.

@samp{#line} (@pxref{Line Control}) does not change GCC's idea of the
directory containing the current file.

You may put @option{-I-} at any point in your list of @option{-I} options.
This has two effects.  First, directories appearing before the
@option{-I-} in the list are searched only for headers requested with
quote marks.  Directories after @option{-I-} are searched for all
headers.  Second, the directory containing the current file is not
searched for anything, unless it happens to be one of the directories
named by an @option{-I} switch.  @option{-I-} is deprecated, @option{-iquote}
should be used instead.

@option{-I. -I-} is not the same as no @option{-I} options at all, and does
not cause the same behavior for @samp{<>} includes that @samp{""}
includes get with no special options.  @option{-I.} searches the
compiler's current working directory for header files.  That may or may
not be the same as the directory containing the current file.

If you need to look for headers in a directory named @file{-}, write
@option{-I./-}.

There are several more ways to adjust the header search path.  They are
generally less useful.  @xref{Invocation}.

@node Once-Only Headers
@section Once-Only Headers
@cindex repeated inclusion
@cindex including just once
@cindex wrapper @code{#ifndef}

If a header file 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 definition 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 file in a conditional, like this:

@smallexample
@group
/* File foo.  */
#ifndef FILE_FOO_SEEN
#define FILE_FOO_SEEN

@var{the entire file}

#endif /* !FILE_FOO_SEEN */
@end group
@end smallexample

This construct is commonly known as a @dfn{wrapper #ifndef}.
When the header is included again, the conditional will be false,
because @code{FILE_FOO_SEEN} is defined.  The preprocessor will skip
over the entire contents of the file, and the compiler will not see it
twice.

CPP optimizes even further.  It remembers when a header file has a
wrapper @samp{#ifndef}.  If a subsequent @samp{#include} specifies that
header, and the macro in the @samp{#ifndef} is still defined, it does
not bother to rescan the file at all.

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

@cindex controlling macro
@cindex guard macro
The macro @code{FILE_FOO_SEEN} is called the @dfn{controlling macro} or
@dfn{guard macro}.  In a user header file, the macro name should not
begin with @samp{_}.  In a system header file, it should begin with
@samp{__} to avoid conflicts with user programs.  In any kind of header
file, the macro name should contain the name of the file and some
additional text, to avoid conflicts with other header files.

@node Computed Includes
@section Computed Includes
@cindex computed includes
@cindex macros in include

Sometimes it is necessary to select one of several different header
files to be included into your program.  They might specify
configuration parameters to be used on different sorts of operating
systems, for instance.  You could do this with a series of conditionals,

@smallexample
#if SYSTEM_1
# include "system_1.h"
#elif SYSTEM_2
# include "system_2.h"
#elif SYSTEM_3
@dots{}
#endif
@end smallexample

That rapidly becomes tedious.  Instead, the preprocessor offers the
ability to use a macro for the header name.  This is called a
@dfn{computed include}.  Instead of writing a header name as the direct
argument of @samp{#include}, you simply put a macro name there instead:

@smallexample
#define SYSTEM_H "system_1.h"
@dots{}
#include SYSTEM_H
@end smallexample

@noindent
@code{SYSTEM_H} will be expanded, and the preprocessor will look for
@file{system_1.h} as if the @samp{#include} had been written that way
originally.  @code{SYSTEM_H} could be defined by your Makefile with a
@option{-D} option.

You must be careful when you define the macro.  @samp{#define} saves
tokens, not text.  The preprocessor has no way of knowing that the macro
will be used as the argument of @samp{#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 first non-whitespace character after @samp{#include} is
not @samp{"} or @samp{<}, 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 file to be included.  CPP does not re-examine the
string for embedded quotes, but neither does it process backslash
escapes in the string.  Therefore

@smallexample
#define HEADER "a\"b"
#include HEADER
@end smallexample

@noindent
looks for a file named @file{a\"b}.  CPP searches for the file according
to the rules for double-quoted includes.

If the line expands to a token stream beginning with a @samp{<} token
and including a @samp{>} token, then the tokens between the @samp{<} and
the first @samp{>} are combined to form the filename to be included.
Any whitespace between tokens is reduced to a single space; then any
space after the initial @samp{<} is retained, but a trailing space
before the closing @samp{>} is ignored.  CPP searches for the file
according to the rules for angle-bracket includes.

In either case, if there are any tokens on the line after the file 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-defined behavior according to the C
standard.  To minimize the risk of different compilers interpreting your
computed includes differently, we recommend you use only a single
object-like macro which expands to a string constant.  This will also