Boost logo

Boost :

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2002-07-20 13:09:24


On Sat, 20 Jul 2002 10:03:23 -0400, "David Abrahams"
<david.abrahams_at_[hidden]> wrote:

>
>----- Original Message -----
>From: "Beman Dawes" <bdawes_at_[hidden]>
>To: <boost_at_[hidden]>
>Sent: Saturday, July 20, 2002 9:30 AM
>Subject: [boost] #include <boost/...> to #include "boost/..." transition?
>
>
>> As has been discussed many times in the past, the C++ standard provides
>> #include <...> for "headers" (which are only well-defined in the standard
>> for the standard library), and #include "..." for "source files" (which
>> includes the Boost header files). See section 16.2.
>>
>> For historical reasons relating to problem compilers, Boost code has
>always
>> used <boost/...> instead of "boost/...", and thus relies on
>> implementation-defined behavior (16.2/2).
>>
>> The historical reasons no longer apply. Should we being to transition
>> Boost code to the more correct #include "boost/..." form?
>
>I guess I really don't understand the issues here. Other libraries I know
>about that get installed in central locations on users' systems use <> by
>convention as well. For example,
>http://www.python.org/dev/doc/devel/ext/simpleExample.html says:
>
>The first line of our file can be:
>
> #include <Python.h>
>
>
>What really determines whether a library header file is a "header" or a
>"source file"?
>

Well, since you are one of the standard experts there must be
something wrong in what I know. So far I thought that in the standard
terminology 'header' is what we colloquially call 'standard header'.
In other words, there's no 'user header' like foo.hpp or
my_library.hpp. They are simply source files.

In fact, the wording of 16.2 confirms this belief (it speaks of
'header' for the #include <...> form and of 'source file' for the
#include "..." form). Moreover, a brute search of the expression
"standard header" in the whole standard yielded no occurrence in
normative text.

Opinion?

Genny.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk