Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++: The Documentary

herbsutter.com

Post reply on HN
Print view View original

271–280 of 334 posts

Re: C++: The Documentary

#271

Post by jviotti »

jdw64 wrote: post #11

It's surprising that C++'s development trend continues. When a game or program is made with C++, it's usually nice because performance is mostly guaranteed. But if someone told me to write C++ myself, I'd cry. There's too much to memorize, and the standards are too varied. When I go to a project site for maintenance and it's a C++ project, I instantly lose energy — because it's just too difficult. I'd be happy if som…

You get used to writing C++, just like you get used to writing any language. I've been writing C++ for quite some time already, on a daily basis, and it became second nature. Though I remember how much of a pain it was when I initially move into it

Re: C++: The Documentary

#272

Post by CupricTea »

fc417fc802 wrote: post #66
zerr wrote: post #24

Earlier quoted context omitted.

You can be pretty productive even with 70% of the language :) It is a common misconception that C++ is suitable only for game engines and similar domains. It is perfectly fine for applications domain as well. As a side note, regarding your profile info, unless you are based in North Korea, please at least add one 0 to your rate. You'll get more long-term and high-quality clientele.

> You can be pretty productive even with 70% of the language Or even far less than that. I like to use it as C with lambdas and namespaces. Sprinkle in metaprogramming as needed. Even just not having to remember to call cleanup code thanks to dtors would alone be enough to sell me on it.

I once wrote a pure C project years back that made heavy use of complex numbers and 2D/3D vector math. At one point I got so fed up debugging my expressions under an endless parentheses-hell of `vadd(vmul(vadd(...), vadd(vmul(...))))` that I threw my hands up and changed the file extensions to .cpp just to use std::complex and enough operator overloading to type vector expressions like a human being.

Re: C++: The Documentary

#273

Post by ahartmetz »

ergonaught wrote: post #250
tenderfault wrote: post #60

So happy to see Andrei Alexandrescu was included in this documentary. His book on modern C++ design was a mind opener at the time I read it. Maybe still is today. Anybody else read it?

It still amuses me, but Andrei's books were the "last straw" that pushed me away from C++ for many years. Great books, truly, and they helped cement the notion that I wanted to move on to a different language. (Go, at the time.)

I seriously hated the book, too. The title should have been "Cute template tricks to make you feel smart and increase compile time, when to use: approximately never". I think about two things from the book caught on, one of them how to deal with lists of template arguments pre C++11. It's kind of horrible, but was sometimes (more or less) necessary.

Re: C++: The Documentary

#274

Post by doug_durham »

igouy wrote: post #246
doug_durham wrote: post #199

Earlier quoted context omitted.

You think that LISP and Smalltalk aren't widely used is because they weren't easy to implement in the late 1980's? There have been many languages that have risen to prominence in the 40 years since, yet LISP and Smalltalk remain niche languages.

Which new languages have risen to prominence outside of a niche?

Rust, Python, Java, Ruby, Scala, Swift to start with. These are languages with very wide adoption. Objective-C is very Smalltalk-like, but it is being phased out for Swift.

Re: C++: The Documentary

#275

Post by drivebyhooting »

wavemode wrote: post #207
GnarfGnarf wrote: post #104

Earlier quoted context omitted.

What, you rewrote std::deque? Whew!

Deque is one of the easier ones. I echo the parent commenter - the STL has a massive negative impact on compile times. And for what? The STL is not even fast. The way the standards are written, std::unordered_map has to be implemented as a tree rather than a flat open-addressing hashtable, which would've been far superior due to cache locality. For my own project I rolled my own string, string_view, map, set, optiona…

Unordered map is a hash map with separate chaining.

Re: C++: The Documentary

#276

Post by tim333 »

claiir wrote: post #5

> currently (as of Q3 2025) the fastest-growing of the top four languages in the world… +90% users in the past 3.5 years. Because of AI, right?

Partly - the documentary gives that a mention https://youtu.be/lI7tMxzSJ7w?t=3862

Also

>It is because we have enduring demand for languages that are good at performance per watt.

(1 min in from above link)

Re: C++: The Documentary

#277

Post by snuxoll »

dysoco wrote: post #157
dbdr wrote: post #95

Earlier quoted context omitted.

> If you are the 'systemizer' type and like to have an extremely precise mental model of the thing you write down to the last bit, nothing beats C++. I would say the same thing of Rust.

I very much prefer to work in Rust but it does force you to design things in an counter-intuitive way in certain situations (linked lists for the canonical example). Specially for lower level software I find C or C++ to allow for much more flexibility and thus the most straightforward design possible.

I really don't think Rust does, but that's if you're outright refusing to use `unsafe` anywhere. Might be a little noisier if you're using things like ManuallyDropped instead of just using raw pointers, but the language doesn't stop you from doing things in ways you would with C or C++, it encourages you to encapsulate the hard parts so you can worry less about correctness of 98% of your codebase, instead of fearing incorrect behaviors can silently sneak in.

Re: C++: The Documentary

#278

Post by nicebyte »

techbrovanguard wrote: post #189
rustyhancock wrote: post #91

Earlier quoted context omitted.

I agree. You don't learn or know C++ in the way you learn or know C. You never have the total language spec in mind. Much of it you will never (and for some of it should never) come across. The way I think of it C is an abstraction of the machine, so thin it's nearly transparent. C++ is an abstraction over programming paradigms, letting you pick how you think. Everything else abstracts the machine away, replacing it…

> C is an abstraction of the machine, so thin it's nearly transparent. Looks like someone fell for the C abstract machine trap yet again. No, C is isn’t an abstraction of the machine.

they're technically not wrong. C is literally an "abstraction" of the machine. As we know, the whole point of an abstraction is to ignore the multitude of details :-)
Post reply on HN