On Fri, 06 Oct 2006 14:31:19 -0400, David Abrahams <dave@boost-consulting.com> wrote:
For instance in boost/any.hpp we have...
#include "boost/config.hpp" #include <boost/throw_exception.hpp>
...(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 <Python.h>
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 <smart_pointer.hpp>. Which means my code wouldn't break or silently change meaning. But then, I'd bet no future standard header name would have ".hpp" in the name :-) -- Genny.