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

I was w开发者_如何学编程ondering how often people actually use much of the standard c++ library, particularly the stuff in the <algorithm> and <numeric> headers. The text books seem to recommend them, but I haven't seen any of them used at all in various projects I've sifted through (coincidence?) and personally it seems easier to just write appropriate simple algorithms myself each time rather than memorize or consult a reference to these headers each time. Am just being lazy or stubborn? Is there actually performance gains etc when using these libraries?

Thanks,

R

It's possible you're being lazy or stubborn. Personally, I use them all the time in production code.

I don't do this to be fancy, and I don't do this because I like writing "space-age code." Rather, I do this because I am a paranoid programmer, and I know that production environments are hostile places that will mutilate code and reduce my programs to smoking piles of worthless bytes, if given a chance.

I do this because I live by the motto, "The best code, is the code you never write." It takes time to learn how to use the STL & Std Lib effectively, but once you do you'll find that it can be used so that what now is 1000 lines of code becomes perhaps 100. Those 100 might take as long to write as the original 1000, but there are fewer failure points. The code can be more robust, if you stand on the shoulders of others.

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

Just about everyone using C++ uses the STL, especially <algorithm>. You really don't want to have to write sorting functions yourself; you'll just end up making mistakes, and in the end the performance will probably be worse.

Whether or not there are performance gains obviously depends on what you are comparing to. In general though, using the STL algorithms is typically faster than writing your own functions -- unless you happen to have a particular trick that applies to your use case that could give you the edge. If you just write a standard quicksort yourself, it will probably be slower than the one in the STL.

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.

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!

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)

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.