Message-Id: Comments: Authenticated sender is From: "Salvador Eduardo Tropea (SET)" Organization: INTI To: Shawn Hargreaves Date: Thu, 26 Jun 1997 15:33:15 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Precompiled headers. CC: djgpp AT delorie DOT com Precedence: bulk Shawn Hargreaves wrote: > Salvador Eduardo Tropea (SET) writes: > >You'll see that cpp is fast in comparisson with cc1plus. Now you can > >say: But it will speedup the cpp part and a 10% is usefull. For that > > But precompiled headers cut out a lot more than just the cpp stage! They > are a dump of already-parsed symbols and function tokens (for a gcc > implementation, I presume this would be something like the RTL > description for the compiled code). So you are removing not only the > preprocssing stage, but a lot of tokenising and syntax parsing work from > the compile stage as well. > This is obviously a tricky thing to implement in a reliable way: the > usual approach (at least in Visual C) seems to be to allow one > precompiled header per program (usually stdafx.h) and require it to come > at the very top of the file. You give a command line option to the > compiler telling it which file this is, and when it sees a #include > "stdafx.h" it will look for a file called stdafx.pch, which contains a > dump of the parsed file contents left over from a previous > compilation... So I guess the best isn't the precompiled headers but instead pre-parsed headers, they can be not so fast but much more easy to handle. Actually one complex thing is that you must recompile the precompiled headers if the user just adds a line of code before the point where the include is called. Of course nobody in this group will make such a thing but is nice discuse about how can be made ;-) > >I guess it works very well for Borland compilers because the preprosses > >part is equally fast than cpp but the real compiler is much more faster > >so the percent is greater. > > I think the point is that Windows programs, particularly ones that use > libraries like MFC or OWL, include an obscene amount of header files, > and these are mostly C++ code which contains a lot of complex class > definitions. MFC has about 200k of headers: that takes a long time to > parse! In a properly designed system you don't need that amount of crap > before you can start writing real code, so precompiling the headers > isn't so much of an issue... Look in the TVision include dir ;-) SET ------------------------------------ 0 -------------------------------- Visit my home page: http://www.geocities.com/SiliconValley/Vista/6552/ Salvador Eduardo Tropea (SET). (Electronics Engineer) Address: Curapaligue 2124, Caseros, 3 de Febrero Buenos Aires, (1678), ARGENTINA TE: +(541) 759 0013