Re: Code Bloat g++

[Mike Stump <mrs at windriver dot com>]

> From: Per Bothner <per@bothner.com>
> Date: 19 Feb 2000 15:22:42 -0800

> Hmm.  No comments on my "implicit #pragma-inferface" idea.

Kinda expected that.

I have an idea that is fundamentally the same (I think).  You have an
along side database, you add an argument to the compile line that
names the database you want to use for your project/executable.  The
argument can be implicit, if we want.  In the database, you store
whatever you want.  RTL for inlining across translation units, type
information for externals to do lint like checking, template storage,
debugging information storage, repo information, duplicate .h file
debugging information notes, profile feedback optimization
information.  In short, _any_ information the compiler wants to
manage.  Then, all those things that want to manage information, can
use this same interface and `solve' whatever problems they want.  For
instance, precompiled headers is an instance of my scheme.  The
database in that case is spread across multiple files, and implicitly
named (if I understand how people want to do precompiled headers).
The only problem, the database isn't quite reusable for other
purposes.  .rpo files (repo files for g++ template management) also
are an instance of an along side database in my world view.

I believe rms is somehow fundamentally opposed to this sort of scheme,
as then the output of the compiler is based upon hidden things that
the user can't see, thus leading to unnecessary obscuring of the
compiler.  He prefers a tool that can generate readable output, that
you can then feed into the compiler as a source file.  I suppose that
in my scheme, one can manage the database as a human readable file,
though, that would slow it down, and I can't quite bring myself to the
speed hit.  I instead prefer a dumper, if one wants to know what is in
the database.  For example, imagine a cluster of 10 computers with 8
processors each that is used in a massive -j240 compile on a project
with 4000+ files to compile.  Do you think that a single database that
must have a single lock on it, that will be held during a complete
rewrite out of the whole text file is doable?  I don't.

Any scheme that is less than this, is pointless to me, as it then only
solves one specific problem in a whole category of similar problems
that could have been solved once and for all, with just about the same
amount of work.

I've implemented a prototype of my scheme, and it did what I wanted.
That's the solution I prefer, despite rms's views.

Once you start with the concept of a generic along side database for
the compiler to use, then all these types of problems turn into a how
do I want to organize the data, how do I want to update that
information, and just what information do I want to track.  Far more
trivial than wondering, what if I have two compiles running and they
both want to update the info, what shall I name the new files, what if
the files I am reading are user only readable, shouldn't the database
also just be user read only to prevent information from escaping to
others?

Or maybe I am making a bigger deal of it then I need to and we are
better off with lots of little along side databases...