Hacker News Reader

Comment by nf05papsjfVbc | Hacker News Reader

Dr. Stroustrup took a lot of pain to ensure the language was useful and did not break backward compatibility. He also always maintained that if you don't use a feature you shouldn't pay for it (in terms of performance). Eventually, it became even more popular and there is now a whole organisation behind the international standards for the language. The book "The Design and Evolution of C++" helps one understand why some things are the way they are and sometimes it helps understand why some things exist in the language in the first place.

The language takes a lot of flak but I think it is quite good given the constraints it has and the modern version is an amazing leap forward in ease of use as well.

View on HN

> The book "The Design and Evolution of C++" helps one understand why some things are the way they are and sometimes it helps understand why some things exist in the language in the first place.

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.

I read that book around 1998 and was an instant convert. C++ has a steep learning curve, and does not stop you from getting yourself into a lot of trouble, but it does stand up to Bjarne’s original promise about performance.

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

The STL doesn't always live up to the standard of "zero overhead abstractions." The list is not high performance, many implementations of hash tables never shrink (and used to have O(n) erase!), and deque is a bad joke (no chunk size control, plus laughable fixed chunk size on some common platforms).

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

> Most high performance projects use vector and little else.

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-hash map

string-to-int hash map

Endeavors that really need high performance tend to use other standard library implementations. I think EA has their own, for example.

The motivation for creating of EASTL was mostly to get rid of allocations. std::vector does not have an allocation problem. Other STL containers do.

"zero overhead abstractions" is a principle of the language, not the library. The STL containers are clearly designed to be on the "safer" side than the performant side. You are right that, perhaps, we've extracted the wrong lesson from the STL but your version ("iterators everywhere, including for your own algorithms and container types") is still definitely the right message.

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

C++ the language, maybe.

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.

Could be true, but a modern language such as Rust has its own problems:

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

What you’ve just linked to is a solution to the issue mentioned above. Rust makes a lot of guarantees, but sometimes those guarantees run afoul of certain required operations in different contexts. For this reason the language has an escape valve, unsafe, and the unsafe blocks are blindingly obvious in the code.

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

STL tried hard to abstract pointer manipulation semantic of low-level C and apply it everywhere whether it fit or not. This pointer heritage inevitably lead to misfeatures like invalidation of iterators under container mutations or the need to have access both to the iterator and its container to implement things like vector::erase().

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.

I have recently got upto speed with c++17 features and I want to explore more C++. So far I have used Java and Python to build webapps. Are there libraries/framework that can replicate the MVC in C++ as well? I think I can extend functionalities from there.

Not quite MVC but RxCpp exists and can help with designing MVP style code. (also known as event driven programming)

I always felt that if you wanted the same functionality as c++ in terms of performance, flexibility and power of abstraction, you'd end up with something as complex as c++.

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

Only if it need to have backward compatibility. Rust doesn’t so it can be vastly simpler.

How is Rust simpler than C++?

Are you talking about grokking the language and its more excotic concepts or writing code on it?

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

Rust is a much smaller language and stdlib than C++ (though still quite large). Rust makes an effort to make many things explicit that are implicit in C++, such as numeric type conversions. Rust's traits are conceptually simpler than classes, especially if you want multiple inheritance. Rust's templates/generics are much closer to the core language than C++'s template language.

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 love Rust. Especially for emudev and embedded development (fields I would traditionally use C or C++). However, it still performs worse than C++ in most cases [1].

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

A number of those C++ benchmarks are "cheating" by using SIMD intrinsics, which was only stabilized in Rust about two weeks ago.

1) Specifically which of those C++ programs? Innuendo is not OK.

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

It's not innuendo when you consider the inherent problems with benchmarks. Once you have an algorithm, it's so hard to define what an objective benchmark is that you should assume the implementation is cheating, even if you wrote it.

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.

> …when you consider the inherent problems with benchmarks…

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.

If I had any real complaint about the execution of C++ it would probably just be the backwards compatibility with C. Don't get me wrong: I love C, and also I don't think it would've been possible for C++ to have gained so much relevance so fast had it not started as C with Classes. However, it does feel like a lot of kludges in C++ come from its legacy. Something that often confuses beginners is the sheer number of ways to do a thing, and some of them are not recommended to be used at all. With C diverging in incompatible ways from C++, the backwards compatibility has made less sense than ever.

If people wanted an object-orientated compiled language that didn't interlink with and offer a smooth transition from C, there were already alternatives (e.g. Modula).

The direction C++ went was pretty different from even what would've been considered 'object oriented' at the time. I'd say half of what made C++ special was how much stuff could happen purely at compile time.

That's why the sheer insanity of Objective C++ intrigues me.

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?"

The book "The Design and Evolution of C++" helps one understand why some things are the way they are

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 )

I am not a C++ fan. But D&E of C++ is one the best books I ever read. It explains a lot of the real world of the decisions they had to make. It was iluminating.

Reply on news.ycombinator.com