🚀 go-pugleaf

In article <gnusenetraub-2412960039190001@dialup52.afn.org> Mauricio Tavares <raub@kushana.aero.ufl.edu> writes:
>        I am finding some very interesting behavior from #define and
>#ifndef/#ifdef.  Let's say that I have a header file called MyHeader.h.  This
>file is included by all my routines (they usually are in separate files).  Now
>that would not be very nice since it would include the very same include files
>(stdio.h and others) over and over again.  So, I thought if I use something
>like
>
>#ifndef MOOSE
>#define MOOSE
>#include <stdio.h>
>#include <X11/Xlib.h>
>#endif
>
>the code would only include *one* copy of these two include files.  What I am
>finding out is that is not the case.  Running C programs that have similar 
>conditional including of header files in gcc (Sparc), Think C (Mac), Borland
>TC++ 3.1 for Windows (PC), and SAS/C (Amiga) results in the same thing.  It
>really seems that the compiler simply *forgets* what was defined in the
>previous .c file and define them all over again.  As a result, my object files
>become unnecessarily large.  Yes, the executable seems to take care of that,
>but still I am using more disk space than I should.  I am open for suggestions
>as usual.

The compiler need only see something called a `translation unit' at the
point you are talking about.  So, yes, indeed, it won't know about
what happened or not in the previous .c file.

Do note that the extra space you are seeing will be symbol table
entries for things like function prototypes and such.  So, yes again,
if b.c uses printf and c.c uses printf, they will both have information
stating their needs for that routine.  That's just the way it works in
the so-called traditional compiler/linker setup.  I guess in a million
lines of code app, this can for sure eat up lots of space, but I never
particularly thought that I'd call this space unnecessarily large.
Especially with just the two headers you refer to.

Anyway, you know your machine and its constraints better than I.
As such, perhaps the following is best for your situation:
[pre]link together the more stable parts of your system.  That way,
you can keep the source seperate but still gather up some of the .o's
into a more conglamorative one).

- Greg
-- 
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
               Producers of Comeau C++ 4.0 front-end pre-release
 ***WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
 Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com / CIS:72331,3421