Re: Including directive fails at compilation time

[Vitaly Prapirny <ma...@mebius.net>]

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