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

Robert Ramey wrote:

David Abrahams wrote:

...

Jeff Garland 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

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