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

181–190 of 226 posts

Re: Safe C++ proposal is not being continued

#181

Post by Yoric »

Yoric wrote: post #124
tialaramex wrote: post #26

Earlier quoted context omitted.

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.

I co-implemented this in OCaml ~20 years ago, using no compiler magic (it did use a macro). Pretty sure that I've seen the equivalent in Haskell, too, and in variants of Scheme. Zig has it, too. And while, as you mention, the Rust implementation does use compiler magic, I'm pretty sure that it could be implemented as a macro, just more slowly. etc.

(sorry, it wasn't you who mentioned it, but it was a good remark nevertheless :) )

Re: Safe C++ proposal is not being continued

#182

Post by Yoric »

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…

Dependent types in well-behaved, well-defined snippets of C++ dedicated to numeric kernels?

While I think it's a great idea, this also sounds like it would require fairly major rewrites (and possibly specialized libraries?), which suggests that it would be hard to get much buy-in.

Re: Safe C++ proposal is not being continued

#183

Post by vlovich123 »

Measter wrote: post #153
vlovich123 wrote: post #49

Earlier quoted context omitted.

> So far I've always succeeded without using "unsafe" or indices, but it drags down productivity. I really don’t understand this perspective. The whole philosophy of Rust is one where you document why “unsafe” is safe. It is not and never has been a goal to make everything safe because that is an impossible goal to merge with high performance systems language because hardware itself is unsafe. It’s why the unsafe key…

It can be preferable to avoid unsafe when reasonable to do so. Programmers are merely human and will make a mistake at some point, and by avoiding unsafe you at least get the guarantee that the buggy behaviour is sound and (aside from race conditions) more predictable.

I think you misunderstand me. I’m not saying that unsafe should be the first thing you reach for. But if you can’t find an easy way to express it safely, and the only path visible is a time costly refactor, it can still be the most cost effective approach and shouldn’t be ignored.

Even ignoring the practicality approach, there’s a reason you see it in things like crossbeam or zerocopy - not everything worthwhile expressing can even be expressed in purely safe code wether because of performance or purely because the ownership lifetime cannot be understood due to the limitations of the borrow checker even when it is indeed safe code.

Re: Safe C++ proposal is not being continued

#184

Post by nextaccountic »

Animats wrote: post #39
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 hav…

> Go is a good compromise

Go doesn't prevent data races.. besides the borrow checker, the thing that makes Rust special is the Send and Sync traits

Re: Safe C++ proposal is not being continued

#185

Post by gloryjulio »

IshKebab wrote: post #33
AlotOfReading wrote: post #30

Earlier quoted context omitted.

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.

Like the google people who can't convince them and went on to create carbon?

Re: Safe C++ proposal is not being continued

#186

Post by Voultapher »

drysine wrote: post #145
Voultapher wrote: post #98

Earlier quoted context omitted.

> With program redesigns that Rust requires Why does Rust sometimes require program redesigns? Because these programs are flawed at some fundamental level. D lacks the most important and hardest kind of safety and that is reference safety - curiously C++ profiles also lacks any solution to that problem. A significant amount of production C++ code is riddled with UB and will never be made safe by repainting it and bou…

> Because these programs are flawed at some fundamental level. That's a very strong statement. How do you support it with arguments?

We have strong evidence that anything with 100k+ LoC that uses C or C++ will have use-after-free bugs because of reference semantics. I have no data on D but I wouldn't be surprised if that's the same case there as well. You need to think about ownership and haphazardly treating it as a free-for-all is a fundamental design flaw IMO. Shared mutable state is bad for the same reasons mutable global variables are frowned upon. One needs to keep the sum total of all places and all possible paths leading to them in context for reasoning about any of them. This very very quickly becomes intractable for human minds.

Re: Safe C++ proposal is not being continued

#187

Post by m3047 »

maleldil wrote: post #177
krater23 wrote: post #147

Earlier quoted context omitted.

Sorry man, but I work since 2012 in professional security development in C/C++. Normally no one talks anymore about things like buffer overflows, use after free,... since years. Everyone uses tools to check for this, and in the end it's cheaper than using Rust. The attack vectors we talk about are logic errors and wrong usage of crypto. Things that can happen with Bash, C/C++, Rust and any other language and that you…

> Normally no one talks anymore about things like buffer overflows, use after free,... since years Some of the biggest vulnerabilities of recent years (e.g. Heartbleed) were out-of-bounds access. The most common vulnerability sources are things that are impossible in Rust, but cannot be fully solved via C++ static checkers.

Rust has unsafe, just like Java.

Re: Safe C++ proposal is not being continued

#188

Post by motorest »

AlotOfReading wrote: post #90
shawn_w wrote: post #84

Earlier quoted context omitted.

They could also care about safety but just not like the Rust approach.

This was asked at the aforementioned chat. Andreas Weis (MISRA) responded along the lines of "You shouldn't be writing new code in C++ if you want guarantees". Might not have the identity correct, my notes aren't in front of me.

> (...) "You shouldn't be writing new code in C++ if you want guarantees".

I'm afraid context is required to actually understand what was said. For example, it can mean anything including very obvious things like stating that the committee is still working on proposals to provide guarantees and they won't feature in a standard until the work is done and a new standard is published. Which would be stating the obvious.

Re: Safe C++ proposal is not being continued

#189

Post by motorest »

gloryjulio wrote: post #185
IshKebab wrote: post #33

Earlier quoted context omitted.

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.

Like the google people who can't convince them and went on to create carbon?

> Like the google people who can't convince them and went on to create carbon?

Lots of people in mega-companies set forth to reinvent the wheel. I think we have enough track record to understand that the likes of Google don't walk over water and some of the output is rather questionable and far from the gold standard. Appeals to authority are a logical fallacy for a reason.

Re: Safe C++ proposal is not being continued

#190

Post by motorest »

john_the_writer wrote: post #141
AlotOfReading wrote: post #90

Earlier quoted context omitted.

This was asked at the aforementioned chat. Andreas Weis (MISRA) responded along the lines of "You shouldn't be writing new code in C++ if you want guarantees". Might not have the identity correct, my notes aren't in front of me.

Love this quote. An love the intent.

> Love this quote. An love the intent.

What intent do you think it has? That proposals are still being worked on and haven't been published in a specification yet?

Post reply on HN