Boost logo

Boost :

From: Beman Dawes (beman_at_[hidden])
Date: 1999-07-29 07:14:34

At 08:02 PM 7/28/99 -0600, Greg Colvin wrote:
>From: Beman Dawes <beman_at_[hidden]>
>> At 07:03 PM 7/28/99 -0600, Greg Colvin wrote:
>> >> Hum... This might be a problem in theory, but in practice are
>> >> really any compilers out there that would prevent (2)? Anyone
>> >> of a real-world compiler with either of these limitations?
>> >
>> >I don't know about the real world (:-) but the standard seems to
>> >say you should use the "name" form for including files.
>> I have read paragraphs 2 and 3 several times and can't see any
>> difference, other that the ordering of sentances and "..." falling
>> back to <...>. Oddly enough, the only problem I ever had with a
>> compiler was with "..." although that was clearly a compiler bug.
>> What are you seeing that I am missing?
>Not much, that's why I said "seems to". We took these paragraphs
>verbatim from the C standard, and the rational says, in effect,
>"we wanted to say what these mean but couldn't" so its all pretty
>much implementation defined.

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.

> I had thought that the intent was
> <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".

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.

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.


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