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

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-08-20 21:45:37

Robert Ramey wrote:
> David Abrahams wrote:
>> Jeff Garland <jeff_at_[hidden]> writes:
>>
>>>> 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.
>>> I think a few years ago I would have agreed with this, but I think
>>> the "size" issues just don't apply that much on modern machines.
>> In general, Jeff, I agree with you, but in this case I have to agree
>> with Robert.  Because of the way the serialization library is
>> constructed, including another archive can really result in the
>> generation of substantial code.  It's not just "size" but actual size.

Sure, but that's optimization.  There's learning how to write a serialization 
program and then there's learning how to writing an optimized serialization 
program.  Here's some code from my new serialization tutorial:

//this is expensive see granular_headers (hyperlink) for details
#include <boost/serialization.hpp>

> Actually, the serialization is an unusual example in this regard
> so maybe its not the best example for discussion.

I expect that this is the reason we don't really have a policy -- because 
there are little nuances for each library.  Turns out date_time doesn't have 
an all-inclusive header either.  My reason was the usual cost of inclusion -- 
why should I include the timezone header if I'm only using the date.  But for 
my standard proposal there is only one header: datetime.

> But using this logic, wouldn't we want to have a header
> stl.hpp which includes all the stl libraries or all the stream
> libraries. Again, where is the line drawn when deciding
> wath to collect.  Regardless of what boost does there
> are always gong to be a lot of headers which don't
> fit in some group.

Or maybe boost.hpp.  Now there's an extreme for you since boost is bigger than 
the standard library.  So I guess there is some limit.

> Finally, there is a big issue for.  If I inherit a piece
> of code and for some reason I need to investigate
> how it works,  I now have to go through a lot
> more code to decide what is relevant.  I don't like
> that.  Smaller programs are better programs,
> and "comprehensive" headers make programs
> bigger while making them look smaller. I
> especially don't like this.

Sure smaller is better, but I don't agree that a comprehensive program makes 
the program bigger.  Sure it makes it harder to narrow down where something 
is, but that's why we have grep.

Well, sounds like it's back on someone like Scott to sit back and weigh all 
the tradeoffs to figure out how this should be.

Jeff