I am not a C++ programmer, but I found that book extremely interesting and a pleasure to read. I think I have publicly said so before, but I wish there were books like this for more programming languages. There's a couple of fascinating HOPL talks on languages like Lisp and Lua, but due to brevity, they are not nearly as detailed and in-depth as this one.

IMHO the STL is one of mankind’s greatest accomplishments.

Many high performance projects use vector but few other containers.

If the STL had a lesson to teach us it should have been "iterators everywhere, including for your own algorithms and container types." Instead most people learned "C++ has all the containers you need built in, throw away your performance tricks and let it call malloc a million times."

As an example, STL unordered-maps have fairly strict requirements around iterator invalidation and that results in indirection that do affect performance. It's pretty easy to make a "faster" unordered_map that tosses that requirement (as many do).

Right. And then it is actually a lot simpler to simply use pointer + size pairs [1] instead of std::vector. Changing to explicit allocation was the best decision I've made. I now find myself not longing for any C++ features anymore at all. I haven't needed anything besides a little allocation wrapper [2] and maybe a string-to-hash map since.

[1] Or n pointers + 1 size for parallel arrays, indicating that it's a bad idea to glue pointer + size in the first place.

[2] https://gist.github.com/jstimpfle/562b2c3e9fe537e378351bb9d5...

string-to-int hash map

STL really is a cruel joke.

is it ok to mutate a data structure while an iterator to it is live? It depends, which makes it much less abstract and generic than it could be (and that people believe it is)

Error messages are useless. Compilers can and do (recently) help with that, but the main issue is the convoluted STL design in which every instantiation’s type name actually takes a full 80x25 screen to spell out.

STLs primary objects are individual iterated elements, which does abstract over pointers (as was stepanov’s intention) but are at such a low level of abstraction as to be onerous.

Modern C++ is slightly better.

https://news.ycombinator.com/item?id=16442743

To say it’s a problem is misleading at best.

Other languages and runtimes use the notion of an iterator or cursor that is alone enough to perform all looping-like operations on the container including efficient erase() and can cheaply (so it is ok to have that in production) or even with good optimizing compiler at zero cost provide protection against container mutations.

Modern c++ shows there was/is room for improvement, but it does not fundamentally simplify the language imo.

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

2) Even with cheating in scare quotes, name-calling is not OK.

I say this from personal experience; in one case I was doing timing studies to solve performance problems, and wound up fooling myself by measuring the wrong thing!

In this case, is it fair to use SIMD intrinsics? It depends on what you're trying to measure. I think that's why "cheating" is in scare quotes, because what would be cheating in one context might be useful information in another.

For instance, if C++ is providing SIMD intrinsics, it's going to beat other languages, and if I just want current performance statistics, that's the question I want to answer.

If the question is, "what's the overall quality of the code delivered by the compiler / optimizer" then using specific tricks doesn't give me a good answer.

dralley's comment does not do that.

There's nothing difficult here: simply say that those X of N leading C++ programs use SIMD intrinsics, when the corresponding Rust programs do not.

dralley might even say that SIMD intrinsics have been available in Rust nightly for years.

dralley might even say that someone has contributed a Rust program that does use SIMD intrinsics, but that program was slower than other Rust programs:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Perhaps if C++ [or Rust] is providing SIMD intrinsics that is not in-itself a magical silver bullet.

And then there are all of the safety features of Rust; while there is a learning curve, it is much easier to learn the concepts of lifetimes and ownership when the compiler is helping to enforce proper usage.

I have almost 30 years of C++ experience and about 6 months of Rust. My gut feeling is that the languages are equally difficult to understand but that the experience of writing code in them is very different.

I'm sure Rust will have its own set of surprises as I keep using it.

But I can't believe they will be nearly as bad as those that C++ comes with. ;)

I always speculated that Jobs went up to the engineers, "hey, we use a lot of Objective C in OS X, right?"

"Yes, sir, Mr. Jobs."

"Well, everyone else, namely Adobe, is using C++ and we need them writing apps for the Mac. We've gotta have those apps. So we're going to need to support that."

"Um, yes sir, Mr. Jobs, we'll get right on that."

He leaves, and they look around nervously. "He's pulling our leg, right?"

As I've said quite recently elsewhere, C++ is an archaeological dig of a language. There are something like 4 major strata. If you would learn and use C++, it behooves you to pick a particular style, then stick to that. (RAII and smart pointers are very useful!)

There's something called the Taligent coding standards, which were once popular, then later castigated as turning C++ into "a poor man's Smalltalk." Small teams can write some dandy code using that style. Everything can fall apart at scale, however.

(EDIT: Here's an example from elsewhere in these comments: https://news.ycombinator.com/item?id=17463569 )