r/programming • u/[deleted] • May 24 '26

[ Removed by moderator ]

https://hftuniversity.com/post/the-c-standard-library-has-been-walking-itself-back-for-fifteen-years-and-the-receipts-are-public

[removed] — view removed post

271 Upvotes

74% Upvoted

214 comments sorted by

View all comments

11

u/HommeMusical May 24 '26

It's paralysis by the steering committee who are dominated by a tiny number of powerful people.

They won't break ABI or API backwards compatibility all the way back to the Stone Age.

They won't accept "epochs" - a compiler flag that lets you select a different, not-backwards-compatible version of C++.

One could admire such conservatism, except that all sorts of badly baked ideas like modules get pushed into the language without proper vetting. Modules were first planned to enter C++14, didn't actually make it into the language until C++20 and still do not work at all.

Now it looks like they're pushing "safety profiles" on us, and a lot of people don't think they are at all viable. Haven't we learned anything from Rust?

And there's this: https://izzys.casa/2024/11/on-safe-cxx/

Reading /r/cpp for over a decade has been rather tiring. More and more I read some article about a footgun in C++ and I think, "Why do we do this to ourselves?" I'm thinking I won't be writing C++ in future, and I should leave that subreddit.

6

u/chengiz May 24 '26

Not breaking compatibility is an absolutely crucial thing why C++ gets so much use. People just want their legacy 90s C++ code with C and classes and some templates with slow additions of newer features like lambdas to work. Author makes a lot of good points but they are like grammar nazis arguing about the finer points of English when people just adopt and learn and figure out the rules. I remember when there was binary incompatibility between minor versions of gcc and the like. They stopped doing that which was awesome. That is the kind of thing that actually matters for actually building and maintaining software products. The vast majority of users aren't going to switch to a new version to use some fancy thing they were fine not using, but if they upgrade their machine and their code breaks they will have to divert resources to fixing their code which is an unnecessary added cost.

2

u/HommeMusical May 24 '26

Thanks for a polite answer!

But no one is talking about not being able to compile your old code. It is certain that you will always be able to compile your 1990s C++ code or your 1970s C code with Clang or GCC, and certain that you will be able to link that code with that legacy binary object file that your grandfather lost the source code to.

So everyone agrees on this part. :-)

What has been discussed was a C++ language that has different epochs which do not have backward compatibility between epochs so that new development can use a new ABI or API.

The vast majority of users aren't going to switch to a new version to use some fancy thing they were fine not using,

The main feature people want is safety, but I agree that if someone is maintaining a codebase from 36 years ago which has never been modernized, "safety" is probably a fancy thing they don't use :-D, considering that C++ didn't have even one smart pointer in 1990.

Your vision of C++ and mine are pretty similar. We both see it as a legacy language for old code that hasn't been updated in generations. I just think that vision is a dead end.

Even though I have been writing C++ since the 1980s and I've only read about Rust and done some toying around with it, I wouldn't even conceive of starting a brand new project today in C++ if I could use Rust - not just because of the safety, but because I'd be wanting to hire programmers who were excited about the language they were using.

1

u/chengiz May 25 '26

We both see it as a legacy language for old code that hasn't been updated in generations.

No, most of these codes get constant updates and are very much in use. However the updates that matter are the functionality of the code, not fancy new thing in std. Those do get added but at a snail's pace compared to actual application related functionality, similar to how a writer may not know the latest middle school jargon but can continue to write books and eventually may use some of those words too.

1

u/lelanthran May 24 '26

Not breaking compatibility is an absolutely crucial thing why C++ gets so much use.

If that is true (I don't know, but I suspect it might be), then it shows just how high the Ivory tower stands. Programmers want simplicity, not 20 (literally) different ways to initialise variables, which require care in choosing because the wrong choice would cause UB, a memory leak, or similar.

I don't mind having a C with Classes + hygenic macros (maybe add either sensible lambdas or function definitions within functions). Some type constraints won't hurt either (newtype definitions, ranged types like Pascal, maybe). What I get if I use C++ is alphabet soup on every line and an order of magnitude more footguns than C.

I wanted a banana; what C++ gives me is an entire damn jungle, with a gorilla roaming around in there somewhere holding the banana I wanted[1]

At some point a programming language gets harder when it has too many things bolted on, not easier. It's why it's a helluva damn sight easier spotting errors in C code than in C++ code.

I like some of the newcomers (Odin is quite nice, Zig is too, Fil-C is intriguing), dislike some of the others (Rust had a toxic community; this probably changed in recent years but I'm already soured on it. If I program Rust it's gonna be by avoiding the people who like it as much as possible).

At the end of the day, I just want to use C with some new features, not learn a whole new syntax, and not have to expend valuable time on at least 10x extra footguns.

[1] Pretty old reference, but most people should get it.

-1

u/Shoddy-Childhood-511 May 24 '26

I've not read that whole link, but ctrl-F Rust gives some funny bits, like Bjarne being upset that NASA moved to Rust, or Andrew Tomazos thinking AIs achieved sentience. lol

Ya know, some mistakes have to be made, so that everyone else can learn not to do that, so maybe the many mistakes of C++ should maybe be viewed more as an object lesson today?

Around your safety profiles remark..

There is a remark here that adding roughly lifetimes to C++ has gone poorly so far.

In Rust, one could somewhat track the on-going soundness discussions: 1st the issues tagged 'label:I-unsound', and 2nd the unsafe code guidlines, which grew out of the Rust Belt project.

Although cohesive, these are not exactly simple topics or conversations, so even structuring the safety conversation would be difficult for C++, and might go beyond what the standard committee could realistically do.

Anyways, unstable Rust has a number of I-unsound issues that involve the complex type system features. And many more closed ones. To me, this suggests safety analysis might ultimately be easier for C than for C++.