+1 for rational thinking ;) 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. And people are turning away from boost because it is either too hard to configure, or because it is outright broken, or they can't link with it. Perhaps boost needs a practical, staged boost::ex:: or boost::sandbox namespace. I do not think such would really help in the long term, but it may help over the next decade. But we also know that such would probably cause far more troubles than it could solve. Which is sad. In summary; I agree that C++ can use all the libraries it can get. However, adding them willy-nilly to boost causes more problems than it solves. Boost needs to work first, be useful second, but overall must have zero overhead for systems not used. This last point has deep implications. That said; who's for boost::directx structures ;) ? On Wed, Nov 25, 2009 at 3:23 PM, Jeffrey Bosboom <jbosboom@uci.edu> wrote:
OvermindDL1 wrote:
On Tue, Nov 24, 2009 at 10:08 AM, Robert Ramey <ramey@rrsd.com> wrote:
Christian Schladetsch wrote:
+1 for making it harder to add a new library to boost.
There are already too many libraries.
-1 for making it even harder to add a new library to boost.
Boost and C++ doesn't have anywhere near enough libraries.
-1 too.
Other languages are more popular just *because* they have libraries that do everything, we need such things in C++ too, with the speed that C++ provides us. You can never have too many libraries, as long as they are well documented and categorized.
I believe Christian's response may have more to do with Boost's monolithic nature. It isn't currently possible to say "I need shared_ptr and Boost.Unordered and any necessary dependencies" -- the user must install all of Boost, which is daunting if not as difficult as it first seems. This goes against the C++ philosophy of "you only pay for what you use". This problem will only get worse as Boost accumulates more libraries.
I also want more libraries (so here's my -1), and I've used Java largely on the strength of its standard library (especially Swing). In fact, I want them even if it makes Boost large and unwieldy. But I think making Boost modular would do a great deal to assuage the fears of those who would rather be more selective.
--Jeffrey Bosboom
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost