C++11 and third party libraries - big issues

[Bssldr]

I suggest watching the 2nd day keynote (by Herb Sutter, member of the standard's committee) of the ongoing GoingNative 2012 conference. In the last part of his talk he points out that the biggest weakness of C++ is the too small standard library (he compared it to C#/Java that have tens of times bigger standard libraries). According to his words the standard's committee is going to work together with big companies/organizations/library vendors like Boost, Poco, Qt, Adobe, Microsoft, Google, Facebook, etc to deliver more useful consistent libraries during the next few years. He mentioned that what the committee has in mind are: filesystem, networking, serialization, HTTP, HTML/XML/JSON, compression, cryptography, audio/image/video manipulation, database interaction, etc.

This shows that the criticism against a too small standard library is justified, the standard's committee has itself realized that fact. For those who think that C++'s standard library is supposed to be tiny and you are supposed to get your libraries from the outer space, you're wrong. Won't stay that way.

[S_M_A]

Maybe so but that doesn't make the language a bad one. After all, in my opinion both C and C++ have proven that they keep being good enough compared to other languages to earn their place as still being very popular languages.

[Chris_F]

For those who think that C++'s standard library is supposed to be tiny and you are supposed to get your libraries from the outer space, you're wrong.

No, it simply means there is s difference of opinion. As it's been stated many times in this thread, C and C++ have been around decades longer than C# and Java. They still serve their purpose just as well as they always have. Lets see if either C# or Java can stand the test of time half as well.

[superbonzo]

I agree with Chris_F, just consider that the standard committee rarely votes unanimously on key decisions ( see the c++11 concept proposal, for instance ).

as other said, what makes a library or a framework different from the standard library is that the latter should be stable in time. You can abandon a library if it gets out-of-date or if better libraries are developed ( how many libraries have been developed during the years ? how many of them have survived ? ). But this is unacceptable for a standard library.
This does not mean that the STL should be tiny, this just means that in order to be included in the STL a design must reach that level of (supposed) generality and robustness guaranteeing wide adoption both in space and in time.

Now, given that the robustness and stability of a design depends firstly on the stability of its usage scenarios, this automatically implies some delay on the standardization process: for example, in order to design a standard GUI library you need a sufficiently stable UI usage pattern and a well proven UI software design. And we have neither of them: user interfaces are evolving continuously and there is a proliferation of UI libraries, each with its own design spirit, each with its own pros and cons and usage base. At present, the very idea of UI is not sufficiently mature to be standardized effectively, IMHO.

And in any case, an hypothetical standardized GUI library would not resemble existing "omnipotent" GUI frameworks, it would probably present an abstraction of a GUI system leaving to the implementation or user/OS provided components things like user input systems, graphical elements, etc ... in the same way as STL streams provide an abstraction of buffered character based data exchange.

For example, consider the recently standardized regex library: its design is totally indipendent on regex syntax; the implementation guarantees support for some selected grammars ( like the ecmascript regex standard ), but it would nicely support any new grammar you like, the only requirement being that a "regular expression" should be able to split and match char patterns in a consistent way. Do you see the difference ?
My string processing code relying just on the standard regex interface will work effortlessly with that new grammar as well ... but this is possible only thanks to the stability of the library interface, that is guaranteed to remain immutable or backward compatible, or at least at a guarantee level given by the top-experts at the time of standardization.

Of course, if you are not capable of exploiting the value of stl ( for example, by mixing code using iostream and c style io, mixing code processing regex result exrtaction with regex expressions manipulation, writing code not respecting standard guarantees, etc ... ) then all this will appear to you as a pointless waste of time ...