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

11–20 of 226 posts

Re: Safe C++ proposal is not being continued

#11

Post by quotemstr »

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?

That's what the "Profiles" feature is. The problem is that any nontrivial real world program in a non-GC language needs non-owning reference types to perform well, and you can't express the rules for safe use of non-owning references without augmenting the language. People have tried. You need something more sophisticated than using smart pointers for everything. In the limit, smart pointers for everything is just called "Python".

What infuriates me about the C++ safety situation is that C++ is by and large a better, more expressive language than Rust is, particularly with respect to compile time type level metaprogramming. And I am being walked hands handcuffed behind my back, alongside everyone else, into the Rust world with its comparatively anemic proc macro shit because the C++ committee can't be bothered to care about memory safety.

Because of the C++ standards committee's misfeasance, I'm going to have to live in a world where I don't get to use some of my favorite programming techniques.

Re: Safe C++ proposal is not being continued

#12

Post by recursivecaveat »

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?

I don't think that really accomplishes anything. If you interpret it broadly enough to meaningfully improve safety you have to ban so much stuff that no codebase will ever turn it on. It's a pretty straightforward locally-verifiable property as well, so people who really want it don't need a pragma to enforce it.

Re: Safe C++ proposal is not being continued

#13

Post by favorited »

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(); }
unless it's a trivial inlined function, like a simple getter.

[0]https://www.youtube.com/watch?v=RLw13wLM5Ko

Re: Safe C++ proposal is not being continued

#14

Post by quotemstr »

int_19h wrote: post #9
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,…

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 someone to fork both C++ and Clang and make something that's actually a good synthesis of the old and the new.

But yeah, the most likely future is one on which C++ goes the way of Fortran (which still gets regular updates, however irrelevant) and the energy goes into Rust. But I like to rage, rage, against the dying of the type based metaprogramming.

Re: Safe C++ proposal is not being continued

#15

Post by favorited »

int_19h wrote: post #9
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,…

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.

The browser companies weren't just onboard with WHATWG – they literally are WHATWG. The WHATWG steering committee is Apple, Google, Microsoft, and Mozilla.

Re: Safe C++ proposal is not being continued

#16

Post by Yoric »

quotemstr wrote: post #11
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?

That's what the "Profiles" feature is. The problem is that any nontrivial real world program in a non-GC language needs non-owning reference types to perform well, and you can't express the rules for safe use of non-owning references without augmenting the language. People have tried. You need something more sophisticated than using smart pointers for everything. In the limit, smart pointers for everything is just ca…

> In the limit, smart pointers for everything is just called "Python".

To be more precise, it's old Python. Recent versions of Python use a gc.

> And I am being walked hands handcuffed behind my back, alongside everyone else, into the Rust world with its comparatively anemic proc macro shit because the C++ committee can't be bothered to care about memory safety.

Out of curiosity (as someone working on static analysis), what properties would you like your compiler to check?

Re: Safe C++ proposal is not being continued

#17

Post by quotemstr »

Yoric wrote: post #16
quotemstr wrote: post #11

Earlier quoted context omitted.

That's what the "Profiles" feature is. The problem is that any nontrivial real world program in a non-GC language needs non-owning reference types to perform well, and you can't express the rules for safe use of non-owning references without augmenting the language. People have tried. You need something more sophisticated than using smart pointers for everything. In the limit, smart pointers for everything is just ca…

> In the limit, smart pointers for everything is just called "Python". To be more precise, it's old Python. Recent versions of Python use a gc. > And I am being walked hands handcuffed behind my back, alongside everyone else, into the Rust world with its comparatively anemic proc macro shit because the C++ committee can't be bothered to care about memory safety. Out of curiosity (as someone working on static analysis…

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 reference safety but also sign comparison restriction, maximum buffer sizes, and so on.

Re: Safe C++ proposal is not being continued

#18

Post by tialaramex »

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 minute bagpipe dirge your lead single it doesn't really matter whether you use the colored vinyl.

Re: Safe C++ proposal is not being continued

#19

Post by zevets »

quotemstr wrote: post #17
Yoric wrote: post #16

Earlier quoted context omitted.

> In the limit, smart pointers for everything is just called "Python". To be more precise, it's old Python. Recent versions of Python use a gc. > And I am being walked hands handcuffed behind my back, alongside everyone else, into the Rust world with its comparatively anemic proc macro shit because the C++ committee can't be bothered to care about memory safety. Out of curiosity (as someone working on static analysis…

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

Re: Safe C++ proposal is not being continued

#20

Post by tialaramex »

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…

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 things which have been achieved in C++ like fmt, a compile time checked, userspace library for arbitrarily formatting variadic generic parameters. That's like man on the moon stuff, genuinely impressive. Mostly though C++ is a garbage fire and so while it's important to learn about it and from it we should not keep doing that.

Post reply on HN