Re: [Fresco-devel] Suggested addition to Coding Style-guide

On Sat, Apr 12, 2003 at 07:30:21PM -0400, Stefanus Du Toit wrote:
> On Sun, Apr 13, 2003 at 01:14:53AM +0200, Gabriel Dos Reis wrote:
> > When build times is really an issue, I believe using that using
> > things like precompiled headers helps much more than declaring by
> > hand which entity one uses.  At least, that is my exprience with
> > large projects.
> 
> Using a compiler cache should also all but completely eliminate this
> particular issue.

Yes and no.  A compiler cache lets you avoid rebuilding sometimes,
which this scheme also does (though a bit more, since there are times
when the head _has_ changed, e.g. in the signature of some method or
another, but this doesn't matter).  This scheme also speeds up
recompiles when they _do_ happen.

> I didn't realise that "regular" gcc supports precompiled headers these
> days. Since when is that the case?

It isn't the case.  gcc's mainline supports them, but no release does;
AFAIK they didn't even make it into 3.3 (which will be released any
time now).

> > A frightening downside of forward declaring "by hand" is the same as
> > why you don't want code-duplication: Every minor change needs to be
> > done at zillions of places, whereas including a forward declaration
> > header keeps the changes in one place.
> 
> I think this is a reasonable point. A decent place to draw the line
> for Fresco may be one file per directory, since for the most part
> things are fairly well compartmentalized.

Yes, if we do want to predeclare things, it should definitely be by
having a "foo-predcl.hh" header for files that don't want to include
"foo.hh" (or a "Foo-predcl.hh" header for files that don't want to
include "Foo/bar.hh", "Foo/baz.hh", etc.).  Having lots of copies of
the declarations spread out across dozens of files is bad.

I'm really not convinced that this is worth the hassle, though.  That
precompiled headers are on the horizon is one argument against taking
the trouble, though they're still probably some months away, so it's
not _that_ strong an argument (unless someone knows that they're in
3.3).  However, I suspect that the worst time-sink is not in our code,
but in the STL headers and _possibly_ OmniORB's generated headers.
Can we get some numbers on whether this change will actually make any
difference before doing it?

-- Nathaniel

-- 
"The problem...is that sets have a very limited range of
activities -- they can't carry pianos, for example, nor drink
beer."

This email may be read aloud.