[boost] library dependencies and boost modularization [ was Boost and Exceptions]

Subject: [boost] library dependencies and boost modularization [ was Boost and Exceptions]
From: Robert Ramey (ramey_at_[hidden])
Date: 2012-06-25 15:23:46

Boost has now close to 100 libraries.  In addition there are hundreds of 
smaller but necessary facilities which aren't technically libraries but they 
add a lot to the "surface area" that one's brain has to be familiar with to 
take best advantage of boost facilities.  There is also a lot of 
interconnectedness which makes it an even larger task.  This wasn't a big 
deal when boost was 15 libraries - but now it's different.  I would like to 
propose a classification of boost libraries and guidelines for future 
libraries.

a) Layering of libraries
===============

0) C++ standard library
1) "boost core" libaries
2) "boost utility" libraries
3) "boost user" libraries

b) Guidelines
=========
1) a library in a given layer shall include code from libraries in a higher 
layer
2) boost core libraries are in namespace "boost"
3) boost user libraries are in the name space boost::<name of user library>
4) there is a special user library named "utility" for small libraries which 
are
widely used.
5) boost header directory structures should match namespace structure.
example, a library named boost.range should have all it's code in namespace 
boost::range
and in the directory boost/range.
6) exception to 5) above, a user library might have a "convenience header" 
in directory "boost" which
includes all the header directories of that user library.

c) Rationale
========
1) it diminishes the possibility of namespace conflicts as boost/C++ grows
2) it diminishes the possibility of importing a lot more code and depencies 
than one expected.
3) a library can control its depencies.  Often a library will rely only on 
"boost core".  This means that
users of the library can know that code is dependent only on that library.
4) It more easily supports the concept of "boost modularization" where by 
deployment of a subset of boost libraries is can be supported.

It's often mentioned how other languages like java, C#, perl have HUGE 
number of libraries in comparison to C++. I believe these languages have 
reached their peak and are in fact in decline somwhat. It is possible that 
this huge number of libraries make them less attractive rather than more? 
Perhaps a little more formal structure applied to our work might be agood 
thing.

Robert Ramey