Alberto Massari wrote:
Hi David,
as far as I know, using #include "..." means "include this file using
the given path relative to the folder where the cpp file is located",
while using #include <...> means "do like before, and if you don't find
it, repeat the process with each folder specified in the INCLUDE list".
It is not reserved for system headers, and Xerces-C doesn't violate any
rule.
What I meant to say is that when you use <>, it is implementation-defined
what happens. That is to say, it is possible for an implementation refuse
to process non-implementation files included using <>. Here's the relevant
section of the C99 standard:
"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."
So a conforming implementation could do the following:
1. Not have any files for implementation-defined headers.
2. Recognize only the names of implementation-defined headers.
3. Do textual substitution of implementation-defined headers from
hard-coded values.
4. Refuse to find anything that's not a implementation-defined header.
Note that how places to search are specified, and the algorithm you stated
are all implementation-defined. The only requirement provided by the
standard is that if finding a file included by "" fails, the implementation
reprocesses the include directive as if it we're done using <>.
Although most compilers implement the algorithm you've stated, it's not a
requirement. Given that, I don't see any value with using <> for
user-defined headers.
Dave
