The reason trim() isn't in the standard library is that when the last standard was made, they had to strike a balance between formalizing current behavior (adding nothing new, just stabilizing what already existed), and adding new functionality. In general, they preferred not to add a feature unless it either 1) would be impossible otherwise, or 2) there were significant drawbacks to using third-party libraries instead. Making too many changes would
- break compatibility with existing code (which may have defined its own trim()
- Add more work for compiler writers (who already had a huge amount of work ahead of them)
- Make the language more complex to learn and use.
With trim(), there are no major interoperability issues. As long as your third-party trim() implementation takes a string and returns a string, we don't really care where it's defined. So it's not really necessary In the standard library. It can be easily supplied by other libraries.
By contrast, something like the string class or vector, are classes that the standard library must supply, because if you use a custom string class, only string operations from that library will work. With a standard library string, third-party libraries can target this common string definition, and everyone wins.
When the last standard came out, Herb Sutter wrote a post describing this very well here
Of course, it would be nice to have a trim() function, but they had bigger fish to fry. They had to standardize all the basics first. I don't think C++0x will add a trim function, but it will add a lot of other convenience utilities that back in '98 were considered "unnecessary" or too specialized.