Re: [Boost-users] Why is there so much co-dependency in Boost? Is there anything to be done about it?

Subject: Re: [Boost-users] Why is there so much co-dependency in Boost? Is there anything to be done about it?
From: Robert Ramey (ramey_at_[hidden])
Date: 2012-09-04 14:29:56

steve_at_[hidden] wrote:
> Greetings,
> As a veteran C++ programmer, I've been an admirer of the Boost
> library for many years.  I've used it at a number of companies I've
> worked for, especially the SmartPtr library.
>
> I've done a study and written some tools, to determine just how many
> Boost header files must be included to use some of the Boost modules.
> The numbers are staggering:

...

This is a legitimate concern which IMO has not been taken seriously by the 
Boost community.
To some extent it's unavoidable since it's more efficcient to have one 
"best" solution
imported everywhere rather than replecating code.

But it doesn't have to be as bad as it currently is.  And it's only getting 
worse as more libraries
get added to Boost.

Here's what  I suggest for boost users such as yourself:

a) don't use "convenience headers" which suck in all the headers in a 
library
rather than just the one's used.  It seems tedious because one has to read
more carefully to know which headers to use but it saves huge amounts of
build time and diminishes "dependency surprises" which can cost a lot of
time to track down.

b) a few libraries "infect" your code with "spreading" depencies.  Use your
analysis to detect these libraries and complain about them.  I have done
this in the past to no effect.  It did make me feel I was doing something
though.  If you can't get library authors to see this, you'll just have to 
avoid
that library or fork your own copy.

c) In your own code, use pre-compiled  headers.  This speeds up re-builds.
It DOES force you to spend some time looking at how you've
divided up your own code but this time is a good investment.

Here's what I suggest library author's do:

a) Take this gentlement's complaint seriously.
b) Consider eliminating "convenience" headers.
c) When writing documentation avoid depence on "convenience headers".
This seems like it adds some work - less conveniece - but hels addressing
this man's problem.

Here's what Boost can do. Something like:

a) Formalize the comcept of boost library "levels"
i) core  - e.g. config, auto-link, BOOST_NONCOPIABLE, ...
ii) utility - e.g. scoped_ptr, ...
iii) application support - e.g serialization

Every boost component would depend only on components at the same or lower 
level.
The assignment of library level would be part of the review process.

The motivation here is to support the future growth of Boost and C++ 
libraries in general.
I see this as the fundamental requirement behind any efforts to achive
"Boost Modularization"

Robert Ramey