Jesse,
I agree that we should not write code that is not conforming with the
specs; but this can be said about the scope of variables declared in a
'for' loop, signed/unsigned, 32 vs 64 bit... here we are talking about
something that would break 99,99% of the existing C++ code, and such a
compiler would never be considered "conforming", but only "picky".
Anyhow, to close the discussion: Xerces needs people that write code to
fix its bugs, and replacing #include <...> with #include "..." is just
wasting their time (unless GCC 5.x, cl 14.x or CC 13.x change their mind).
Alberto
Jesse Pelton wrote:
David may have a different answer, but as someone who spends a lot of
time wrestling with the issues on the Web caused by the sort of
reasoning you're using, I place a high value on code that conforms to
specifications. It may not be of much benefit today, but it can save
all kinds of trouble when you encounter some new processor of your code
(whether C++, HTML, or something else). If you write code in accordance
with the specification, you'll work with any new processor that
correctly implements the specification. If your code relies on existing
implementations as "de facto" standards, you're at the mercy of both
incorrect existing processors and correct future processors.
To paraphrase RFC 760: be liberal in what you accept, strict in what you
write.
-----Original Message-----
From: Alberto Massari [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 29, 2007 10:39 AM
To: [email protected]
Subject: Re: Including directive fails at compilation time
Hi David,
don't take it wrong, but my head is now spinning. My interpretation of
this thread is that you are worried by the fact that a (unnamed, maybe
not existent) compiler that interprets the C++ specs in a strict way
would not be able to compile Xerces because it uses <> in the headers.
Also, if Xerces used "", maybe this would not happen (I don't have the
specs, so I cannot check what that "very different" section says).
If this is true, who cares? Nobody ever complained about this compiler.
Xerces used to be compiled on AS/400, that should potentially be one of
these compilers, and it did have the <>-style includes...
Allow me to turn your "That's the point I was trying to make -- we are
relying on implementation-defined behavior for no tangible benefit"
question into:
Why should we rewrite our headers for no tangible benefit, if the
implementation-defined behavior for all the used compilers are fine with
it?
Alberto
David Bertoni wrote:
Alberto Massari wrote:
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.
You are reading it too liberally. Notice that user of the term
"header" rather than source file, and the fact that the standard uses
both the term "header" and "source file," and that "source file" is
never used in the section I quoted.
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?
Why would it be stupid? Some platforms don't implement their system
headers as files.
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"
Not necessarily. You are conflating <> and "", but I was only talking
about <>. The section in the standard for the #include "" directive
is very different.
and I think you agree that a specification forcing such a
preprocessor directive would be at minimum brain-dead and useless.
Limiting #include "" in the same way the standard allows limiting <>
would not be very useful, although it would still be compliant.
However, I'm not talking about the #include "" directive here at all.
I didn't even quote that section of the standard.
What I was saying is that Xerces-C uses #include<> to indicate the
implementation-defined behavior of "don't search in the current
directory of the source file." But that behavior is not guaranteed by
the standard.
We could change every #include<> directive in the source code to
#include "", and it wouldn't change anything, except make the code
more portable. That's the point I was trying to make -- we are relying
on implementation-defined behavior for no tangible benefit.
Dave
