Re: [Boost-users] #include directives

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2006-10-06 16:07:38

On Fri, 06 Oct 2006 14:31:19 -0400, David Abrahams
<dave_at_[hidden]> wrote:

>>>For instance in boost/any.hpp we have...
>>>
>>>#include "boost/config.hpp"
>>>#include <boost/throw_exception.hpp>
>>>
>>>...(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 <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? 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. But then, I'd bet no future standard header
name would have ".hpp" in the name :-)

--
Genny.