Hi David,
I think you are interpreting the specs in a very strict way. As I read
it, "it searches a sequence of implementation-defined places for a
header" means that some compilers could look for an INCLUDE environment
variable, or process a list of command line options like /I, or (like
Borland) read the content of a bcc.cfg configuration file; but,
regardless of the method each compiler chooses, there is a list of
folders somewhere to search in.
As for recognizing only a fixed set of header names, that would be
stupid; why have a set of folders where to search, if you only recognize
string.h?
Anyhow, assuming there is a compiler that doesn't allow the
specification of the "sequence of implementation-defined places" and so
only allows for a predefined set of header names between the <>, the
user would be forced to write in his CPP file something like
#include "/usr/include/xercesc/dom/DOM.hpp"
or
#include "../../../xercesc/dom/DOM.hpp"
and I think you agree that a specification forcing such a preprocessor
directive would be at minimum brain-dead and useless.
Alberto
David Bertoni wrote:
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
