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.