From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-07-20 14:31:22
At 10:03 AM 7/20/2002, David Abrahams wrote:
>----- Original Message -----
>From: "Beman Dawes" <bdawes_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
>> 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
>> 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,
>The first line of our file can be:
> #include <Python.h>
>What really determines whether a library header file is a "header" or a
As Gennaro Prota mentioned, the only headers are C++ Standard Library
headers. The standard has no notion of a user header, only a user source
>What about other things outside the standard like threading support? Is
> #include <pthreads.h>
> #include "pthreads.h"
The rule is simple. pthreads.h isn't a C++ Standard Library header, it is
a source file, and so should be included with #include "pthreads.h"
This isn't anything new; both the "C Programming Language" and the "C++
Programming Language" books indicated that anything except the standard
library should be included with #include "...".
>I realize the standard has ideas about which is which, but existing
>practice may be more-important than what the standard says in this case.
Possibly, although we shouldn't assume that Boost practice is
universal. I've seen industrial code which is careful to maintain the
distinction between <...> and "...".
>> My personal feeling is that, yes, we should begin a gradual transition.
>> code should begin to use the #include "boost/..." form. Existing code
>> should be modified over time, particularly when other changes are being
>> made that will force recompilation anyhow.
>Making a gradual transition might not be that simple. Toolset support
>I don't mean Boost.Build, but the underlying toolsets here) for
>different search paths for "" and <> is inconsistent. Some of those
>toolsets force you to make those paths completely separate; some don't
>separate them at all. You can't always move something from <> to "" and
>expect it to get picked up. Certainly we are currently using <sysinclude>
>in Jamfiles to force (where possible) files to be found in the <> paths.
>I've tried, as much as possible, to make the Boost.Build toolsets behave
>that "" searches <include> followed by <sysinclude>, while <> searches
><sysinclude>, but as I've said underlying toolset support is
>so it wasn't always possible.
I've been experimenting with "..." includes in the filesystem library, and
it doesn't seem to break the build system in general. We do sometimes get
warning messages out of Metrowerks and GCC, which I haven't tried to pin
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk