Re: [Boost-users] #include directives

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2006-10-10 08:51:17

On Mon, 09 Oct 2006 10:19:39 -0400, David Abrahams
<dave_at_[hidden]> wrote:

>Gennaro Prota <gennaro_prota_at_[hidden]> writes:
>
>>>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? 
>
>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
>> <smart_pointer.hpp>. 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 <crypto.h>, clashing with my <crypto.hpp>.

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