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

251–260 of 334 posts

Re: C++: The Documentary

#251

Post by cyberax »

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 also caused developers to produce template-heavy code that took minutes to compile. We used to joke that these developers were "bitten by Alexandrescu".

But it was indeed a nice book that really made stataic polymorphism popular. Before that, most books focused on building object hierarchies with virtual functions, etc.

Re: C++: The Documentary

#252

Post by WalterBright »

CyberDildonics wrote: post #240
Maxatar wrote: post #213

Earlier quoted context omitted.

I don't know if this is true. In the 80s there were many languages that were C with additional features or C preprocessors that added and experimented with features similar to cfront. You had OOPC (object-oriented pre-compiler), Objective-C, C*, Concurrent-C. People were experimenting in all kinds of ways by taking C and trying things out with it.

I think it is absolutely true, because adding features to an experimental language that has no tools or ecosystem surrounding it does nothing and people know that. Niche experiments having features doesn't accomplish anything, but adding just one more feature to C seems plausible. With C++ people could point people to another production ready language compatible with C that people could use, so there was somewhere th…

> adding just one more feature to C seems plausible

I thought it would be a couple months to add C++ to my C compiler. 10 years later...

Re: C++: The Documentary

#254

Post by lostdog »

socalgal2 wrote: post #223

C++ needs to die. I get so many people are invested in it and so much code is written in it. I used to be a fan and it's still my main job. But, in 2026 with LLMs able to find all the exploits, and with more and more adversarials, we need a language that is opt-out of safety, not C++ which is opt-in + super vigilance to get safety. It doesn't work and decades of experience proves it.

C++ was a superb language for its time. There was nothing faster with as-powerful abstractions. It showed how far you can change a language too, with C++11 being a massively better language with shared_ptr and company.

It took in almost every idea, and the battlefield showed us which do work and which don't. We get to keep RAII, move vs copy, smart pointers, placement-new, and generics. We get to drop auto_ptr, copy-by-default, its specific exceptions implementation (fight me), multiple virtual inheritance, and templates as full code substitution.

In my opinion the battles have played out, and Rust is the best sum-up of what worked (it even inherited the compile times! Lucky us!)

Re: C++: The Documentary

#255

Post by bluGill »

tarnith wrote: post #218
bluGill wrote: post #119

Earlier quoted context omitted.

Are we talking about games or medical devices here? I expect different things from them. If a medical device needs to turn off bounds checking to get results I'm concerned enough to not want to let anyone use it. If a game can get a slight performance improvement I'm all for it, who cares if it crashes, it is just a game.

Who cares if it crashes? The users. We can all agree it's not medical systems, but audio DSP and game dev both end up rewriting a lot of STL stuff to suit their needs, and often using a restricted subset of modern C++ features for similar reasons. That isn't some arbitrary choice, but pretty much where everyone continually ends up when solving real-time problems using C++. Whether those be games or not.

You can prevent more than enough crashes with enough testing to make gamers happy. Even if you prove there is not out of bounds error I still want a medical device to check

Re: C++: The Documentary

#256

Post by deaddodo »

WalterBright wrote: post #245
andrewl-hn wrote: post #200

Earlier quoted context omitted.

Something that not many people consider. It is almost certain that C++ "saved" C by existing. Without C++ there would be an enormous pressure to add more features to C itself. One reason why C committee could get away without adding much over the years was that they could nod towards C++ and say "that's their job, not ours". And if later didn't exist who knows what kind of language C would become. Classes? Templates?…

> It is almost certain that C++ "saved" C by existing. Perhaps. But in the 80's, C was the most practical language to use on the PC, by far. And porting C code to other platforms was easy.

Yeah, OPs claim feels disconnected from C’s identity. C stayed conservative because the areas where it excels (to this day) benefit from its “portable assembler” design history. A history with no C++ wouldn’t have changed that, instead another (either non-C extended or alternative C-adapted [Obj-C, for instance]) language would have taken the market C++ did; likely with a larger runway time due to the lack of interoperability/superset compilation.

Re: C++: The Documentary

#257

Post by [deleted] »

jmalicki wrote: post #204
72deluxe wrote: post #156

Earlier quoted context omitted.

But C++98 is so different to even C++11. Bjarne's book covering C++11 read completely differently to the 98 version, I found.

That just adds to the incoherency. It's why I've found Rust a joy - enough had happened in programming languages, that it was able to reinvent C++ with some of the best parts of the Haskell/ML/Scala family, some of the ergonomics of Python/nodejs, and bringing the borrow checker too. C++ is this weird amalgam of like 7 different generations of languages. But by far the worst part is the developer hostility behind the…

[deleted]

Re: C++: The Documentary

#258

Post by bregma »

tialaramex wrote: post #194
patrick451 wrote: post #159

Earlier quoted context omitted.

> Sure, both languages offer both generic comparison sorts†. But the defaults matter and as always in C++ the defaults are wrong, here it's reflected in naming. Why, exactly, is the c++ std::sort "wrong"? There are tradeoffs both ways. You happen to prefer stable sorting to speed, but that is a preference not an objective fact.

> Why, exactly, is the c++ std::sort "wrong"? It's silently an unstable sort, which is surprising, and then to add insult to injury it's also slower. Yeah, I know, the C++ unstable sort is so slow it's slower than Rust's stable sort. YMMV for input types, sizes etc but generally that's what the numbers look like and though it's not universal it's actually quite common. "I bet the C++ is faster" is the wrong instinct,…

So C++ is "wrong" because it doesn't work like something that came along 40 years later and you used first?

The problem does not appear to be in C++.

Re: C++: The Documentary

#259

Post by bregma »

kllrnohj wrote: post #187
bregma wrote: post #142

Earlier quoted context omitted.

I work maintaining the toolchain and language runtimes for a commercial safety-certified embedded operating system. I am deeply familiar with C and C++ because I live it and breathe it every day and have done so for over 40 years. Most of our customers use C, probably for historic reasons but also because it is much much easier to reason about and that becomes very important when auditing for functional safety certif…

> I really recommend against using C++ for safety-certified embedded software. Stick to C. You're almost certainly better off with Rust at this point or, if you must have C-like development, Zig.

Neither Rust nor Zig are appropriate at this time for certified functional safety. Given the definition of the languages is "it does what one particular implementation of its compiler, runtime, and standard library does at this time" it's not possible to construct a workable safety case for their use.

Enthusiam and neat ideas are not sufficient to certify a development tool for functional safety.

Re: C++: The Documentary

#260

Post by tourist2d »

kibwen wrote: post #140
GodelNumbering wrote: post #89

Personal opinion: C++ is the most elegant language I have used (for about 15 years). 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 acknowledge the limitations and uncertainties that come from compilers etc, but still

An elegant language is one that achieves a lot with very little. Forth and Scheme are elegant languages. You're free to like working in C++, and you can sure achieve a lot with it, but I don't think it's controversial to say that it does not do so with very little.

[dead]
Post reply on HN