Re: [boost] On splitting headers

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-02-06 08:43:28

From: "Beman Dawes" <bdawes_at_[hidden]>
> At 03:16 PM 1/30/2002, vesa_karvonen wrote:
>
>  >--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
>  >[on splitting smart_ptr.hpp]
>  >> Yes, this has been my intent. In my experience a translation unit
>  >> rarely needs all four (now five) smart pointer classes.
>  >
>  >In my experience, any header which contains the interface of more
>  >than one thing ends up being splitted or consumes compiling time
>  >unnecessarily. Boost has many headers which have more than one
>  >interface.
>  >
>  >I think that it would be beneficial to make it a guideline in Boost
>  >to split components into headers so that every client of a header is
>  >expected to use all components declared in the header.
>  >
>  >I always shiver when I need to include <algorithm> in order to use max
>  >() or min().
>  >
>  >See the Interface Segregation Principle:
>  >
>  >http://www.objectmentor.com/resources/articles/Principles_and_Patterns
>  >.PDF
>
> But that is only one side of the equation.  The other side is the various
> costs that are known to occur with overly fine-grained headers.  All of
the
> following costs have been reported from the field:

What can I say. I disagree, on all counts.

> *  Increased errors by inexperienced programmers.  The saddest reports are
> the cases where the new programmer assumes the problem is his or her
fault,
> and destroys the program in the process of trying to discover what the
> compiler is complaining about.
>
> *  Increased errors by experienced programmers.  Experienced programmers
> recover immediately, but still complain of what is seen as an unnecessary
> burden.  The STL headers have been cited as specific examples of overly
> fine-grained headers.

Right, the standard headers have the wrong granularity. Fine-grained headers
don't have this problem. You know that std::allocator is in <std/allocator>,
and that std::multimap is in <std/multimap>.

> *  Difficulty teaching.  Teachers apparently don't want to have to explain
> much of the details of headers until later in a programming
> course.  Fine-grained headers get in the way of this.

See above.

> *  Intimidation factor.  Potential users of a library can be scared off by
> a large number of headers.  A potential Boost user decided against use
> because "Boost is for experts only - look at the number of headers."

Boost is a collection of libraries that have nearly nothing in common.
Providing <boost> will not solve the "problem." It will simply leave the
wrong "all or nothing" impression in users, leading to _less_ boost use
(fear of vendor lock-in.)

> *  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.

Providing a monolithic header means that everything depends on everything.
Any granularity is better than that.

> *  Increased compile time.  Depending on the performance characteristics
of
> the platform (particularly, slow to open files), large numbers of small
> headers can take longer to compile that larger granularity headers.

And of course, depending on the performance characteristics on the platform,
small headers can compile faster than large headers, simply because there is
less to compile.