On 11/25/2009 08:28 AM, Christian Schladetsch wrote:
My base point is about complexity. Boost is complex, and it has some complex inter-dependencies. A lot of those are around the parser and lexer (spirit etc).
There are some boost libraries like boost::pool which are basically unsupported.
Lastly, there are some boost libraries that use a large set of other boost libraries and hence are fragile to external changes. Boost::container is one of these.
Now, to my comment about "+1 to make it harder to add a boost library". I stand by it, even as I agree that there should be more C++ libraries.
But, there should not be more boost libraries. If anything, there should be less boost libraries. Every one added, adds non-linearly to the overall complexity of boost.
I agree to all of this. We have talked quite a bit about boost's monolithic nature and the technical complexities this incurs. But I think the issues run deeper. If we would stop thinking of boost as one entity, it would be easier to see how different libraries (now 'boost components') are in different shape as far as maintenance is concerned. Some are well supported, widely used, or still being developed. Others were dropped into boost and never touched again. (Some just work and don't need any fixups, others less so, but the author(s) disappeared, and now the library has become a legacy, for the rest of boost.) In short: There is a great variability in technical and non-technical aspects of boost components, which IMO suggest that running them as individual projects would be beneficial to everybody. I believe this could all be done within the Boost.org umbrella, but with more autonomy to sub-projects. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...