On Fri, 06 Oct 2006 14:31:19 -0400, David Abrahams wrote:

...

...

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 . 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.

On Mon, 09 Oct 2006 10:19:39 -0400, David Abrahams wrote:

Gennaro Prota writes:

...

...

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?

The Python documentation. Heh, whoops; I just checked and it doesn't recommend that anymore. Maybe I'm mistaken altogether, or maybe it changed at some point. What about other nonstandard libraries? Do they all recommend #include with quotes?

What I have generally seen, and I may well be wrong about this, is something like "to use the library, put the following #include in your code". My feeling has always been that there was not much thought behind the choice of the form (<> vs. "").

...

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 . Which means my code wouldn't break or silently change meaning.

Yes, but is a Boost library header "one of yours" or does it "belong to the system?"

I wasn't distinguishing between mine and system's sources; just between C++ implementation's and others. Note that the implementation mapping may be limited to 1 character after the last dot, so there's the (real?) danger that C could introduce, for instance, something like , clashing with my .

There's the rub, and you could use the same argument. If you have your own boost/foobar.hpp and the system administrator installs a new Boost with a foobar.hpp header, which one is picked up by Boost's boost/baz.hpp header?

Fortunately, I think we're fairly well-protected from all this nonsense by the boost/ prefix on all our #includes.

Yes. Until some years ago I used to avoid any prefix when one of my .cpp files included something in its same directory. I take care to organize my source tree in a way which reflects the logical organization of the library components, so that for instance I have root/ | +--- operator | +--- meta/ | ... Now, a width.hpp in meta/ would for instance include highest_bit_position.hpp in the same dir by simply doing: #include "highest_bit_position.hpp" The intent of this was that if anyone wanted to move the whole meta/ directory somewhere else then everything kept working: the subsystem was "relocatable". After considering the name clashing possibilities however I have switched to fully prefixed ""-includes everywhere. -- Genny.