David Bertoni wrote:
Vitaly Prapirny wrote:
David Bertoni wrote:
I'm not saying it would ever happen. I simply made a statement about
what the C and C++ standards say a conforming implementation could do.
That's your words: "Standard C++ reserves <> for system headers, and
Xerces-C violates that." But standard does not restrict <>-headers
to only system headers. All it says is that ""-headers are source files
only but <>-headers are not. Usage of the <> form is the common practice
in other libraries (look at the boost library for example).
Yes, and I made it clear in subsequent posts that I wasn't clear about
what I was trying to say.
You also just said the standards makes the distinction between "headers"
and "files." Since Xerces-C, which is not part of the implementation,
uses "files," a conforming implementation might no be able to find
Xerces-C's _files_ with #include<>. That was my point.
Yes, standard makes distinction between "header" and "file". "Header" is
broader concept than "file". "File" in #include is always "header", but
there could be "headers" that not "files". And #include<> should be able
to work with files because '#include "file"' fallback to '#include
<file>' according to the standard. And conforming implementation might
not be able to find Xerces-C's files with #include<> only because of
not searching in Xerces-C's folders but not because they are files. And
#include"" have the same imperfection.
Whether it's "common practice" or not, code shouldn't rely on
non-standard behavior to work. Especially when there's no tangible
benefit from doing so.
I imply that it's "common practice" (and used in the boost library)
because it's standard conformant usage.
Good luck!
Vitaly
