Niall Douglas wrote:
Most libraries presented for standardisation ARE battle hardened libraries. However they were typically written for preceding C++ standards, and in outdated idioms and design patterns, and require modernisation which can involve substantial refactoring.
Maybe not most. It's no longer easy to give a single reason as to why the committee's output is what it is, as the submissions are of varying quality, philosophy, and origin; there's no single universal problem with them. Some of them come from big companies, are indeed totally battle-hardened, but reflect the monoculture of the company which does not correspond very well to the environment in which the median C++ programmer operates. Others are useful facilities in use in more than one relatively smaller company, battle-hardened, but pragmatic, prioritizing problem-solving over design elegance or avoidance of undefined behavior. And then we still have the "direct to video" libraries that haven't actually seen much practical use. In theory the committee should be that great place where people who value design elegance and lack of undefined behavior and specification imprecision meet the people who need to get their work done yesterday and the people who have a lot of experience with large scale deployment, but in a company culture that's not representative of the C++ community as a whole, and the end result is supposed to be the best of these worlds. But it isn't.