On Fri, 06 Oct 2006 14:31:19 -0400, David Abrahams
For instance in boost/any.hpp we have...
#include "boost/config.hpp" #include
...(this is from boost_1_32_0).
Because people don't pay attention.
No, it's because there was never any consensus reached about which is correct, or even if one is more correct than the other.
Yeah, so let's use both, happily together :-) The OP asked why they were mixed, and provided an example from a single source file.
There was an IMHO justified proposal by Beman Dawes to replace the <> form (which was used for historical reasons)
I note that Beman is now using the <> form.
You all must have convinced him ;-)
That led to the following DR, which is IMHO only wasting committee time:
http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#370
I note that interpreting the standard according as proposed there would decisively render a huge body of existing practice non-compliant.
The standard should define its own terminology (or provide references). C99 defines (well, at least "describes") what a "source file" is, but not a header. I do not recall what C98 does, as I tend to use C99 for that kind of stuff; probably just the same as C99. Which means a consensus about what is _correct_ is very unlikely. Given the wording in the description of the first two forms of #include, however, I find the interpretation that non-standard includes should use the quoted form reasonable, except that why should the implementation specify how something like <iostream> is identified and where it is searched is beyond me; which makes the interpretation unreasonable: that part must refer to "user headers" :-) (But that's not the point. The point was why mixing #include forms in one source file). Whether any of the interpretations reflects the intent is another story. Whether it reflects existing practice is yet another.
For example:
#include
which is the standard recommended practice for people using Python's 'C' API, would suddenly become the wrong thing to do. So it's not clear to me, anyway, that it's a useful direction to be going in.
Recommended by whom? Being a bit (a lot) paranoid I would always
recommend the quoted form for non-standard "headers": should a name
clash occur (say the standard introduces smart_pointer.hpp, which I
have in my code) the quoted form will first perform an implementation
defined search --on the implementations I use-- before trying a fall
back on