This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: reduce compilation times?

--- Tom St Denis <> wrote:

> Duft Markus wrote:
> > Hi!
> >
> > I assume, that all strategies discussed here are
> targeted at C. now what
> > about C++, how do things behave there? As far as i
> know C++ is much
> > different, and requires completely different
> thinking with regards to
> > splitting source in more files, etc.
> >   
> I don't know enough about C++ linking but there is
> no reason you can't 
> put methods in seperate .C files.  The problem is
> most C++ developers 
> want to inline all of their methods and put quite a
> bit of actual code 
> in their .H files instead, which is just a
> maintenance nightmare.
Well, that MAY be true of kids still wet behind the
ears, but it isn't true of experienced C++ developers
I know.  I prefer C++ for high performance code: in
fact my best C++ code is faster than my best fortran
code, but that is another story.

I routinely split my C++ classes across multiple
compilation units, sometimes to the point of one
function per compilation unit.  But sometimes there
are a handful of member functions that are
sufficiently closely related to warrant placing them
in the same compilation unit.  I put only that code in
a header file that could rationally be inlined.  There
are, in fact, a handful of best practices that have
developed over the years regarding helping the
compiler determine which functions to consider

The only exception to this is how we need to handle
template classes.  I deal with this, though, by
keeping my template classes as small as practicable
(and perhaps using a small family of related template
classes rather than a single catchall).  My
experience, though, is that once you start working
with template classes, especially with state of the
art template metaprogramming, compilation times
increase dramatically anyway, so you just bite the
bullet and deal with it.  But this gets into an area
where I wouldn't hand the task to a junior developer
anyway.  They just don't have the experience needed to
do it well.  I'd instead want to spend some time
giving them on-the-job training for a few years,
before letting them run with a template
metaprogramming task (I know of a few college programs
where C++ programmers aren't given so much as 5
minutes on generic programming, so the inability of
most junior C++ programmers to understand it isn't a

> The benefits of code factoring are hardly limited to
> C or C++.  They 
> equally apply to Java applications (with the sad
> exception, hehehe, that 
> your class has to be in one file, but you can
> refactor into smaller 
> classes, etc), pascal, assembler, etc.
Yeh, but it is a mistake to implement high performance
code in Java anyway, so neither compilation speed or
runtime performance is a major factor in choosing to
use it (rather, in my experience, it is the ease of
use and time to complete the coding for certain types
of application).  While it has improved over the
years, it still doesn't come close to C++ or fortran. 
Where Java has the edge is the ease with which
distributed programming can be done, and this is
because of the wealth of libraries supplied in the
J2SE and J2EE SDKs.  

I generally agree with the rest of what you said. 
Anyone who has been doing this a while, and learned
from that experience, will be using version control,
well factored compilation units (thought about rather
than just mindlessly munging things together or
dividing them), &c.  Dividing a class into multiple
compilation units gets you only so far.  If one of
your edits requires a change to the header file
containing the class declaration, then all the files
depending on it must be recompiled also, even though
you didn't touch them.  You have to think about how to
distribute your code, not just put it all into a
single file or distribute among countless files.  Both
ideas, mindlessly applied, are bound to get you into
trouble with a hard to maintain project.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]