RE: [boost] Re: relative includes

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

> #ifdef COMPILE_AS_APP
> #include "otsikkotiedosto.h"
> #else
> #include <otsikkotiedosto.h>
> #endif
> 
> 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
better.

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

Rob
Susquehanna International Group, LLP
http://www.sig.com