David Abrahams wrote:
I agree with that; no question about it. I think a few more degrees of classification than you've outlined could be useful:
core vs. optional
I hate "optional" but can't think of a better term right now. This is the distinction between, e.g., type traits and serialization
It's hard to draw the line between 'core' and 'optional' IMO. I guess 'core'-libraries would be libraries that are heavily used by other boost-libraries whereas 'optional' libraries are leafs in the library-dependency graph. Therefore I think it just is important to have a clearly documented library-dependency-graph. This would allow people using one specific boost library to know what other boost-libraries they also need. This will also allow them to know if the library they want to use relies on 'still experimental' boost-libraries etc. And finally library-authors should be cautious about adding another dependency in their library. This way people can evaluate in advance the 'stability' of the boost-library they are interested in. toon