The line that stood out to me was the quote from Stepanov, about C++ being the only language in which it was possible to implement the STL. To most people, that would have been a hint that perhaps the design of the STL was flawed...
I think the STL may have been the worst thing to have happened to C++. It could have been so much nicer if something like Qt (the core part) was adopted instead.
Which bit about Qt were you hoping was part of the STL? I think the design goals of the STL was to make it portable, something Qt is not, despite being multi-platform. We mustn't forget that C++ is used on very low level devices.
If Qt is anything like wxWidgets, wxWidgets reuses the STL for its container types, basically providing a thin wrapper over the STL (or it can do with a build switch).
I myself find the STL very useful, so I am genuinely interested in which bits of the STL you wish were more Qt-like? Do you mean the GUI bits of it or something?
How do you define portable? If you mean the same code compiling and running out-of-the-box on Windows, Mac and Linux then actually my experience with Qt has been very positive in that regard. Those are the only platforms I develop for right now, so I can't ocmment about portability to e.g. iOS or Android (although I believe Qt ports are available for them).
Qt doesn't reuse the STL container types, it provides its own - which I find much more pleasant to work with than their STL counterparts. The STL puts a lot of effort into providing types of flexibility that are irrelevant or useless to me (e.g. allocators) and doesn't provide lots of simple things that I need every day (e.g. an indexOf method for std::vector, a contains method for std::set, or a toUpper/toLower method for std::string).
Ah I see what you mean. I should dig out Qt again really - I haven't used it for years. I have managed to make do with wxWidgets.
Regarding iOS and Android, the attempts at getting C++ on them (particularly Android) are brave but I think for normal apps (not OpenGL or games), developers are probably better using Java.
Like you, I too am writing for the Big 3 normal desktop OSes, with sporadic Android development and iOS tinkerings, necessitating learning new languages.
"Portable" for C++ means I can run it, for example, on the computer that controls a car's anti-lock brakes. And, in fact, I can use C++ and the STL on such a computer, even if it has no OS.
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) looks like this:
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.
Thanks, 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?
a 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.
I 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.
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.
I 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...
I think the STL may have been the worst thing to have happened to C++. It could have been so much nicer if something like Qt (the core part) was adopted instead.