Re: #include what?

Chris F Clark wrote:


> Following what gcc does is certainly a good model. And it is true
> that the C standard is intentionally vague about what the search rules
> mean. This is because in certain circumstances the machine/OS on
> which the compiler is being run may have no concept of directory (at
> least not like the Unix/Windows/Mac world knows about it). Note, I
> have never programmed on such a system, nor even know if such things
> actually exist.


A native development system may implement an appropriate structure as
well, so that a port to weird systems will not require too many
changes to the source code and makefiles.




> By the way, the standard was specifically designed so that #include
> <xxx> need not reference any actual include file at all, and might be
> just some symbol table entries built-into the compiler. In theory
> this model was espoused by Algol-68, which had a "standard library
> prelude" which could either be something the compiler read or
> something built-into the compiler.


Thanks for that hint! I already used a IncludeOnlyOnce flag, to
prevent further processing of already processed header files. Now it
might be a good idea to distinguish between <system> and "other"
header files, so that this flag only applies to system headers.


Other languages distinguish more explicitly between true "header"
files, containing invariant declarations, and "source" files, which
always have to be inlined.




BTW, #include_next IMO is part of cross-compiler support, where a
single header file can be split into an general part and OS and
machine specific parts. The include path then can be constructed from
--target and similar options, so that #include_next will search the
appropriate target specific directories.




Sorry for the late response, my machine broke and I've been offline
for a week.


DoDi

Return to the comp.compilers page.
Search the comp.compilers archives again.