Over at the Manageability blog there's an interesting entry titled Manageability - Google's Coding Culture and C addressing the lack of uniformity in C++.
There's a few points I'd like to discuss in that regard.
*update*: I also posted a rather lengthy comment to the entry linked above...
One of the main things separating C++ from many other languages, whether it is Java with a large "standard" body of code, or Perl with CPAN etc., is the method of disseminating new code.
In the C++ world, the rule is very much a "bazaar" style of development of libraries - everyone are welcome to the party, and people are hawking their wares at every street corner and sometimes in the middle of the street.
This has it's advantages and disadvantages. Among the disadvantages are the issues mentioned in the entry above: There are many things for which there are no standard ways of doing things. There are often a multitude of libraries doing the "same" thing. There are many coding styles.
However, what that fails to recognise is that the situation is like that to a large extent because that's what people want. Not that people want chaos, but people want different things.
Many of us that dislike Java does so exactly because it forces or at least nudges us into patterns we don't want to follow, and because it constrains us to programming models we don't like.
The multitude of C++ libraries doing the same thing comes from a variety of reasons:
- The standard is limited. It is limited because every standards conformat compiler is expected to offer everything in it. That is, sockets support is considered inappropriate because not all systems can support it, and so on. This is a very different approach to Java.
- People don't know about each others efforts, but decide to keep going when they find out because of different goals/features/needs.
- Different goals, features and needs is a big driver: There are trade offs in anything you do, and where the Java approach is to put one approach into the standard, the C++ approach is that if there is no clear consensus on the way to do things it doesn't belong in the standard.
As it is, that leaves C++ with a very powerful but also very limited foundation, with the STL (which IS part of the standard), iostreams and the remaining bits and pieces forming a generic base, and above that you are free to pick and choose.
But look aroud at various open source projects, and you will quickly see some sets of "standard" libraries popping up everywhere.
The C++ world is fragmented, but there is extensive reuse.
While it's easy to say C++ would be better off with a larger standard library, I think that is a two edged sword - many of the people using C and C++ do so because they only "pay for what they use": You don't get a whole lot of stuff with a basic setup that may not be appropriate for your system.
A lot of these people would not use C++ if it grew into the huge standard that Java has become, because it would no longer fit what they are looking for.
The very strength of the C/C++ legacy is the huge amount of code that is out there in forms that are reasonably easily reusable - it just isn't as neatly packages as some for some other languages.
Reuse in C/C++ is just a whole lot more focused around finding code that works for you (has the right space/time trade-off's etc.) and is under the right license.
Part of this is also a result of the pure age of the C/C++ community - a lot of code back to the 80's, and code with roots further back, is still not only in use but also being reused in new systems.
(One classic example is wildmat.c written by Rich Salz in 1986 and still being reused mostly unchanged in new code these days)