3 ms·
Sure, I was just giving my opinion. Take it for what it's worth... :-) But if you'll indulge me for a moment, consider how you'd convert a string to uppercase
by vilya 12y ago
Sure, I was just giving my opinion. Take it for what it's worth... :-)
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 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.
- humanrebar 12y agoIt should be (eliding namespaces): 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.
- vilya 12y agoThanks, but I was just looking for a better way to convert a string to upper case, not an arbitrary collection of chars. I've never yet needed to upper-case anything other than a string and unless I get the urge to write a text editor (unlikely!) I doubt I ever will. 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?
- stinos 12y agoa better way to convert a string to upper case, not an arbitrary collection of chars 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.
- vilya 12y agoI think that sums up nicely why I don't particularly like the STL: it's that mindset. It's all well and good having a generic operation over an arbitrary collection of anything, but sometimes you just want to get stuff done. All that generality adds distance between your code and the problem you're trying to solve with it. It's obfuscation. Edit: I hope that doesn't sound too combative - I'm just trying to explain myself, not saying that you're wrong.
- stinos 12y agoI'll let you draw your own conclusions. 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.
- vilya 12y agoI admit I'm guilty of cherry picking my examples. :-) I wouldn't say it's bloat though, if it's something that most people end up having to re-implement. For what it's worth, I have my own little library of STL helpers too...