I was interviewing IBM and they where asking what is STL, so if I know what is function , variable , pointers , template class , classes .... etc in C++ , why is it so important to learn the STL library , and how good will I need to know the STL library ?
Why learn STL library
I presume you mean "STL" in the sense of the C++ standard library and not the actual STL that eventually influenced/became the standard C++ library.
It's important to know the standard library for your language, and that's just as true with C++ as with anything else. The standard library provides significant useful functionality, defines significant useful paradigms, and is generally a very powerful tool. Without the standard library of a language, there's often very little you can usefully do.
It's important to understand the standard library even if you intend to "reinvent" aspects of it, such as its allocator mechanism, its smart pointer library, or its container types. If you don't understand it, at least to some degree, you can very easily end up with inferior home-grown alternatives. It's also important to understand from the perspective of being able to comprehend other code written in the language.
The STL was a ground-breaking design at the time of its release and understanding it will help you understand how to use data-structures more effectively to solve problems and help teach you how to do it in a way that is systematic and less prone to bugs.
e.g. Iteration over containers is a key concept.
Iterators enclosing the contents are always defined as [begin, end) (meaning what begin references is in the container but what end references is not in the container).
I believe it was Alexander Stepanov (key designer for the STL) who said that the syntax of C++ templates was the worst thing he has ever had to code with but it was the only tool available that allowed him to codify his ideas into a usable implementation. 20+ years later and that hasn't really changed.
In modern context "the STL" refers to the container templates (and supporting code) in the C++ standard library.
I presume you mean "STL" in the sense of the C++ standard library and not the actual STL that eventually influenced/became the standard C++ library.
Seeing that even C++ standard committee members refers to (a specific subset of) the C++ standard library as "STL", that historical footnote really no longer needs to be mentioned, IMO.
(the specific subset is the algorithm-iterator-container chunk, which I'd guess is 70% or more of the overall standard library)
Should people avoid books like these because 'the STL is no longer used'? (edit: okay, bad example, seeing as that book is from 2001. But I hear standard committee members using the term STL in modern conference talks as well)
I think denying that usage brings more confusion than permitting it, though obviously many disagree. Especially 20 years later when a beginner isn't likely to accidentally be using the SGI-STL, and anyone using something like STLport is experienced enough to already know the distinction, I think this programmer-war can be laid to rest.
The C++ Standard Library is not the original STL. But a large part of the C++ Standard Library has also adopted/co-opted (through general usage) that name.
If I know what is function , variable , pointers , template class , classes .... etc in C++ , why is it so important to learn the STL library , and how good will I need to know the STL library ?
You need to learn how to use it, but you don't need to have perfect memory for it. It should be the first tool you reach for, rather than re-inventing the wheel, because the more you understand it, the more you can reinvent the wheel better if you need to, and the better you can communicate with other developers who also understand it.
Shared knowledge is great for communication. I can say "linked list" or "unordered map" and everyone else knows what I mean. They can mentally translate it into their own context (like "unordered map" might be a "hash dictionary" in whatever C++ library they're using for their project, for example).
It's worth learning because it'll stretch your mind; it's worth learning so you can communicate with other developers better; it's worth learning because they are great general-purpose tools that you can replace piecemeal when you require something more tailor-made.
At the very least you should learn it because other people use it and you want to be able to understand what the hell is going on when you see their code.
I'm more interested to know why you think that knowing about a small fraction of language features means that you can't benefit from learning other things as well.
Seeing that even C++ standard committee members refers to (a specific subset of) the C++ standard library as "STL", that historical footnote really no longer needs to be mentioned, IMO.
(the specific subset is the algorithm-iterator-container chunk, which I'd guess is 70% or more of the overall standard library)
Should people avoid books like these because 'the STL is no longer used'? (edit: okay, bad example, seeing as that book is from 2001. But I hear standard committee members using the term STL in modern conference talks as well)
I think denying that usage brings more confusion than permitting it, though obviously many disagree. Especially 20 years later when a beginner isn't likely to accidentally be using the SGI-STL, and anyone using something like STLport is experienced enough to already know the distinction, I think this programmer-war can be laid to rest.
The C++ Standard Library is not the original STL. But a large part of the C++ Standard Library has also adopted/co-opted (through general usage) that name.
I don't really disagree, but given the brevity of the original post, the relative lack of context, and the fact that as you imply there are still plenty of people out there who stubbornly (almost zealously) insist that one should absolutely never use the term "STL" unless one means Stepanov's library only, I wanted to be clear. I wouldn't give the same answer for the original STL as I would for the modern standard library (there's really nothing worth studying in the original STL unless one is a language history buff).
It's important to learn STL stuff since there's useful things in there, like std::sort and std::vector. They are useful because they save time and are implemented well enough for most needs, without bugs.
You should learn it because its The Right Way* to write code in C++ -- You should write std::vector almost every time you want dynamic memory, you should write std::unique_ptr every time you have a pointer who's contents are owned by a single entity, you should be using the standard algorithms wherever you can and not writing raw loops, you should be using std::move, and countless other examples.
I would argue that, without the standard library, it can hardly be said you're writing C++ at all. Yes, just "the syntax" is C++, but that's a bit like saying the collection of English words are English. While technically true in a legalistic sense, a language -- whether computer or human -- is more than its atoms. Its about how the parts fit together, and what patterns have emerged to deal with common situations. Most programmers, especially new or young programmers, without utilizing the standard library, just end up writing C++-flavored nonsense. You can use a library that's not the standard library, such as would likely be instituted by your company or engineering organization, but there better be a good reason for avoiding the standard library, and there better be a rock-solid implementation of its alternative.
* The C++ Standard Library / STL is not perfect, its got some warts and imperfections and accumulated cruft, but by and large its great and there's a lot of good, useful stuff inside. When it offers a solution to your problem, or a bunch of parts that can be wired together to solve your problem, it really ought to be the first thing you reach for. For the general case, I don't believe there's a more performant and battle-hardened library on the planet. Its true that there are those with special needs who might avoid the standard library because they can't use exceptions in their environment, or that they might be able to devise special ways of doing things that are faster than the standard library because they understand their exact use-case better (e.g. which corners they can cut) and so their solution actually has to do less work. Bit its a rare thing that anyone comes up with something that's faster than the standard library functions while also maintaining the same level of general-purpose correctness.
Don't make the mistake of assuming, as most starting game developers do, that the standard library is "too slow" or just plain to be avoided. Don't make the mistake of assuming, as most starting game developers do, that "real (game) programmers" write every line of code they've ever laid eyes on. Don't make the mistake of assuming, as most starting game developers do, that using such a pedestrian library doesn't live up to the game-developers-as-programming-gods myth, and if you do then you'll never be elite. Don't make the mistake of assuming, as most starting game developers do, that you know what needs to be optimized before you've measured it with real tools that you really know how to use.
You should have at least a basic working knowledge of the standard template library (STL) because it's portable, practical, readily available, easy to use, and everyone else is using it unless they have good reason not to. Using not only the containers, but also the algorithms part of the library, can save you a great deal of time and trouble.
It's also important to know the best container to use for a given task. For example, I probably wouldn't recommend a vector to store pointers to a GUI element's children, but I would recommend it for storing game object data.
You should learn it because its The Right Way* to write code in C++ -- You should write std::vector almost every time you want dynamic memory, you should write std::unique_ptr every time you have a pointer who's contents are owned by a single entity, you should be using the standard algorithms wherever you can and not writing raw loops, you should be using std::move, and countless other examples.
I'd put that 'Right Way' quote on hold; much of the STL is full of performance dangers that will set you back one day when you're writing production code.
Here's some stl stuff I'd recommend that you should most definitely avoid:
- std::stringstream: known to have performance implications, also has terrible syntax. use snprintf instead (it has better syntax too)
- std::fstream: same as above. use c-style apis fopen, etc instead
- data structures other than std::vector: this is always kind of a newbie trap. using things like std::map over a vector can have a performance impact due to the count of cache misses you get from using that data structure.
- smart_ptr/weak_ref family: I find these to be syntactic sugar that gets in the way of implementing what you really want. One day, you'll find out that there's an allocation smart_ptr makes that kills performance, so you'll need to make an allocator, which is yet more work. Or you might get a crash from incorrect use of the api.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement