STL vector, this is General programming.
STL vector, this is General programming.
STL vector sucks It's much better than STL string (compared to QString), but sucks anyway...
I totally agree. STL is ugly like MFC
It's not that it's "ugly". According to me it has two problems - it lacks functionality and it has many different implementations with different quality, complexity, etc. And it tends to be heavy sometimes... Qt classes are much more lightweight.
if compare Qt and STL, then using Qt classes more convenient and as you say, more light.
When compared with a C style "array", even the worst STL is a blessing.
But I agree that Qt classes often offer better usability and more useful methods.
(But, as there are times when one can use C++ and STL but not introduce the dependency to Qt, I use STL, too.)
What does, when used correctly?
Obviously, anything you use as a layer between you and the cpu has a chance of introducing a bug and thus a crash: By 'worst' I did not mean buggy. :-)
But abstractions like (std:: or Q)vector, map etc just like classes you build upon them help because they allow you to work and think are nearer to the real world than the datastructures C has to offer.
(I realize that C++ has basically the same and this is rather an issue of good libraries. Only it's more easy and thus likely too use string, array etc 'classes' in C++ than C.)
Obviously naked C arrays have there place, too.
(Also in most applications I work with the trouble of checking "does the input fit here", "is this stack based array big enough" etc just is a pain. I see too many places where crashes would occur if the input was only too long. Sure, one can program to prevent that (you can in assembler, too...). But if people don't do it, not much of a help that they could have done it.
Therefore, in my opinion it is good if a language - or library - allows one not to have to deal with the dangerous world of memory management. (I say allow because now and then you need/want to have to deal with it. But not always and imho definitely not for string operations.)
And yes, one can write pretty code in C (one can in any language). But having to work with a large C (and partly C++) code base on a daily basis: believe me when I tell you: you can write very ugly code in it, too.
(The lack of a proper string entity leads to numerous hard to read (often incorrect) for-loops, working on char*, incrementing pointers etc that is way harder to read, debug etc than a e.g. nice simplifyWhitespace(), boost::strip() or whatever. Once again, I agree that one could use (or create) a string-struct in C, and write nice reusable and well named functions for it. But could is theory, and ugly code is my reality ;-) )
To sum up: it is not a problem with C, or C++, or naked C style arrays. It is a problem of the people using it...
As mentioned, VC6 implementation of STL does.
That's completely another case but then we come back to a question "why use STL if you have Qt?". The latter provides an even more abstract and complete interface with better speed, memory footprint and capabilities.But abstractions like (std:: or Q)vector, map etc just like classes you build upon them help because they allow you to work and think are nearer to the real world than the datastructures C has to offer.
(I realize that C++ has basically the same and this is rather an issue of good libraries. Only it's more easy and thus likely too use string, array etc 'classes' in C++ than C.)
Unfortunately for some time std::string is not a "proper string entity" as it is based on char* as well and in times of globalization this is unacceptable.(The lack of a proper string entity (...)
Bookmarks