Re: [Boost-users] #include directives

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.