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

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

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

--Beman