Alberto Massari wrote:
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).
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. You and
Vitaly insisted that the algorithm you stated is somehow codified in the
standard, and I stated that it's not.
In the past, I have experienced compilers that implemented different search
algorithms for #include<> and include "" and the solution was to simply
right the code with #include "" unless you're trying to get one of the
standard headers or a implementation-defined header.
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...
I care, but I probably don't care enough to change the Xerces-C code. I
also wouldn't change it unless all the committers agreed that we should do it.
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?
Again, why are you assuming I'm saying we should do this? I never said
anything of the sort. I only pointed out that there's no tangible benefit
to use #include <> with non-implementation files, and you risk some
compiler in the future refusing to play with you if you do so.
Dave
