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

Safe C++ proposal is not being continued

sibellavia.lol

Post reply on HN
Print view View original

21–30 of 226 posts

Re: Safe C++ proposal is not being continued

#21

Post by BoxFour »

quotemstr wrote: post #14
int_19h wrote: post #9

Earlier quoted context omitted.

The reason why WHATWG was able to take over HTML like that is because all the people & companies that were actually making the browsers were onboard. With C++, my impression is that most implementers simply aren't interested. And, conversely, most people who might be interested enough to roll a new implementation have already moved to Rust and make better use of their time improving that.

You're right, but dammit, I wish you weren't. A world in which we can evolve existing large C++ codebases gradually towards safety instead of having to RRiR is a better world. There are lots of cool innovations C++ made that will just disappear from the Earth, forever, if C++ can't be made memory safe in the same sense Rust is. I mean, Rust doesn't even support template specialization. I don't think it's too late for…

> I don't think it's too late for someone to fork both C++ and Clang and make something that's actually a good synthesis of the old and the new.

People have tried variants of this already: Carbon, for example. I don’t think anyone outside of Google uses it, though, and even within Google I suspect it’s dwarfed by regular C++.

I don’t think C++ will become irrelevant for a long time. Recent standards have added some cool new features (like std::expected), and personally I feel like the language is better than ever (a biased opinion obviously).

Memory management is still a huge elephant in the room, but I don’t think it’s becoming irrelevant.

Re: Safe C++ proposal is not being continued

#22

Post by Yoric »

quotemstr wrote: post #14
int_19h wrote: post #9

Earlier quoted context omitted.

The reason why WHATWG was able to take over HTML like that is because all the people & companies that were actually making the browsers were onboard. With C++, my impression is that most implementers simply aren't interested. And, conversely, most people who might be interested enough to roll a new implementation have already moved to Rust and make better use of their time improving that.

You're right, but dammit, I wish you weren't. A world in which we can evolve existing large C++ codebases gradually towards safety instead of having to RRiR is a better world. There are lots of cool innovations C++ made that will just disappear from the Earth, forever, if C++ can't be made memory safe in the same sense Rust is. I mean, Rust doesn't even support template specialization. I don't think it's too late for…

FWIW, Rust doesn't have specialization yet because they're really hard to get right without introducing new undefined behaviors.

This doesn't mean that it's not possible to achieve a safe subset of C++ that supports template specialization, but it suggests that we aren't going to see it any time soon.

Re: Safe C++ proposal is not being continued

#23

Post by Yoric »

tialaramex wrote: post #20
quotemstr wrote: post #14

Earlier quoted context omitted.

You're right, but dammit, I wish you weren't. A world in which we can evolve existing large C++ codebases gradually towards safety instead of having to RRiR is a better world. There are lots of cool innovations C++ made that will just disappear from the Earth, forever, if C++ can't be made memory safe in the same sense Rust is. I mean, Rust doesn't even support template specialization. I don't think it's too late for…

Well like you said, Fortran didn't actually go anywhere. Fortan 77 is a terrible programming language, but you can't seriously claim it "disappeared from the Earth". Not that long ago tsoding was like "I should learn Fortran" and wrote a bunch of Fortran. Obviously from his perspective some things about Fortran are awful because it's very old, but it wasn't somehow impossible to do. There are a few really amazing thi…

> There are a few really amazing things which have been achieved in C++ like fmt, a compile time checked, userspace library for arbitrarily formatting variadic generic parameters.

Anecdotal, but that's hardly unique to C++. So even if C++ were to disappear overnight (which we all agree won't happen), this wouldn't be a burning-library-of-Alexandria moment.

Re: Safe C++ proposal is not being continued

#24

Post by efuquen »

tialaramex wrote: post #18

I am actually much more pessimistic about Profiles than Simone. Regardless of the technology the big thing Rust has that C++ does not is safety culture , and that's dominant here. You could also see at the 2024 "Fireside chat" at CppCon that this isn't likely to change any time soon. The profiles technology isn't very good. But that's insignificant next to the culture problem, once you decided to make the fifteen min…

And I would say the deficiencies in Profiles and the fact Safe C++ was killed is the technical decisions reflecting the culture problem.

Re: Safe C++ proposal is not being continued

#25

Post by tialaramex »

zevets wrote: post #19
quotemstr wrote: post #17

Earlier quoted context omitted.

I've been thinking for a while now about using dependant typing to enforce good numerics in numerics kernels. Wouldn't it be nice if we could propagate value bounds and make catastrophic cancellation a type error? Have you worked much with SAL and MIDL from Microsoft? Using SAL (an aesthetically hideous but conceptually beautiful macro based gradual typing system for C and C++) overlay guarantees about not only refer…

Please do this. But first: we need to take step-zero and introduce a type "r64": a "f64" that is not nan/inf. Rust has its uint-thats-not-zero - why not the same for floating point numbers??

You can write your "r64" type today. You would need a perma-unstable compiler-only feature to give your type a huge niche where the missing bit patterns would go, but otherwise there's no problem that I can see, so if you don't care about the niche it's just another crate - there is something similar called noisy_float

Re: Safe C++ proposal is not being continued

#26

Post by tialaramex »

Yoric wrote: post #23
tialaramex wrote: post #20

Earlier quoted context omitted.

Well like you said, Fortran didn't actually go anywhere. Fortan 77 is a terrible programming language, but you can't seriously claim it "disappeared from the Earth". Not that long ago tsoding was like "I should learn Fortran" and wrote a bunch of Fortran. Obviously from his perspective some things about Fortran are awful because it's very old, but it wasn't somehow impossible to do. There are a few really amazing thi…

> There are a few really amazing things which have been achieved in C++ like fmt, a compile time checked, userspace library for arbitrarily formatting variadic generic parameters. Anecdotal, but that's hardly unique to C++. So even if C++ were to disappear overnight (which we all agree won't happen), this wouldn't be a burning-library-of-Alexandria moment.

Well. What other examples of this feat are you thinking of?

To me the things which come to mind are either compiler magic (e.g. C printf) or they rely on RTTI (e.g. Odin and similar C-like languages) and neither of those is what fmt does, they're "cheating" in some sense that actually matters.

Re: Safe C++ proposal is not being continued

#27

Post by randomNumber7 »

tiberius_p wrote: post #10

I'm not up to date with the latest developments in C++ but would't it be straightforward to do something like "#pragma pointer_safety strong" which would force the compiler to only accept the use of smart pointers or something along those lines. Was anything like this proposed so far?

The problem with this would probably be that you usually have to use some libraries with C APIs and regular pointers.

You could compile your program with address sanitizer then it at least crashes in a defined way at runtime when memory corruption would happen. TCC (tiny C compiler initially written by fabrice bellard) also has such a feature I think.

This of course makes it significantly slower.

Re: Safe C++ proposal is not being continued

#28

Post by Henrystewart »

tialaramex wrote: post #18

I am actually much more pessimistic about Profiles than Simone. Regardless of the technology the big thing Rust has that C++ does not is safety culture , and that's dominant here. You could also see at the 2024 "Fireside chat" at CppCon that this isn't likely to change any time soon. The profiles technology isn't very good. But that's insignificant next to the culture problem, once you decided to make the fifteen min…

[dead]

Re: Safe C++ proposal is not being continued

#29

Post by BoxFour »

tiberius_p wrote: post #10

I'm not up to date with the latest developments in C++ but would't it be straightforward to do something like "#pragma pointer_safety strong" which would force the compiler to only accept the use of smart pointers or something along those lines. Was anything like this proposed so far?

> pragma pointer_safety strong" which would force the compiler to only accept the use of smart pointers

You’d possibly just be trading one problem for another though - ask anyone who’s had to debug a shared ownership issue.

Re: Safe C++ proposal is not being continued

#30

Post by AlotOfReading »

tialaramex wrote: post #18

I am actually much more pessimistic about Profiles than Simone. Regardless of the technology the big thing Rust has that C++ does not is safety culture , and that's dominant here. You could also see at the 2024 "Fireside chat" at CppCon that this isn't likely to change any time soon. The profiles technology isn't very good. But that's insignificant next to the culture problem, once you decided to make the fifteen min…

It doesn't show up in the online videos, but there was a huge contingent of people at that fireside chat wanting a reasonable safety story for C++. The committee simply doesn't have representation from those people and don't seem to understand why it's an existential risk to the language community. The delivery timelines are so long here that anything not standardized soon isn't going to arrive for a decade or more. That's all the time in the world for Rust (or even Zig) to break down the remaining barriers.

Profiles and sanitizers just aren't sufficient.

Post reply on HN