Boost logo

Boost :

From: Daryle Walker (darylew_at_[hidden])
Date: 2001-05-20 13:03:16

on 5/20/01 9:16 AM, John Max Skaller at skaller_at_[hidden] wrote:

> Daryle Walker wrote:
>> I gave the project at
>> <> a little test run,
>> and here's what occurred:
>> - I had to add some <assert.h> #includes. I guess you assumed that an
>> indirect #include would work. Don't do that since a header on different
>> platforms may have different inner #includes, so an indirect #include isn't
>> guaranteed to be portable.
> AFAIK Standard headers are not allowed to provide any (user) symbols other
> than the ones specified in the Standard. Since this got past gcc 9.5, it isn't
> conforming. My assumption was that the compiler was conforming, not that some
> include or other would work (i.e. I expected the compiler to tell me if I made
> a mistake).

You mean 2.95 for your GCC version, right?

I don't think conformance in the way you're thinking of is possible with
today's technology. I think all #includes work today by text dumps, so a
header that includes another header has to "leak" the symbols from the inner
#include. You should ignore that effect and directly #include the headers
for any symbol you directly use.

Since <cassert> is supposed to help with user debugging, why would any
standard header #include it?

Sometimes taking "advantage" of inner #includes can't be avoided. Your
compiler doesn't have conforming C++ I/O. It still maintains the old C++
model of all the I/O stuff being jammed in <iostream>. So I get suggestions
to assume the existence of std::ostream and std::endl from <iostream>
instead of directly #including <ostream> (and <iosfwd>).

> Fixed, thanks.
[SNIP concerns about use of #line]

Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

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