Re: [boost] #include <boost/...> to #include "boost/..." transition?

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

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 
file.

 >What about other things outside the standard like threading support? Is 
it
 >
 >    #include <pthreads.h>
 >
 >or
 >
 >    #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.
 >New
 >> 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.
 >>
 >> Comments?
 >
 >Making a gradual transition  might not be that simple. Toolset support 
(and
 >I don't mean Boost.Build, but the underlying toolsets here) for 
specifying
 >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 
so
 >that "" searches <include> followed by <sysinclude>, while <> searches 
only
 ><sysinclude>, but as I've said underlying toolset support is 
inconsistent,
 >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 
down.

--Beman