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

131–140 of 226 posts

Re: Safe C++ proposal is not being continued

#131

Post by usamoi »

MattDamonSpace wrote: post #85
usamoi wrote: post #58

They are not rejecting Safe C++; they are rejecting memory safety. Majority of them believes that memory safety is just hype, and minority of them knows it's a problem, but doesn't want to restrict themselves about coding. If code runs, it is fine. If it does not, coder running is fine too.

I work on a Swift/iOS app that wraps a C++ library 90+% of our crashes are from hard-to-diagnose cpp crashes. Our engineers are smart and hardworking but they throw their hands up at this. Please tell me my options aren’t limited to “please be better at programming”…?

> Our engineers are smart and hardworking but they throw their hands up at this.

Since you don't think this is a skill issue, shouldn't you support Safe C++, which eliminates unsafety rather than just turning a blind eye to it?

> Please tell me my options aren’t limited to “please be better at programming”…?

You can only use Valgrind/ASan, stress testing, and rewriting in other languages to pay off the technical debt. Even if a god points out every bug in your code, you'd still need to put in great effort to fix them. If you don't pay for it while coding, then you must pay for it after coding. There are no shortcuts.

Re: Safe C++ proposal is not being continued

#132

Post by wolvesechoes »

Voultapher wrote: post #98
WalterBright wrote: post #74

Earlier quoted context omitted.

D adds a lot to memory safety without needing to struggle with program redesigns that Rust requires. These include: 1. bounds checked arrays (you can still use raw pointers instead if you like) 2. default initialization 3. static checks for escaping pointers 4. optional use of pure functions 5. transitive const and immutable qualifiers 6. ranges based on slices rather than pointer pairs

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

> Why does Rust sometimes require program redesigns? Because these programs are flawed at some fundamental level.

Simply not true, and this stance is one of the reasons we have people talking about Rust sect.

Re: Safe C++ proposal is not being continued

#133

Post by akoboldfrying »

Voultapher wrote: post #98
WalterBright wrote: post #74

Earlier quoted context omitted.

D adds a lot to memory safety without needing to struggle with program redesigns that Rust requires. These include: 1. bounds checked arrays (you can still use raw pointers instead if you like) 2. default initialization 3. static checks for escaping pointers 4. optional use of pure functions 5. transitive const and immutable qualifiers 6. ranges based on slices rather than pointer pairs

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

No. Programs that pass borrow checking are a strict subset of programs that are correct with respect to memory allocation; an infinite number of correct programs do not pass it. The borrow checker is a good idea, but it's (necessarily) incomplete.

Your claim is like saying that a program that uses any kind of dynamic memory allocation at all is fundamentally broken.

Re: Safe C++ proposal is not being continued

#134

Post by juliangmp »

I'm unsure a bout the profiles. If they add restrictions and need to be enabled as a compiler flag, no legacy project I'll use them since they'd probably get like 4 errors and say "oh this options breaks my code, but the code has been running for years so its fine".

Re: Safe C++ proposal is not being continued

#135

Post by goku12 »

lelanthran wrote: post #96
zozbot234 wrote: post #67

Earlier quoted context omitted.

> So far I've always succeeded without using "unsafe" or indices, but it drags down productivity. There is a common perception that Rust is less productive than competing languages, but empirical research by Google and others has found this to be wrong. Rust just shifts the effort earlier in the development phase, where the costs are often orders of magnitude lower. You may spend a few hours struggling with the borro…

> Rust just shifts the effort earlier in the development phase, where the costs are often orders of magnitude lower. That works fantastically when you're rewriting something - you already have the idea and final product nailed down. It works poorly when you don't have everything nailed down and might switch a lot of stuff around, or remove stuff that isn't needed, etc.

> It works poorly when you don't have everything nailed down and might switch a lot of stuff around, or remove stuff that isn't needed, etc.

I do prototype applications in Rust and it involves heavy refactoring including deletions. Those steps are the easiest ones for me and rarely gives me any headache. Part of the reason are the interfaces that you're forced to define clearly early on. Even the unrelated friction of satisfying the borrow checker gently nudge you towards that.

The real problems are often caused by certain operations that the type system can't prove to be safe, even when they are. For example, you couldn't write async closures until recently. Such situations often require lots of thought to resolve. You may have to restructure your code or use a workaround like RC variables.

The point is, these sorts of assumptions often don't seem to hold in practice, at least in my experience. My personal experience doesn't agree with the assertion that prototyping is hard in Rust.

Re: Safe C++ proposal is not being continued

#137

Post by versteegen »

murderfs wrote: post #127
pjmlp wrote: post #108

Earlier quoted context omitted.

Spot on, since C++11 the committee has increasingly started to design and add features to the standard without any kind of implementation, only after the standard gets ratified, the implementers eventually find out that the design is broken, or has flaws. A strange phenomenon akin to the Algol 68 days, and no other ISO based language is taking, where standardising existing practice or having a full test implementatio…

The committee got burned, extremely badly, by C++03's export templates, where it got standardized without an implementation, and everyone realized it was basically unimplementable, and the only group that did, wrote a paper telling everyone not to [1] This was well in mind when C++11 came around (especially since C++11 slipped so badly: it was originally "C++0x", and then they ran out of digits for x). By the time we…

Wow, that paper is absolutely damning.

> Design: 1.5 years (elapsed) to come up with a design they believed they could implement.

> Development: 3 person-years (3 people × >1 year each)

> (Note: By comparison, implementing the complete Java language from scratch took the same team 2 person-years.

Re: Safe C++ proposal is not being continued

#138

Post by tialaramex »

pizlonator wrote: post #71
tialaramex wrote: post #68

Earlier quoted context omitted.

Geoff's stuff is mostly about heuristics. For his purpose that makes sense. If Apple are spending say $1Bn on security problems and Geoff spends $1M cutting such problems by 90% that's money well spent. The current direction of profiles is big on heuristics. Easy quick wins to maybe get C++ under the "Radioactively unsafe" radar even if it can't pass for safe. The most hopeful thing I saw in Geoff's talk was cultural…

> Geoff's stuff is mostly about heuristics. That's not true at all. - The bounds safety part of it prevents those C operations that Fil-C or something like it would dynamically check. You can to use hardened API instead. - The cast safety part of it prevents C casts except if they're obviously safe. - The lifetime safety part of it forces you to use WebKit's smart pointers except when you have an overlooking root. Th…

I can't rationalize how "prevents... except" isn't still just heuristics.

r/cpp is full of people with such heuristics, ways that they personally have fewer safety bugs in their software. That's how C++ got its "core guidelines", and it is clearly the foundation of Herb's profiles. You can't get to safety this way, you can get closer than you were in a typical C++ codebase and for Geoff that was important.

Re: Safe C++ proposal is not being continued

#139

Post by vdfs »

juliangmp wrote: post #134

I'm unsure a bout the profiles. If they add restrictions and need to be enabled as a compiler flag, no legacy project I'll use them since they'd probably get like 4 errors and say "oh this options breaks my code, but the code has been running for years so its fine".

Neither will those projects use Safe C++

Re: Safe C++ proposal is not being continued

#140

Post by john_the_writer »

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.

I don't know that they don't care about safety. They just don't agree with the definition others have picked. I remember when managed code became a thing. I being an old c++ dev noted that memory was always managed. It was managed by me.
Post reply on HN