Code Bloat g++

[Zack Weinberg]

On Sun, Feb 20, 2000 at 03:27:06PM -0800, Per Bothner wrote:
> Zack Weinberg <zack@wolery.cumb.org> writes:
> 
> > Well, I'd like to facilitate smaller debug info, but I'm not sure how
> > precompilation helps.
> 
> Well, there is an indirect way it can help:  I was talking about
> generating a repository of pre-compiled .o files.  Martin complained
> about the Makefile- and other hassles of managing repositories.
> Well, if we do both at the same time, the problems go away.
> 
> Specifically, assume pre-compiling foo.h produces foo.hx.
> The same driver program that generates foo.hx also generates foo.o
> (in the same target directory).  foo.o is generated *as if* by
> a foo.c containing:
>         #pragma implementation
>         #include "foo.h"
> except we foo.h as containing an implicit #pragma interface.
> We also put an annotation in foo.hx that we have generated a foo.o.

Aah, this makes a lot more sense now.

Problem is, this isn't the precompiled header scheme I had in mind.  I
was intending to do it with one monster precompiled header for an
entire *project*.  That sidesteps the semantic nasties associated with
what goes in foo.hx versus what goes in bar.hx when bar.h includes
foo.h, what happens when you play games with #defining tokens used in
foo.h, and so on.  It's also a bigger performance win when the
dominant term is reading zillions of tiny headers over NFS.

I also was contemplating a one-to-one scheme, but it didn't do any
work beyond basic tokenization.

...
> We're talking about two different kinds of debug info:  Debug info
> for types and declarations, and debug info for function bodies.
> My scheme helps with the former, not the latter, so the "final
> assembly output" is not an issue.
> 
> Again, if the problem of debug info is overwhelmingly that of
> function bodies, then my idea won't help much.

I was under the impression that the problem was with excessive
emission of unused template functions and associated debug info.

...
> I think most of the C++ header files that make pre-compiled
> header worthwhile are idempotent ones.  These are straight-forward
> to handle for both your pre-compilation scheme and for my idea,
> because we don't have to be concerned about conditionals.

You still have to worry about things like

#define _POSIX_SOURCE
#include <unistd.h>

Stuff like that is all over the standard headers, and if it doesn't
work right we're in deep trouble.

zw