Re: speeding up compile times in C++

imp@boulder.openware.com (Warner Losh)
Mon, 6 Feb 1995 18:31:40 GMT

          From comp.compilers

Related articles
speeding up compile times in C++ amichail@cs.toronto.edu (1995-01-26)
Re: speeding up compile times in C++ thutt@clark.net (1995-01-26)
Re: speeding up compile times in C++ glwinter@infi.net (1995-01-29)
Re: speeding up compile times in C++ shankar@sgi.com (1995-02-02)
Re: speeding up compile times in C++ glasss@ncp.gpt.co.uk (Steve Glass) (1995-02-03)
Re: speeding up compile times in C++ thutt@clark.net (1995-02-04)
Re: speeding up compile times in C++ rfg@rahul.net (Ronald F. Guilmette) (1995-02-04)
Re: speeding up compile times in C++ imp@boulder.openware.com (1995-02-06)
Re: speeding up compile times in C++ green@vizbiz.com (Anthony T. Green) (1995-02-06)
Re: speeding up compile times in C++ shankar@sgi.com (1995-02-08)
Re: speeding up compile times in C++ tmb@netcom.com (1995-02-12)
| List of all articles for this month |

Newsgroups: comp.compilers
From: imp@boulder.openware.com (Warner Losh)
Keywords: C++, performance
Organization: Openware Boulder
References: 95-01-073 95-02-058
Date: Mon, 6 Feb 1995 18:31:40 GMT

Amir Michail <amichail@cs.toronto.edu> wrote:
>One problem with writing large C++ projects is that changing one or two
>header files often results in much of the project being recompiled. This
>is partly due to the class hierarchies and derivation.


"Ronald F. Guilmette" <rfg@rahul.net> writes:
>An excelent paper on this topic is ``Encapsulating a C++ Library'' by
>Mark Linton. It appears in the 1992 USENIX C++ Conference Proceedings
>(pp. 57-66; ISBN 1-880446-45-6).
>
>If you are designing _any_ large body of C++ code, reading this paper
>is an absolute must.


Even with the techniques in this paper, there are a significant number
of problems with the current compiler technologies that will impact
both the compilation speed of library, and the extent that one can
change the library before users of the library are forced to
recompile.


The biggest two problems are adding data members, and adding virtual
functions. Both of these action require a recompile of the entire
class tree below the current node in the derevation tree. This is
commonly called the "fragile baseclass" problem.


Techniques of indirection do exist that will easily solve the first
problem, but the second one can only be worked around by adding a
bunch of extra virtuals and then using them as needed when you need a
virtual and doing unnatural casting to coerce things to be the right
types.


I heard a rumor at the X Technical conference that a new compiler from
SGI will solve many of these problems though clever use of
indirection, but I was unable to get more inforamtion than that. Does
anybody know if this is the case, and to what extent the fragile base
class problem is solved by this or other compilers?


Warner
--
Warner Losh imp@boulder.openware.com Openware Boulder
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.