Re: [boost] Re: relative includes

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-02-07 16:40:01

----- Original Message -----
From: "vesa_karvonen" <vesa_karvonen_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, February 07, 2002 7:48 AM
Subject: [boost] Re: relative includes

> --- 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 do understand, and no I don't take it too seriously. Libraries (especially
in C++) are grossly under-covered in the literature. When you do see library
headers included, they are typically either the C++ standard headers or the
Posix headers.

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

What library is also an application? I know of applications which draw
almost exclusively on an associated library, but that's not quite the same
thing.

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

Personally, if they were in-house libraries not likely to be distributed
outside my company, I'd use "...". But don't ask me to provide reasoning;
that's just a convention I've used.

> 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

And other headers that come with the platform? What about pthread.h, or
whatever it's called?
What about Mac Toolbox headers? What about windows.h? If I take you at your
word, they're in the next category despite the fact that all documentation
that comes with these artifacts tells the user to use <...>.

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

That's my interpretation also, but I don't see how clearer definitions would
help us decide between "..." and <...>.