From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-02-07 13:21:16
From: vesa_karvonen [mailto:vesa_karvonen_at_[hidden]]
> --- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> > I agree with you that consistency is important. I don't have a
> > strong opinion about which way is "correct".
> Proof by intimidation follows... :)
I wasn't intimidated.
> Don't take this too seriously! I hope that you understand what I'm
> getting at. "De facto" standards and "existing practice" are very
> important considerations.
That's true, unless there's benefit to creating new "existing practice" and
forming a new "de facto" standard.
> > I think on compilers
> > that distinguish "..." from <...> there are advantages to the user
> > to being able to include everything in his application with "..."
> > and everything outside with <...>, but I'm open to other schemes.
> What if a library is also an application? Do you then use:
How can a library be an application? Either you're building one or the
> #ifdef COMPILE_AS_APP
> #include "otsikkotiedosto.h"
> #include <otsikkotiedosto.h>
> everywhere so that you can choose which form to use?
No, of course not.
> Which form of include do you use inside the library to include its
> own source files?
The distinction is between code that goes into a library or shared library
versus code compiled directly into the application. Any code coming from a
library, regardless of whether your platform supplied that library or you
developed it in house, or you secured the library from some third party,
could be identified by the <...> form. Any code not in a library could be
identified by the "..." form.
> The main problem I see with your argument is the problem of defining
> what exactly defines "everything in his application" and "everything
> outside". Especially because such things are very likely to change
> over time as the code base evolves.
If code moves from the application to a library, then the above scheme
requires maintenance to update the include directives for the moved files.
> PRINCIPLE: Moving source code from one project or organization to
> another should not require changing it.
That's a reasonable principle. I hadn't considered the impact of moving a
file from an application to a library, even though I've used the <...> for
libraries, "..." for apps approach for years. OTOH, I hadn't considered the
impact because I almost never moved files across that boundary between app
and library, so I'm not sure it's a big deal. Besides, everything -- aside
from test apps -- in Boost is a library, so Boost can adopt the <...> form
with near impunity.
> The only clear conclusion that I can draw based on the C++ standard,
> existing practice and the desire to find a simple and easy way to
> choose the proper form of include is that:
> - #include <...> is reserved for standard library headers and
> - #include "..." is for everything else.
That is a simple, reasonable rule. Given the chance that one might need to
move a file across the boundary (between app and lib), the rule is even
> The above rule is:
> - easy to define
> - not challenged by the C++ standard
Neither is the <...> form for all library code challenged by the Standard.
The Standard doesn't specify matters either way.
> - conforms to existing practice
It conforms to much, but certainly not all, existing practice.
> - has extensive support in high quality C++ literature
It may be, however, that those you claim support your position may simply do
it by habit rather than conscious choice.
> My conclusion is that the term "header" technically refers to a
> standard library header. I couldn't find anything in the standard
> that would use the term "header" to refer to a user defined files.
> The term "source file" refers to user defined source files.
A generic term for what is often referred to as a "header file" is "include
file." Thus, "include file" is still a source file, as distinguished from
an "implementation file." But, convention is hard to break -- it is, after
all, the basis for your argument to use "boost/..." rather than
"<boost/...>" -- so I don't think trying to reserve "header file" for
standard library include files is doomed to fail.
Susquehanna International Group, LLP
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk