9fans archive / 2000 / 08 / 55    prev next


    search terms are split using tokenize    
    from:regexp searches From: lines    
    subject:regexp searches Subject: lines    
    before:yyyy[/mm[/dd]] and after:yyyy[/mm[/dd]] specify date range    

    powered by grep(1)    
From: Bruce G. Stewart <bruce.g.stewart@wor...>
Subject: Installing the updates
Date: Wed, 2 Aug 2000 08:32:55 GMT

Russ Cox wrote:
> 
>         Where's the horror here?  Computers are fast.  Pushing extra work on
>         programmers and creating an unnecessary portability issue is a high
>         cost.  Reading a header file five or more times during compilation is
>         a low cost (and one which can be optimized away for ifdef-protected
>         headers; I'm told gcc does so).
> 
> While it may be simpler when it works, when
> it fails it does so in mysterious ways.  I don't know
> how many times I've tried to figure out why
> some header file I wanted wasn't getting included,
> only to find that it had _already_ been included,
> by someone else, with different things #defined,
> so the definition or prototype_I_ wanted wasn't
> there.
> 
> I'd much rather have the compiler barf on a
> #define or something like that, than hop over
> the whole file as though it weren't there.
> 
> Russ

I think nested includes also lead to excessive factoring - there is a
folklore that says small include files are better because fewer things
need to be recompiled when a header is changed.

More includes makes for more interdependencies, so one resorts to
nesting to reduce the amount of typing. Then one needs a tool to find
all the dependencies to create the mkfile. One wants to run it whenever
a header changes in case some new nested dependency has been introduced.
Perhaps a mkfile to mk your mkfile is the answer.. and on it goes.

I also find the one library / one h principal attractive. I'd rather
have the compiler wasting its time scanning one behemoth text than
scanning a lot of little files looking for #endif.