Is The Standard Library Really That Useful?

[JagerDesu]

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.

[George PlusPlus]

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.

[JagerDesu]

Maybe I should've initially worded my question a little differently, I don't mean to cause a flamewar, start just a discussion. ;)

Furry Guy wrote:

Your objections about speed, readability and maintainability are VERY subjective

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.

Well-written code using the STL can rival "roll your own code" any day.

This statement is a little contradictory to the previous one.

[helios]

Can you give an example?

[George PlusPlus]

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.

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*

[George PlusPlus]

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*

[George PlusPlus]

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. ;)

[JagerDesu]

Furry Guy wrote:

The STL is written by people, read LOTS, who eat, sleep and live coding.

The STL (by I assume you mean the Standard Library) isn't a singular entity written by an elite squad of programmers. The standard is drafted, then finalized. Then different groups of developers attempt to write compliant implementations.

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.

Compile time is also a finite resource. Developers do not have time to wait around all day for their code to compile. C++ without template witchery takes long enough to compile. Every second it takes to compile is just another second of downtime that a developer could be using to improve the product.

helios wrote:

Can you give an example?

An example of what, more specifically?

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.

[jlb]

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.

[JagerDesu]

jlb wrote:

With what compiler?

Visual Studio 2015.

Debug builds will usually be slower for several reasons

Yes, I am aware of this. I am not debating whether Debug builds are slower than Release builds or not. I am stating that extensively using templates within your project can severly reduce your Debug build performance. Given that the standard library is a heavily templated library, this applies to it as well. Since a software developer spends most of their time debugging and maintaining code, this is very undesirable.

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.

The STL is the older library from the 90s that preceded the first C++ standard library. I assumed that Furry Guy was referring to the standard since the STL is never used anymore. I figured there was no point in being pendantic over semantics as it wouldn't really contribute much to the conversation.

Oh and I would say that both the STL and standard library are written by elite squads of programmers.

My point was that the Standard Library isn't a singular library written by a singular group of people. It's similar to how OpenGL is simply a standard; separate vendors have separate implementations. Note that I am not saying that the programmers on this are not talented; I am saying they are human. They are not infaillable.

[jlb]

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.

[JagerDesu]

jlb wrote:

No, the STL, as we know it today, was not even part of the early pre-standard language

I never said it was.

Templates were added after the standard

Huh?

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.

Yes it does. I think you're confusing the C runtime and the C++ Standard Library.
https://en.wikipedia.org/wiki/C%2B%2B_Standard_Library

With templates you usually have longer compile times and binary size

Yes, this is one of my points.

but usually they don't affect runtime speed

They do for debug builds. This is not only for Visual Studio, but for GCC and Clang as well.

Ehh, this devolved pretty quickly into somewhat of a holy war, not my intent, but what can one do?

[mbozzi]

Is The Standard Library Really That Useful?

IMO, yes.

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).

It shouldn't be taken for granted that modern == good (or the opposite).

Now, I find that using the standard library is quite distasteful for the most part. It's pretty bloated

No, I disagree. The stdlib's containers and algorithms are quite tightly designed. They make one of the nicest C++ APIs I've had the pleasure of using.

Takes forever to compile

Agreed. One of the stdlib's issues is that its header files aren't sufficiently granular. Each standard library header included potentially introduces thousands of lines of unnecessary code to each client.

There's a subset of C++ developers for whom compile speed (rather, iteration rate) is especially important.

The code itself is completely unreadable

Unfortunately, yes. Large parts of the standard library have lots of tricky optimizations and plenty of compatibility issues besides. There's a significant chance that the experts who wrote it are solving problems that the average reader hasn't considered.
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.

Sure. The choice to apply or avoid a particular feature should be granular. The answer will depend on the component you're working on. For example, some might find the stdlib especially beneficial on API boundaries where it's advantages of genericity, flexibility, and strong typing are most significant. Similarly, it might be worse than useless when one is gluing C code together.

Am I the only one who feels like this?

Doesn't look like it. A couple months ago this blog post made the rounds: http://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/

[Cubbi]

JagerDesu wrote:

As I find myself becoming more and more seasoned, I find that I use the standard library much less and less.

Opposite evolution here. The more I work as a software engineer, the more I appreciate the costs and burdens of in-house development, and the more deeply I analyze every library available before (if ever) making a decision to commit to designing my own. As for the C++ standard library, I have a hard time even remembering when I stopped seeing that as something separable from the core language.

JagerDesu wrote:

code itself is completely unreadable with literally all major compilers

Maybe I've done too much C++, but I find all three C++ stdlibs to be easily readable. LLVM libc++ is pretty much presentation/textbook level code.

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.

"C-with-classes" is the hardest way (IME) to achieve any of those goals, but..

JagerDesu wrote:

such as games [...] Am I the only one who feels like this?

...that is actually the zeitgeist of gamedev community, as far as I can tell from their posts and presentations (I never had first-hand experience with that world, my career path was osdev -> realtime/embedded -> finance)

[jonnin]

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.