Is The Standard Library Really That Useful?
As I find myself becoming more and more seasoned, I find that I use the standard library much less and less. At first, I made quite an effort to use "modern C++" (at this time this was C++11).
Now, I find that using the standard library is quite distasteful for the most part. It's pretty bloated, takes forever to compile, and the code itself is completely unreadable with literally all major compilers. It's pretty good for hacking out a quick and dirty solution in certain situations, but I as time goes on I typically end up rewriting it in a more C-with-classes fashion.
Don't get me wrong- I'm no C purist. I love C++11 threads, I use vectors and strings in certain areas, auto-for-loops (is that what they're called? lol), etc, but I find that specialized, POD, data structures typically beat the "idiomatic" equivalent both in speed, readability, and mantainability.
I do, however, work more with lower-level projects such as games, emulators, operating systems, etc. Might be the reason why I find code written in this manner easier to digest.
Am I the only one who feels like this?
Thank you, I look forward to your responses.
Now, I find that using the standard library is quite distasteful for the most part. It's pretty bloated, takes forever to compile, and the code itself is completely unreadable with literally all major compilers. It's pretty good for hacking out a quick and dirty solution in certain situations, but I as time goes on I typically end up rewriting it in a more C-with-classes fashion.
Don't get me wrong- I'm no C purist. I love C++11 threads, I use vectors and strings in certain areas, auto-for-loops (is that what they're called? lol), etc, but I find that specialized, POD, data structures typically beat the "idiomatic" equivalent both in speed, readability, and mantainability.
I do, however, work more with lower-level projects such as games, emulators, operating systems, etc. Might be the reason why I find code written in this manner easier to digest.
Am I the only one who feels like this?
Thank you, I look forward to your responses.
Last edited on
Yes, it is very useful. When used appropriately.
Why keep reinventing a flat wheel by writing your own stuff already done with the STL.
I certainly don't feel the way you do.
Your objections about speed, readability and maintainability are VERY subjective. Well-written code using the STL can rival "roll your own code" any day.
Why keep reinventing a flat wheel by writing your own stuff already done with the STL.
I certainly don't feel the way you do.
Your objections about speed, readability and maintainability are VERY subjective. Well-written code using the STL can rival "roll your own code" any day.
Maybe I should've initially worded my question a little differently, I don't mean to cause a flamewar, start just a discussion. ;)
Yes, you are correct, they are subjective. It depends on the situation. For example I'm not going to use a list when I want to quickly destroy and recreate couple hundred thousand particles or game entities. It's quite easy to beat with a custom data structure.
Will I use a vector to read in the entire contents of a file directly? Definitely. It's pretty inituative and has no real drawbacks if I'm doing it once at the startup of a level.
This statement is a little contradictory to the previous one.
| Furry Guy wrote: |
|---|
| Your objections about speed, readability and maintainability are VERY subjective |
Will I use a vector to read in the entire contents of a file directly? Definitely. It's pretty inituative and has no real drawbacks if I'm doing it once at the startup of a level.
| Well-written code using the STL can rival "roll your own code" any day. |
Last edited on
The STL is written by people, read LOTS, who eat, sleep and live coding.
Yes, the STL can (not WILL) rival "roll your own code" any day. There are circumstances that require low-level stuff, but those are IMO exceptional circumstances. Knowing those circumstances require lots of experience, knowledge and more than a bit of "artistry."
Good programmers are paid big bucks to know what the hell they are doing. Well-written code is as much art as technology.
If you think what I said, and how I said it, is a flame-war, then just walk away. You ain't seen nothing yet.
Hint, simply disagreeing with your opinion is not a flame-war.
I expressed MY opinion. Nothing more, nothing less.
I could have been blunt, far more blunt, but then that wouldn't be all that conducive to a discussion. There are others here who can flay you alive and leave nothing but a pile of quivering chunks.
If all you wanted are people who hail your views and opinions as the greatest thing since sliced bread, or simply agree with you no matter what, I'm not one of those people.
I just disagree with your premise the STL and Standard Library are bloated, unreadable, etc. Does my disagreement with your views invalidate you as a person? Ii shouldn't.
*Moving on, lest things do degenerate into a flame-war*
Yes, the STL can (not WILL) rival "roll your own code" any day. There are circumstances that require low-level stuff, but those are IMO exceptional circumstances. Knowing those circumstances require lots of experience, knowledge and more than a bit of "artistry."
Good programmers are paid big bucks to know what the hell they are doing. Well-written code is as much art as technology.
| I don't mean to cause a flamewar |
If you think what I said, and how I said it, is a flame-war, then just walk away. You ain't seen nothing yet.
Hint, simply disagreeing with your opinion is not a flame-war.
I expressed MY opinion. Nothing more, nothing less.
I could have been blunt, far more blunt, but then that wouldn't be all that conducive to a discussion. There are others here who can flay you alive and leave nothing but a pile of quivering chunks.
If all you wanted are people who hail your views and opinions as the greatest thing since sliced bread, or simply agree with you no matter what, I'm not one of those people.
I just disagree with your premise the STL and Standard Library are bloated, unreadable, etc. Does my disagreement with your views invalidate you as a person? Ii shouldn't.
*Moving on, lest things do degenerate into a flame-war*
You should read what Bjarne Stroustrup, the dude who invented the C++ language, has to say on the issues you raise about low-level, "roll your own" code (myth #4):
https://isocpp.org/blog/2014/12/five-popular-myths-about-c-bjarne-stroustrup
Note: this was written before C++17 was really being discussed with any seriousness. C++14 was freshly minted.
Direct link to Myth #4:
https://isocpp.org/blog/2014/12/myths-3
Compile time is NOT performance when running the compiled code.
*leaves the room, now for sure*
https://isocpp.org/blog/2014/12/five-popular-myths-about-c-bjarne-stroustrup
Note: this was written before C++17 was really being discussed with any seriousness. C++14 was freshly minted.
Direct link to Myth #4:
https://isocpp.org/blog/2014/12/myths-3
Compile time is NOT performance when running the compiled code.
*leaves the room, now for sure*
| helios wrote: |
|---|
| Can you give an example? |
I wish I were still in the room so I could ask who you directed your question at, but alas, I can't. ;)
| Furry Guy wrote: |
|---|
| The STL is written by people, read LOTS, who eat, sleep and live coding. |
These developers are human, they make mistakes, their implementations are not perfect. On top of that, they are designed to be generic.
| Compile time is NOT performance when running the compiled code. |
| helios wrote: |
|---|
| Can you give an example? |
A lot of the problems I have with the standard library manifest themselves when you deal with larger code bases. It's much slower in general to link and debug template heavy code in general. An example small enough to fit in a forum post probably won't be great at highlighting these issues.
For example:
Ceres Solver is 154 times faster in Release than in Debug. That's quite ridiculous.
https://twitter.com/id_aa_carmack/status/835573906383634433?lang=en
The standard library does have its uses, but it is not ideal in many places. In basic, isolated use-cases it's sufficient. When I'm writing a simple 1-2 file tool it gets the job done. Introducing it throughout a larger codebase? I'm wary.
| Ceres Solver is 154 times faster in Release than in Debug. That's quite ridiculous. |
With what compiler?
Debug builds will usually be slower for several reasons.
1. Debug builds contain much more information to aid debugging. This information is not required in non-debug builds.
2. Debug builds usually do more run time diagnostics, for example some compilers do range checking when accessing vectors and arrays. Release builds usually don't do that "extra" work.
3. Debug builds usually use fewer optimizations than release builds.
The STL (by I assume you mean the Standard Library) isn't a singular entity written by an elite squad of programmers. |
The STL should not be confused with the standard library. The standard language is a different entity, you can make a program that doesn't use the STL but it will still be using the standard library.
Oh and I would say that both the STL and standard library are written by elite squads of programmers. Each implementation has it's own squads of extremely talented programmers, this is why it is useful to use several different compilers to verify the program is correct and not using some implementation detail.
| jlb wrote: |
|---|
| With what compiler? |
| Debug builds will usually be slower for several reasons |
| The STL should not be confused with the standard library. The standard language is a different entity, you can make a program that doesn't use the STL but it will still be using the standard library. |
| Oh and I would say that both the STL and standard library are written by elite squads of programmers. |
| Visual Studio 2015. |
Well there you go. VS is one of the compilers that do a lot of runtime checks when in debug mode.
| I am stating that extensively using templates within your project can severly reduce your Debug build performance. |
It is not the use of templates themselves that increase runtime in debug mode it is all the checking MS places into debug mode checks that slow down runtime performance.
| Given that the standard library is a heavily templated library, |
No the standard library is not heavily templates, in fact it has few if any template instances.
| Since a software developer spends most of their time debugging and maintaining code, this is very undesirable. |
Check your compiler documentation, it might be possible to reduce the overhead in Debug mode.
| The STL is the older library from the 90s that preceded the first C++ standard library. |
No, the STL, as we know it today, was not even part of the early pre-standard language. Templates were added after the standard library. The standard library contains strange things like fgets(), scanf(), and the rest of the C subsystem along with things that make simple classes, class constructors, and most other things for the Base language possible and is still in use today. The STL is template heaven and is also still in use today. These are two different libraries. The standard library is usually provided as a pre-compiled library (the header files usually only contain function prototypes and macros but no source code. The STL is in many cases is a header only implementation, which means that the class is defined and implemented in the header file.
By the way using templates either your own or one from the STL are usually header only implementations. With templates you usually have longer compile times and binary size but usually they don't affect runtime speed, in fact they may even speed things up because templates are usually inline entities since every instance of a template has it's own source code.
Last edited on
| jlb wrote: |
|---|
| No, the STL, as we know it today, was not even part of the early pre-standard language |
| Templates were added after the standard |
| cppreference wrote: |
|---|
| 1990: The Annotated C++ Reference Manual This book described the language as designed, including some features that were not yet implemented. It served as the de-facto standard until the ISO. New features: namespaces, exception handling, nested classes, templates |
| wikipedia wrote: |
|---|
The Standard Template Library (STL) is a software library for the C++ programming language that influenced many parts of the C++ Standard Library. It provides four components called algorithms, containers, functions, and iterators. ... Implementations Original STL implementation by Stepanov and Lee. 1994, Hewlett-Packard. No longer maintained. |
https://en.cppreference.com/w/cpp/language/history
https://en.wikipedia.org/wiki/Standard_Template_Library
| jlb wrote: |
|---|
| No the standard library is not heavily templates, in fact it has few if any template instances. |
https://en.wikipedia.org/wiki/C%2B%2B_Standard_Library
| With templates you usually have longer compile times and binary size |
| but usually they don't affect runtime speed |
Ehh, this devolved pretty quickly into somewhat of a holy war, not my intent, but what can one do?
Last edited on
| Is The Standard Library Really That Useful? |
| As I find myself becoming more and more seasoned, I find that I use the standard library much less and less. At first, I made quite an effort to use "modern C++" (at this time this was C++11). |
| Now, I find that using the standard library is quite distasteful for the most part. It's pretty bloated |
| Takes forever to compile |
There's a subset of C++ developers for whom compile speed (rather, iteration rate) is especially important.
| The code itself is completely unreadable |
Fortunately, a user shouldn't need to read the standard library.
| Don't get me wrong- I'm no C purist. I love C++11 threads, I use vectors and strings in certain areas, auto-for-loops (is that what they're called? lol), etc, but I find that specialized, POD, data structures typically beat the "idiomatic" equivalent both in speed, readability, and mantainability. |
| Am I the only one who feels like this? |
Last edited on
| JagerDesu wrote: |
|---|
| As I find myself becoming more and more seasoned, I find that I use the standard library much less and less. |
| JagerDesu wrote: |
|---|
| code itself is completely unreadable with literally all major compilers |
| JagerDesu wrote: |
|---|
| as time goes on I typically end up rewriting it in a more C-with-classes fashion.[...] I find that specialized, POD, data structures typically beat the "idiomatic" equivalent both in speed, readability, and mantainability. |
| JagerDesu wrote: |
|---|
| such as games [...] Am I the only one who feels like this? |
I guess I have come full circle on this.
in the mid 90s to early 00s, computers were still single core, and their clock speeds were still in MHZ. Worse, the STL was new and implementations of it combined with lack of best practices made for very slow code. I tried to write some stuff using early vectors and valarrays (lawl) and it was at times an order of magnitude slower than a C array. C++ strings were as clunky as any other string class (everybody had one and they were all sluggish and clunky). <algorithm> consisted of like sort and toupper or something, there were not a lot of useful ready to go functions. I threw in the towel and coded whatever ran the fastest; I had to. That usually mean Cish code.
Now, the libraries are better, lots of useful additions, lots of useful algorithms. valarray still is poorly done, and strings are still clunky, but the vast majority of our tools are very good now. They are fast and we have best practices to avoid performance gotchas.
And, the good news is that almost nothing has been actually removed fully. A few things are marked to not be used but still work fine and likely will for the rest of my life. If something is not working for you, you can go full bore C on it. As an example, I will probably always use printf over cout for formatted doubles. But we are absolutely MUCH better off with the tools today than we were in 2000.
in the mid 90s to early 00s, computers were still single core, and their clock speeds were still in MHZ. Worse, the STL was new and implementations of it combined with lack of best practices made for very slow code. I tried to write some stuff using early vectors and valarrays (lawl) and it was at times an order of magnitude slower than a C array. C++ strings were as clunky as any other string class (everybody had one and they were all sluggish and clunky). <algorithm> consisted of like sort and toupper or something, there were not a lot of useful ready to go functions. I threw in the towel and coded whatever ran the fastest; I had to. That usually mean Cish code.
Now, the libraries are better, lots of useful additions, lots of useful algorithms. valarray still is poorly done, and strings are still clunky, but the vast majority of our tools are very good now. They are fast and we have best practices to avoid performance gotchas.
And, the good news is that almost nothing has been actually removed fully. A few things are marked to not be used but still work fine and likely will for the rest of my life. If something is not working for you, you can go full bore C on it. As an example, I will probably always use printf over cout for formatted doubles. But we are absolutely MUCH better off with the tools today than we were in 2000.
Topic archived. No new replies allowed.