From: Noel Yap (yap_noel_at_[hidden])
Date: 2002-07-20 14:19:38
--- Ron Garcia <garcia_at_[hidden]> wrote:
> David Abrahams wrote:
> >From: "Beman Dawes" <bdawes_at_[hidden]>
> >>Should we being to transition Boost code to the
> more correct #include "boost/..." form?
> >Other libraries I know about that get installed in
> central locations on users' systems use <> by
> >convention as well.
> In your experience with Boost.Build, was any
> particular variations of
> behavior with regards to <> vs "" search paths more
> prevalent than others?
> My tendency has been to use angle brackets for
> standard headers and
> system files (note that I work in a mostly
> unix-centric environment),
> quotes for everything else. I mostly work on
> machines where I do not
> have the freedom to place headers wherever I please,
> which biases my view.
> With respect to your python example, do you know if
> any explicit
> decision was made, or could it just be the
> preference of the author of
> the example you shared.
> Finally, is there any technical benefit to one style
> over the other
> given the current state of compiler implementations?
IIRC, the difference between #include <> and #include
"" is that the latter will check the directory of the
includer for the included file before checking the
include path. If this is correct, I see two benefits
to using #include "" for files in the same directory
as the includer:
1. It has more of a guarantee of including the correct
file. In the past, I've experienced a problem of
including the wrong types.h due to this. OTOH, this
is less of a problem if, for example, "boost" were not
in the include path and developers prefixed includes
2. It should be a little faster if the included file
was in the same directory as the includer since the
precompiler won't have as much to search.
Personally, I prefer using #include "" in the case
when the inluded file is in the same directory as the
includer and #include <> otherwise.
Do You Yahoo!?
Yahoo! Health - Feel better, live better
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk