Gennaro Prota
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?
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?" 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