Re: [Boost-users] Header file granularity policy?

From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2006-08-19 12:47:00

"Robert Ramey" <ramey_at_[hidden]> wrote in message 
news:ec7aiq$mni$1_at_sea.gmane.org...
> Jeff Garland wrote:
>
>>> Is there some kind of Boost convention or policy
>>> on whether a library should offer a comprehensive "declare
>>> everything in the library" header in addition to more targeted
>>> headers?
>
> Personally, I avoid the "comprehensive" headers.  I personally
> feel uncomfortable with the idea if including unused stuff
> as a side effect.  This is especially true now that this
> extra stuff may include templates.
>
> This is one reason that the serialization library has no such
> "comprehensive" header defined.  The other reason is that
> it's not clear how much such a header might include - all
> possible archives? all stl serialization. etc.  Finally, at
> least in the serialization library, the mere inclusion of
> a header can result in the instantiation of code which
> is never called - thereby adding to code bloat.
>
> So, I think the issue would be best addressed by discouraging
> the creation and usage of "comprehensive" headers.  Of
> course, for me that is not a big issue as I avoid their usage
> in any case.

IMO, lack of comprehnsive headers make those libraries more difficult to 
learn, and more intimidating than need be. Typically, when learning a new 
library, many coding shortcuts are taken in the context of a simple test 
program that would not be dreamt of in the context of a complete 
application. This is all done in an effort to focus on mastering the main 
points of the library. Later the other details are addressed when one is 
confident of the main points of the library. Optimizing compilation time by 
identifying the less encompassing header files falls in this stage.

I certainly appreciated this approach when first learnig the function 
library on VC6(which required the compatible approach at that time). Later 
to improve compile times I switched from the encompassing function.hpp to 
the specific funttion0.hpp ... function3.hpp.

Jeff Flinn