Re: My try-out of the Felix Garbage Collector 1.1

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
>> <http://groups.yahoo.com/group/boost/files/flx_gc_1_1.zip> 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