Re: [boost] Coding guidelines - comments

From: Greg Chicares (chicares_at_[hidden])
Date: 2001-07-06 07:10:07

Beman Dawes wrote:
> 
[snip earlier discussion of #include <...> vs. "..."]

gcc and stlport use <...> for nonstandard headers.
Both are recognized as portable. Without some concrete
evidence of compilers that they're incompatible with
for this reason, it doesn't seem right to break boost
user's code. Either way should work.

Of course, the standard would overcome such reasoning,
if it really gave an answer. It looks like all this
stuff like 'q-char-seq' goes back to C89/90, since
a 1991 edition of Harbison & Steele mentions it.
I guess actual practice even then was divergent enough
that no crisp prescription could be standardized. All
I can conclude from the standard is that
 - there are two ways of including things
 - both have implementation-defined behavior
 - they're potentially different, but may work the same
 - #include<...> must work with standard headers

If you want to go ahead with a DR, read on.

> Using #include<...> relies on unspecified behavior.

Correct, according to 16.2/2. But so does #include"...",
according to 16.2/3, which also says ("If this search is
not supported") it's conforming to make both work the
same way.

> 16.2 paragraph 2
> (which supplies semantics for #include <...>) applies only to a "header",
> which in 1.4 paragraph 5 is defined as a standard library header.

  1.4/5 The names defined in the library have namespace
  scope (7.3). A C++ translation unit (2.1) obtains access
  to these names by including the appropriate standard
  library header (16.2). 

I'm not sure that's a restrictive definition of 'header'.

2.8 says that both <x> and "y" are header-names. Do they
both name headers though? Hmmm... <x> can only name a
header (16.2/2), while "y" names a source file (16.2/3),
so should "y" be a source-file-name for consistency?

'header' vs. 'source file': are they disjoint, or is
one a subset of the other? At first I would have
guessed that 'source file' is a superset and 16.2/3
chose that term so that we can include, e.g., a
template implementation file vector.cc in a vector
header (until we have export). But the same paragraph
speaks of repeating an unsuccessful search using <>,
so maybe all source files are headers, although
standard headers need not be physical files.

BTW, 2.1/4 says headers are lexed, yet the first three
steps of translation apply only to source files.

> (Actually, I think the standard is unclear. Take a look at 16.2 paragraph 2
> and tell me if you think "header" applies to both std lib and user
> includes.  I'll file a defect report if others agree that 16.2 para 2 is
> unclear.)

#include <...> has to apply to standard library headers,
else code in the standard doesn't conform. I think 16.2/2
says it also applies to any other 'header' the implementation
likes. If borland provides a header <windows> that it maps
to a file named 'win##includes.x' then that conforms. The
implementation makes that decision, not the standard or
the user.

One more thing.
  16.2/5 The implementation provides unique mappings
  for sequences consisting of one or more nondigits
  (2.10) followed by a period (.) and a single nondigit.
So "config.hpp" may be subject to a non-unique mapping,
whatever that would mean. Same for <iso646.h> .