Re: [Boost-users] #include directives

From: David Abrahams (dave_at_[hidden])
Date: 2006-10-09 10:19:39

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?

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

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com