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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk