I think opinions on that greatly vary. I for one find a majority of what is in STL very well-designed and very usable.
I think opinions on that greatly vary. I for one find a majority of what is in STL very well-designed and very usable.
But if you'll indulge me for a moment, consider how you'd convert a string to uppercase using the STL vs using Qt. The STL code (taken from http://en.cppreference.com/w/cpp/algorithm/transform) looks like this:
std::string tmp = s;
std::transform(tmp.begin(), tmp.end(), tmp.begin(), std::ptr_fun<int, int>(std::toupper));
return tmp;
Note the use of a temporary variable, because std::transform does a destructive update.The equivalent Qt code looks like:
return s.toUpper();
I'll let you draw your own conclusions.By the way if there's a simpler way to do that using the STL, I'd love to hear about it.
transform(begin(tmp), end(tmp), begin(tmp), [] (char c) { return toupper(c); });
...the only noisy parts are the calls to begin() and end(). On the other hand, it will work for any collection type with good iterators (vectors, lists, strings, deques, ropes, etc.).It is also trivial to write a mylib::transform_in_place() that cuts down on the noise with a one-line function.
And yes it's trivial to wrap this in a function, but in my opinion it really shouldn't be necessary. It's such a simple and common-place operation, why isn't it in the standard library?
just a sidenote - this is exactly the opposite of the way of thinking the STL promotes: in STL terms, you do want a generic operation on an arbitrary collection of anything that happens be compatible with toupper. Shouldn't even be a char, let the compiler figure that out. And as it turns out, std::string happens to fit in nicely.
Edit: I hope that doesn't sound too combative - I'm just trying to explain myself, not saying that you're wrong.
from this single example I could say 'STL isn't bloated and contains just the things necessary while leaving plenty of room for extending. That is just the way it was designed' (And extending it is something I do regularly, resulting in a header-only library with tons of small helper functions containing something like noted in the other comments 'transform_inplace' and 'to_upper' which is implemented using the former. Also the resusability of most of these shouldn't be underestimated.) - but for this case I sort of agree that toUpper could have been a member of string becasue it's pretty basic and that if you work with strings regularly QString is nicer from the start as you don't need extra functions. But of course that opens the road to others saying that if toUpper is there, then why shouldn't x and y and z be there.. Never-ending :P. Which is also probably why the STL is the way it is.