Boost logo

Boost :

From: Greg Colvin (gcolvin_at_[hidden])
Date: 1999-07-29 09:30:48

Sorry to be nitpicking so much here. It may not be that important what
convention Boost uses, but it is important to follow a convention, or
else some combination of command line switches, environment variables,
and where you compile from could suck in an inconsistent set of Boost

From: Beman Dawes <beman_at_[hidden]>
> ....
> I went back and read both the C standard and C rationale, and there
> is no indication that <...> is for system files, and "..." is for
> user files unless you want to deduce that from some rationale
> discussion of early C implementation search paths.

Yep -- its a strrtch I know. From K&R, first edition, page 86:

   To facilitate handling collections of #defines and declarations
   (among other things) C provides a file inclusion feature. Any
   line that looks like
      #include "filename"
   is replaced by the contents of the file filename. (The quotes
   are mandatory.) ...

No mention in this section of angle brackets, which appear on page
143 in the Input and Output chapter:

   Each source file that refers to a standard library function must
   contain the line
      #include <stdio.h>
   somewhere near the beginning. ... Use of the angle brackets < and >
   instead of the usual double quotes directs the compiler to search
   for the file in a directory containing standard header information
   (on Unix, typically /usr/include).

So users are taught to use the quoted for their own files and the
bracketed form for standard files. And despite the name usr,
users typically do not copy their own files into /usr/include,
since it is shared by other users of the system.

> > I had thought that the intent was
> >that:
> > <name> forms were intended for standard and system C++ headers;
> > <name.h> forms were intended for standard and system C headers;
> > "whatever" forms were intended for user source files;
> >where "headers" need not be files at all.
> Well, neither standard says anything about "intended for standard and
> system headers" or "intended for user source files".

I see the Standard's careful use of the term "file" for the quoted
form and "header" for the bracketed form as hinting back at this
convention, while struggling not to actually require a file system.

If anyone has access to an OS 360/370 compiler I'd be interested in
what the rules are there, since as I recall that system has a notion
"file" very different from the Unix/CPM/MSDOS tradition.

> The convention I have seen used a lot is that <...> is for headers
> that contain public interfaces to a library, while "..." is for
> headers which are part of the library's implementation and not part
> of its public interface. That, coupled with the implementation
> directory not being in the <...> path, keeps a user from
> inadvertently including an implementation header which isn't part of
> the public interface.

Yes, this is a reasonable convention, to the extent that a library is
seen as "system" code.

> Don't take my word of it. Look at various public libraries. I just
> grepped SGI's STL library, and it uses the <...> form for all
> headers, system or otherwise.

As does Oracle's C source code. But before Oracle I never used angle
brackets to include any source written by me or my company.

Boost list run by bdawes at, gregod at, cpdaniel at, john at