Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-02-05 15:34:31

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
>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:

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:

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

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

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

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

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at