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

31–40 of 226 posts

Re: Safe C++ proposal is not being continued

#31

Post by 1718627440 »

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

> Rust has its uint-thats-not-zero

Why do we need to single out a specific value. It would be way better if we also could use uint-without-5-and-42. What I would wish for is type attributes that really belong to the type.

    typedef unsigned int __attribute__ ((constraint (X != 5 && X != 42))) my_type;

Re: Safe C++ proposal is not being continued

#32

Post by pklausler »

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…

Judging Fortran by looking at Fortran 77 is preposterously uninformative.

Re: Safe C++ proposal is not being continued

#33

Post by IshKebab »

AlotOfReading wrote: post #30
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.…

Yeah because the committee is now people that a) really love C++, and b) don't care enough about safety to use Rust instead.

I think there are plenty of people that must use C++ due to legacy, management or library reasons and they care about safety. But those people aren't going to join language committees.

Re: Safe C++ proposal is not being continued

#34

Post by pizlonator »

favorited wrote: post #13
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?

You might be interested in this talk[0] by a WebKit engineer on how they're implementing similar approaches using libTooling and their own smart pointer types. For example, their tooling prevents code like this: if (m_weakMember) { m_weakMember->doThing(); } from compiling, forcing you to explicitly create an owning local reference, like so: if (RefPtr strongLocal = m_weakMember.get()) { strongLocal->doThing(); } unl…

I was going to link to this.

My interpretation of Geoff's presentation is that some version of profiles might work, at least in the sense of making it possible to write C++ code that is substantially safer than what we have today.

Re: Safe C++ proposal is not being continued

#35

Post by safercplusplus »

quotemstr wrote: post #5

Okay, so treat the C++ standards committee the same way the HTML5 people treated W3C. If they insist on making themselves irrelevant, let them. Profiles cannot achieve the same level of safety as Rust and it's obvious to anyone who breathes. Profiles just delete stuff from the language. Without lifetimes reified as types you can't express semantics with precision enough to check them. The moment string_view appears,…

> Profiles cannot achieve the same level of safety as Rust

So the claim is that the scpptool approach[1] can, while remaining closer to traditional C++, and not requiring the introduction of new language elements. Since the scpptool-enforced safe subset of C++ is an actual subset of C++, conforming code continues to build with your existing compiler. It just uses an additional static analyzer to check conformance.

For the 90% or whatever of C++ code that is not actually performance sensitive, the associated SaferCPlusPlus library provides drop-in and "one-to-one" safe replacements for unsafe C++ elements (like standard library containers and raw pointers). (For example, if you're worried about potentially invalid vector iterators, you can just replace your std::vectors with mse::mstd::vectors.) With these elements, most of the safety is enforced in the type system and not reliant on the static analyzer.

Conforming implementations of performance-sensitive code would be more restricted and more reliant on the static analyzer for safety enforcement. And sometimes requires the use of library elements, like "borrowing objects", which may not have analogies in traditional C++. But overall, even high-performance conforming code remains very recognizable C++.

The claim is that the scpptool approach is a straightforward path to full memory (and data race) safety for C++, and the one that requires the least code migration effort. (And again, as an actual subset of existing C++, not technically dependent on standard committees or compiler vendors for its implementation or deployment.)

[1]: https://github.com/duneroadrunner/scpptool/blob/master/appro...

Re: Safe C++ proposal is not being continued

#36

Post by pizlonator »

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…

> The profiles technology isn't very good.

Can you be very specific about why?

Here's the argument for why profiles might work: with all of the profiles enabled, you are only allowed to use the safe subset of C++ and all of the unsafe stuff is hidden behind APIs whose implementations don't have those profiles enabled. Those projects that enable all profiles by default effectively get Swift-like or Rust-like protection.

Like, you could force all array operations to use C++ stdlib primitives, enable full hardening of the stdlib, and then have bounds safety.

And you could force all lifetime operations to use C++ stdlib refcounting primitives, and then have lifetime safety in a Swift-like way (i.e. eager refcounting everywhere).

I can imagine how this falls over but then it might just be a matter of engineering to make it not fall over.

(I'm playing devils advocate a bit since I prefer Fil-C++.)

Re: Safe C++ proposal is not being continued

#37

Post by steveklabnik »

1718627440 wrote: post #31
zevets wrote: post #19

Earlier quoted context omitted.

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

> Rust has its uint-thats-not-zero Why do we need to single out a specific value. It would be way better if we also could use uint-without-5-and-42. What I would wish for is type attributes that really belong to the type. typedef unsigned int __attribute__ ((constraint (X != 5 && X != 42))) my_type;

Those are the unstable attributes that your sibling is talking about.

Re: Safe C++ proposal is not being continued

#38

Post by fooker »

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…

> fork both C++ and Clang

Great! What are you waiting for?

If you try to answer that question, you'll also find why other similar projects are not finding much traction yet.

Re: Safe C++ proposal is not being continued

#39

Post by Animats »

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…

Regardless of the technology the big thing Rust has that C++ does not is safety culture, and that's dominant here.

True. So many proposals have gone by over the years. Here's one of mine from 2001.[1] Bad idea. The layers of cruft in C++ have become so deep that it's a career just to understand them.

DARPA has something called the TRACTOR program, "Translate All C to Rust". It's been underway for a year, and they have a consortium of universities working on it. Not much, if anything, has come out. Disappointing.

Rust is probably too hard. I write 100% safe Rust, and there are times when I hit an ownership structure wall and have to spend several days re-planning. So far I've always succeeded without using "unsafe" or indices, but it drags down productivity.

Although object-oriented programming is out of fashion, classes with inheritance are useful. It's really hard to do something comparable in Rust. Traits are not that helpful for this.

Go is a good compromise. Safety at a minor cost in performance. Go is good enough for web back end stuff. Go has both GC and "green threads". This automates the problems that wear people down in C++ and Rust.

[1] https://www.animats.com/papers/languages/cppstrictpointers.h...

Re: Safe C++ proposal is not being continued

#40

Post by 1718627440 »

steveklabnik wrote: post #37
1718627440 wrote: post #31

Earlier quoted context omitted.

> Rust has its uint-thats-not-zero Why do we need to single out a specific value. It would be way better if we also could use uint-without-5-and-42. What I would wish for is type attributes that really belong to the type. typedef unsigned int __attribute__ ((constraint (X != 5 && X != 42))) my_type;

Those are the unstable attributes that your sibling is talking about.

Yeah of course I can put what I want in my toy compiler. My statement was about standard C. I think that's what Contracts really are and hope this will be included in C.
Post reply on HN