stl algorithms and collections in workplace?
Hello, I am currently learning pieces of the stl, but when I watch videos about coding interviews etc the person always say that you cant use the stl algorithms or the collections in the interviews, and you should know how to code these things from scratch. So I am wondering how that goes for people working in a c++ job. If you are a c++ programmer for work, do you, or are you allowed to use these collections and the algorithms in your code? I dont understand why it would exist if you couldnt, but reading and watching people go on about interview etc, it really sounds like it is not allowed
It's absolutely allowed. Matter of fact, it's a major ding if a STL container is appropriate and you don't use it. I would send back a programmer in a code review to rewrite his code. The STL is tested and trusted. Someone who thinks they can improve on the STL by writing it themselves introduces a major testing headache.
The reason C++ candidates are asked to write an STL routine or container in an interview is to judge their understanding on the logic behind lists, vectors, maps, etc. If you have trouble writing something, then your general understanding of C++ and the ability to solve problems is probably weak.
The reason C++ candidates are asked to write an STL routine or container in an interview is to judge their understanding on the logic behind lists, vectors, maps, etc. If you have trouble writing something, then your general understanding of C++ and the ability to solve problems is probably weak.
Thanks abstractionAnon, that was a very helpful answer. And i guess it does make sense for the interviewer to want to know that you actually understand everything. I will continue learning the stl.
you never know what you may run into. You could get hired to work in C, for example.
Learn the STL. Also learn the basics of data structures and algorithms if you can, because those are useful in other languages, many of which have nothing like the STL. (there are high quality 3rd part libraries, of course).
Learn the STL. Also learn the basics of data structures and algorithms if you can, because those are useful in other languages, many of which have nothing like the STL. (there are high quality 3rd part libraries, of course).
You should know about data structures in general and the circumstances when one type is preferable over another. Also common method(s) for their implementation.
With C++, for classes know about copy/move constructors, copy/move assignment and destructor and the 'swap' idiom for implementation.
Unless you're expressly told not to, use STL containers and algorithms when appropriate.
Always know whether you're going for a C or C++ interview! C isn't just the 'C' part of C++ but it's own language and you do some things differently in C to C++ which you need to know if you're doing a C interview.
In the real world, you're probably expected to know about and use the STL unless it's not appropriate (and reason given!) - eg for some embedded programs.
Also keep up-to-date with the standards. C++20 is the current standard. You may well be asked about something say around the range-for statement and expected to know that in C++20 this can also have an optional initialiser part.
With C++, for classes know about copy/move constructors, copy/move assignment and destructor and the 'swap' idiom for implementation.
Unless you're expressly told not to, use STL containers and algorithms when appropriate.
Always know whether you're going for a C or C++ interview! C isn't just the 'C' part of C++ but it's own language and you do some things differently in C to C++ which you need to know if you're doing a C interview.
In the real world, you're probably expected to know about and use the STL unless it's not appropriate (and reason given!) - eg for some embedded programs.
Also keep up-to-date with the standards. C++20 is the current standard. You may well be asked about something say around the range-for statement and expected to know that in C++20 this can also have an optional initialiser part.
FYI, the C++ Standard Library is NOT the STL. The Standard Template Library.
Portions of the C++ stdlib, or stdlibc++, were derived from the STL, but the two are now different things. Just as more than a few features of the C++ stdlib were derived from Boost, yet what was implemented has some differences.
https://stackoverflow.com/questions/5205491/whats-the-difference-between-stl-and-c-standard-library
The author of this article really doesn't like CPlusPlus:
http://kera.name/articles/2010/08/it-is-not-called-the-stl-mmkay/
Now, if people still want to refer to the C++ stdlib (stdlibc++) as the STL I won't really complain. Much. :Þ
Portions of the C++ stdlib, or stdlibc++, were derived from the STL, but the two are now different things. Just as more than a few features of the C++ stdlib were derived from Boost, yet what was implemented has some differences.
https://stackoverflow.com/questions/5205491/whats-the-difference-between-stl-and-c-standard-library
The author of this article really doesn't like CPlusPlus:
http://kera.name/articles/2010/08/it-is-not-called-the-stl-mmkay/
Now, if people still want to refer to the C++ stdlib (stdlibc++) as the STL I won't really complain. Much. :Þ
You're right of course, and the history is interesting, but IMO correcting people is a lost cause. The term "STL" is used by committee members.
Consider the paper titled A Concept Design for the STL with Stroustrup & Sutton as first authors
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3351.pdf
Or, try a google search for
site:wg21.link/ "STL"
Consider the paper titled A Concept Design for the STL with Stroustrup & Sutton as first authors
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3351.pdf
Or, try a google search for
site:wg21.link/ "STL"
Every reference I can find do say the standard itself doesn't use the STL term, even if committee members do informally use it.
I really wasn't trying to correct, per se. Merely pointing out a mistake long repeated is still a mistake.
Same with photo-copying documents still has a lot of people even now talking about "xeroing documents." Inertia will win the argument virtually every time.
The main thrust for my initial comment was to point out the disgust a C++ blogger has for CPlusPlus, even though the comments were made over a decade ago. A lot has changed since then.
Back onto the opening topic....
The history of STL vs. stdlibc++ is a good bit of trivia for a possible interview. If an opening for casually mentioning it occurs.
If a company makes it clear they won't allow using the stdlibc++ to its fullest, requiring "roll your own" 'solutions' when C++ already has time tested ones, that is a company I wouldn't want to work for.
I really wasn't trying to correct, per se. Merely pointing out a mistake long repeated is still a mistake.
Same with photo-copying documents still has a lot of people even now talking about "xeroing documents." Inertia will win the argument virtually every time.
The main thrust for my initial comment was to point out the disgust a C++ blogger has for CPlusPlus, even though the comments were made over a decade ago. A lot has changed since then.
Back onto the opening topic....
The history of STL vs. stdlibc++ is a good bit of trivia for a possible interview. If an opening for casually mentioning it occurs.
If a company makes it clear they won't allow using the stdlibc++ to its fullest, requiring "roll your own" 'solutions' when C++ already has time tested ones, that is a company I wouldn't want to work for.
Topic archived. No new replies allowed.