C++ standard library - when should I use it and when shouldn't I?

Question

I was wondering how often people actually use much of the standard c++ library, particularly the stuff in the and

Answer 1

What projects are you sifting through? Are these professional projects or something random?

One of the things I've noticed is that a lot of legacy type code (I worked on a code base that pre-dated C++98) avoids the C++ standard library because of performance worries of the implementations at that time, or just because the libraries didn't exist at the time. Of course, some environments (embedded systems, games, defense, etc.) might have other requirements that preclude the use of C++ standard library in many cases, like a coworker of mine worked in defense and couldn't use the STL stuff at all, due to customer requirements not to use it.

---

In general, if there's a choice of using the standard library vs. inventing your own wheel vs. using someone else's library, then in general I'd pick the first choice first. The code gets tested by thousands, hundreds of thousands of people, subject to more testing and scrutiny than most things you'd implement yourself.

A third party library (let's pick an example like Boost) if it has things that you require. A library like Boost is well respected, has a reputation of being exceptional quality code, and is used/tested/maintained by many, many people.

The final choice is invention of your own code, I think this really falls into a few categories:

1. Self-learning - writing code just to learn, but this means there's no expectation you're shipping it as production code.
2. You have specific requirements that are not met by anything that can be acquired, or must be adapted from something else. There is a lot of this, you might need to write your own algorithms specific to whatever you're doing.

But remember that if you implement your own, think about whether or not the standard library already has it, otherwise you could run into a maintenance problem if something gets very ingrained in your code. My last company implemented their own container classes, and of course the code base grew to millions of lines of code (across tons of products) and everyone used these internally-developed container classes. Bugs in those containers cost significant amounts of developer time and money to fix because there were just fundamental bugs in the classes (linked lists, vectors, associative arrays, nothing that standard C++ doesn't provide). While new code used the standard library, the company just didn't have the resources to start refactoring all the old code.

If you can offload that worry to other developers who are experienced with such code, AND get the testing of thousands of people? That's a big win!

Answer 2

A lot of existing C++ projects don't use the standard library because they were started before you could rely on the standard library being available -- I'm talking code that's got a release history going back ten to fifteen years, here. I have also heard that some modern environments (for instance Android) still don't give you a complete C++ runtime, so if you need to be portable to those environments you still can't use it.

Another reason is that some extremely large programs (I have personal experience with the guts of Firefox, and I have heard that this is also true of OpenOffice) are built with exception support disabled, because it is fervently believed to cause performance problems (this may actually be true for MSVC++'s ABI and/or for programs of ludicrous size, such as the above two) -- but you can't use most of the C++ runtime if you do that.

It's frustrating, but that's the industry for ya.

Answer 3

it's not a direct answer to your question, sorry. just a cry. I've read previous answers and decided to add my two cents. particularly about <algorithm> and <numeric>

What is the main C++ paradigm? Of course, OOP, tree whales etc. every C++ interview has a question about this. But I've never has been asked about functional programming. <algorithm> and <numeric> is that functional part IMHO. To use them actively you need to think a bit different, to architecture your program making a place for their usage. Typical reasoning: why to use any sorting if I can use a std::map or std::set? isn't this a devil of premature optimization? final result will be accepted in vast majority of cases, just buy better hardware. tricky implementation usually is much simpler to code than to learn that 100+ algorithms and what is more important - to understand how and when to use them. it's complete rocket science.

consider statistically average software company with 100 C++ programmers. there will be about 10 good specialists. have they any chance to spread good style there? yeah, if they are nature born leaders and work long enough in the company. they need to constantly fight with prejudices like "exceptions are very bad idea", "virtual methods are slow" and "it's just an int, why it's not thread-safe?". and their code cannot be understood by others because of intensive <algorithm> and <numeric> usage

Answer 4

You should use stl as much as possible.
It has been written by pretty sophisticated programmers and it is very unlikely that you can write a more optimized version of any of stl stuff.
Do not re-invent the wheel

Answer 5

When should you use the C++ Standard library? When it provides a function you need.

It's known that some things like for_each aren't supported terribly well by the language- that's what lambdas are for in C++0x.

Answer 6

You should use standard libraries in all languages, not only C++. That's pretty much a basic rule in programming these days.

Your impression is wrong; any good project will benefit from building upon known, tested, libraries. The amount of time and man-hours there's behind these libraries is just something that an individual can't achieve alone.

Lots of people have suffered, sweated, sweared and fought over the years in order to get those libraries properly running. The combined effort of writing, debugging and arguing over each particular implementation detail can probably be measured in decades. On top of that, uncountable machine cycles have been spent running test after test just to make sure that everything worked according to the specs.

Yet pretty much every programmer has now and then that thought. You know the one.

"I can do better in one evening".

I know. I understand. I have been there.

Go ahead. It's a good experience.

A long, sinuous path will extend before you. On the initial part of your journey, you will find little implementation pebbles here and there. Some of them will slip into your shoes, most won't.

Later on the path will stop being so straight; it'll start branching out. Soon you will find yourself trying lots of different paths and backtracking frequently. And occasionally you will encounter a profound chasms of algorithmic uncertainty or a tiresome refactoring mountain.

All that while you watch your peers speeding on the clean, straight, maintained Standard Libraries Highway.

Gradually you will realize that refusing to use standard libraries and isn't just lazy or stubborn, but foolish. And terribly inefficient!

In conclusion - if you want to reach somewhere, no matter how fast you can run, driving a car will get you there faster and more safely (unless you are going to the store downstairs for some milk)