Re: relative includes

From: vesa_karvonen (vesa_karvonen_at_[hidden])
Date: 2002-02-07 07:48:45

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

The first thing I would like to ask from you is to provide a list of 
books that have C or C++ source code snippets that use the #include 
<...> form to include anything else but either standard library 
headers or system headers (e.g. posix).

For each book that you are able to find, I promise to be able to list 
10 books that do not. In other words, if you find 10 books that use 
the #include <...> form for their own source files, I promise to find
100 books that do not.

I also claim that the average technical quality of the books that I 
will list, according ACCU reviewers, will be higher.

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.

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

#ifdef COMPILE_AS_APP
#include "otsikkotiedosto.h"
#else
#include <otsikkotiedosto.h>
#endif

everywhere so that you can choose which form to use?

Which form of include do you use inside the library to include its 
own source files?

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.

For instance, the company where I work, builds applications that 
consist of dozens of libraries and only relatively small "application 
core". Initially many of these libraries have been developed for use 
in only a specific application or for our own use. Which include form 
would you use for these libraries?

However, we have licensed some of the libraries to external 
developers and we (well I anyway) have plans to start moving many of 
these libraries to open source. Which include form would you use for 
these libraries now?

PRINCIPLE: Moving source code from one project or organization to 
another should not require changing it.

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.

The above rule is:
- easy to define
- not challenged by the C++ standard
- conforms to existing practice
- has extensive support in high quality C++ literature

> I would love to see an argument about this which appeals to
> reasoning stronger than "Bjarne thinks it should work this way"
> or "lots of people do it this way". So far, I never have.

It is most unfortunate that neither the C nor the C++ standard have 
the guts to clearly define what are the relationships of the 
following terms:
- header
- library header
- standard [C/C++] library header
- source file

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.