> tinybyte wrote:
On Sun, 04 Jan 2004 12:00:31 -0800, bill wrote:
Normally foo.h is a standard header file, so it's path is not defined
in compiler option, but I am curious how compiler find it.
The fundamental difference is that when using "" the preprocessor begin
searching from the directory where it found the file enclosed between "".
Using <>, preprocessor begins from standard locations, such as
/usr/include.
Here's the relevant section from n869:
6.10.2 Source file inclusion
Constraints
[#1] A #include directive shall identify a header or source
file that can be processed by the implementation.
Semantics
[#2] A preprocessing directive of the form
# include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a
header identified uniquely by the specified sequence between
the < and > delimiters, and causes the replacement of that
directive by the entire contents of the header. How the
places are specified or the header identified is
implementation-defined.
[#3] A preprocessing directive of the form
# include "q-char-sequence" new-line
causes the replacement of that directive by the entire
contents of the source file identified by the specified
sequence between the " delimiters. The named source file is
searched for in an implementation-defined manner. If this
search is not supported, or if the search fails, the
directive is reprocessed as if it read
# include <h-char-sequence> new-line
with the identical contained sequence (including >
characters, if any) from the original directive.
To summarize, #include "" directives cause the implementation to search
in an implementation-defined manner for the source file indicated. If
this fails, it tries again using the search method that it normally uses
for #include <> directives (which is also implementation-defined).
Another (sort of) important difference is that #include <> directives
need not specify an actual source file - the implementation defines how
it determines what text is used to replace the directive.
The remainder of section 6.10.2 follows.
[#4] A preprocessing directive of the form
# include pp-tokens new-line
(that does not match one of the two previous forms) is
permitted. The preprocessing tokens after include in the
directive are processed just as in normal text. (Each
identifier currently defined as a macro name is replaced by
its replacement list of preprocessing tokens.) The
directive resulting after all replacements shall match one
of the two previous forms.134) The method by which a
sequence of preprocessing tokens between a < and a >
preprocessing token pair or a pair of " characters is
combined into a single header name preprocessing token is
implementation-defined.
[#5] The implementation shall provide unique mappings for
sequences consisting of one or more letters or digits (as
defined in 5.2.1) followed by a period (.) and a single
letter. The first character shall be a letter. The
implementation may ignore the distinctions of alphabetical
case and restrict the mapping to eight significant
characters before the period.
[#6] A #include preprocessing directive may appear in a
source file that has been read because of a #include
directive in another file, up to an implementation-defined
nesting limit (see 5.2.4.1).
[#7] EXAMPLE 1 The most common uses of #include
preprocessing directives are as in the following:
#include <stdio.h>
#include "myprog.h"
[#8] EXAMPLE 2 This illustrates macro-replaced #include
directives:
#if VERSION == 1
#define INCFILE "vers1.h"
#elif VERSION == 2
#define INCFILE "vers2.h" // and so on
#else
#define INCFILE "versN.h"
#endif
#include INCFILE
Forward references: macro replacement (6.10.3).
Footnotes:
134 Note that adjacent string literals are not concatenated
into a single string literal (see the translation phases
in 5.1.1.2); thus, an expansion that results in two
string literals is an invalid directive.
-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
