delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1996/11/10/15:01:14

From: root AT jacob DOT remcomp DOT fr (root)
Subject: lazy header files processing
10 Nov 1996 15:01:14 -0800 :
Sender: daemon AT cygnus DOT com
Approved: cygnus DOT gnu-win32 AT cygnus DOT com
Distribution: cygnus
Message-ID: <m0vMfmh-000ALAC.cygnus.gnu-win32@jacob.remcomp.fr>
Original-To: gnu-win32 AT cygnus DOT com
Original-Sender: owner-gnu-win32 AT cygnus DOT com

At last count, windows.h has (in its now compressed form) more than 13.000
lines and 450K.

In a normal compilation only 5% of this mass of information will be actually
used. The compiler has to build countless typedefs, defines, etc, that make
probably like 600-700K of RAM, to discard it again.

I'm thinking of building a windows.gph (Gnu Precompiled Header), that would
have a digest of that information. It would consist of the identifier, and
a file pointer to the textual definition of the symbol.

Now, when the preprocessor sees a symbol, it would look it up in that database
and directly define the symbol or call the compiler procedure that defines
a typedef or sees a prototype. This would implement a lazy evaluation of
symbols, only defining the symbols that are actually used, instead of defining
everything greatly reducing compilation time and memory requirements.

Of course this has to be recursive, so that when processing a definition, any
as yet undefined symbols will provoke a recursion to define the new missing
symbol.

Gnu has built a gdbm hashed data-base under Unix. Could it be used to 
implement this?

-- 
Jacob Navia	Logiciels/Informatique
41 rue Maurice Ravel			Tel 01 48.23.51.44
93430 Villetaneuse 			Fax 01 48.23.95.39
France
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019