Re: reduce compilation times?

[Tom St Denis <tstdenis at ellipticsemi dot com>]

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.

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.

Even if you're a one person shop.  It helps, especially if you use some 
form of revision control.  For example, if you've messed up a function, 
and changed over functions (and want to keep them), it's easier to 
restore one file from the last sane revision, then to patch one huge 
file with mix of current, unstable, old, code.  I've done that myself a 
few times.  I would be working on one of my libraries, and amongst say 
5-6 changes I'm making one of them doesn't pan out.  So I just nuke the 
file and cvs update it.  Boom, the last stable copy is back. 

Anyways... despite what others are saying, putting all of your eggs in 
one basket won't magically make the compiler be able to optimize the 
code significantly differently than what you could have with well 
factored code, and ideally created static inlines/macros.  All doing 
what they're saying gets you is a hard to maintain project.