RE: [boost] On splitting headers (Re:Objectionstoremovingtheoldsmartpointerclasstemplates?)

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-02-05 22:29:23

> The C++ committee's LWG has been discussing headers recently.  I think that
> Bjarne was the most recent person to complain about the stl headers.  There
> is some discussion about providing a single <stl> to deal with that.  There
> is also discussion of a <std> header which includes all the C and C++
> standard headers.

Nothing about split headers prevents a library user or developer from providing
a single header for convenience.  I don't think promoting this practice would be
a wise example for the standard to set.

>  >Perhaps. I must admit that I fail to see the difficulty of teaching
>  >how to use #include. It shouldn't take many minutes.
>
> I think what the teachers are complaining about isn't the need to explain
> the concept of a header, but rather the need to teach which headers must be
> included to get which set of library features.

Well, even JAVA has split headers, so I find this hard to swallow since JAVA is
praised so highly as being 'easy to learn'.

>  >> *  Header dependency metric.  Header dependency is sometimes
>  >> measured, with a high numbers of dependencies seen as bad
>  >> practice.  Harder to avoid with fine-grained headers.  Very similar
>  >> to intimidation factor.
>  >
>  >Dependencies should not be measured in numbers of headers. It is a
>  >useless metric.
>
> But it is one that real programmers use, nevertheless.

Right.  But what we are interested in isn't the number of headers it's which
headers.   Personally, I don't care if a file needs 100 includes in the include
graph if that's what it takes to do the job.  But if it only needs 10 and
requires 100 that's bad. Which leads you right back to splitting headers.

>  >Ideally dependencies should be measured in how long it takes for the
>  >compiler to process the dependencies. Since lexing (and parsing)
>  >typically consumes most of the time taken by the processing of
>  >headers, an easy to compute, rather portable and usable metric is the
>  >bytes of code metric.
>
> It really depends on the system you are using.  On some systems, I/O times
> dominate, and the cost of opens is particularly high.

Yes, but be careful.  One 'combined header' might cause you to recompile and
link hundreds of files and dozens of libraries when only a few would have been
required with split headers.  So I think you need to consider the whole
compilation impact.

>  >My bet, which, I believe, is supported by John Lakos, is that the
>  >incremental development of large software systems can be made
>  >considerably more effective by using fine grained headers than
>  >coarsely grained headers. What I'm ultimately getting at is that
>  >modification of a single header should cause the recompilation of a
>  >minimal number of translation units. This simply can not be achieved
>  >by using coarsely grained headers.
>
> But "large software systems" are only one use of C++.  That's the point; if
> you totally optimize headers (or anything else) for a particular scenario,
> you are probably pessimizing for other environments.  Thus a balanced
> approach (mid-size granularity of headers) serves a wide variety of needs,
> although it certainly isn't optimal for all needs.

I guess having worked on a number of mammoth systems I'm just used to traipsing
over hundreds of directories and thousands of source files to get to find the
class or function of the moment.  It's just the nature of big systems.  However,
I can tell you it was a top priority to keep include dependencies down; not by
combining headers, but by splitting them.  The reason is testing and release.
Whenever you get things running (especially in 24X7 systems) it gets hard to
release things b/c any change might break the working system.    If the change
you make recompiles one component/library testing will be reduced b/c the
effects will be better understood.  However, if you have to recompile/relink
fifty libraries b/c of bad include structure release managers get very nervous
b/c it feels like you are replacing the whole system -- even if you didn't
change those libraries -- just recompiled them.  So usually avoiding one event
where you have to retest everything, or you can't release a feature b/c of the
impact outweighs all the compile times, training issues, and other downsides.

My 2 cents....

Jeff