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

91–100 of 226 posts

Re: Safe C++ proposal is not being continued

#91

Post by int_19h »

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…

> You need something more sophisticated than using smart pointers for everything. In the limit, smart pointers for everything is just called "Python".

I don't see how that follows at all. What makes Python Python (and slow!) is dynamic dispatch everywhere down to the most primitive things. Refcounted smart pointers are a very minor thing in the big picture, which is why we've seen Python implementations without them (Jython, IronPython). Performance-wise, yes, refcounting certainly isn't cheap, but you just do that and keep everything else C++-like, the overall performance profile of such a language is still much closer to C++ than to something like Python.

You can also have refcounting + something like `ref` types in modern C# (which are essentially restricted-lifetime zero-overhead pointers with inferred or very simplistic lifetimes):

https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

It doesn't cover all the cases that a full-fledged borrow checked with explicit lifetime annotations can, but it does cover quite a few; perhaps enough to adopt the position that refcounting is "good enough" for the rest.

Re: Safe C++ proposal is not being continued

#92

Post by int_19h »

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;

Proper union types would get you there. If you have them, then each specific integer constant is basically its own type, and e.g. uint8 is just (0|1|2|...|255). So long as your type algebra has an operator that excludes one of the variants from the union to produce a new one, it's trivial to exclude whatever, and it's still easy for the compiler to reason about such types and to provide syntactic sugar for them like 0..255 etc.

Re: Safe C++ proposal is not being continued

#94

Post by Animats »

vlovich123 wrote: post #49
Animats wrote: post #39

Earlier quoted context omitted.

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…

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

I just start everything with

    #![forbid(unsafe_code)]

Re: Safe C++ proposal is not being continued

#95

Post by MForster »

lallysingh wrote: post #93

Call me stupid for asking, but what is "safe" here? I get the length-checked buffer copies and accesses, is there anything else? Less allowed type conversions?

You are talking about spatial safety. There are a few other types of memory safety:

- temporal safety (e.g. no use after free) - initialization safety (no read of initialized memory) - thread safety (no data races) - type safety (accessing memory with the correct type)

Re: Safe C++ proposal is not being continued

#96

Post by lelanthran »

zozbot234 wrote: post #67
Animats wrote: post #39

Earlier quoted context omitted.

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…

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

Re: Safe C++ proposal is not being continued

#97

Post by Panzerschrek »

The mentioned proposal isn't really that great. It basically tries to make C++ to Rust by blindly copying many its ideas. Many of them aren't strictly necessary to achieve safety in C++. There are different proposals for safety, which are way smaller and simpler than this one.

Re: Safe C++ proposal is not being continued

#98

Post by Voultapher »

WalterBright wrote: post #74
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.

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

Claiming that not being forced to fix something fundamentally broken is an advantage when talking about safety doesn't make you look like a particularly serious advocate for the topic.

Re: Safe C++ proposal is not being continued

#99

Post by Voultapher »

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…

I came to the same conclusion in a talk I gave to the Munich C++ Meetup [1]. There is a prevalent culture of expecting users to not make mistakes. Library constructs that could be significantly safer-to-use are kept easy-to-use incorrectly, usually with the argument of performance. The irony is that if you look closer, the performance optimization that was done is removing the seatbelts from a small hatchback to safe on weight.

[1] https://youtu.be/rZ7QQWKP8Rk or text form https://github.com/Voultapher/Presentations/blob/main/safety...

Re: Safe C++ proposal is not being continued

#100

Post by WalterBright »

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.

I'm familiar with borrow checkers, as I wrote one for D.

Not following the rules of the borrow checker does not mean the program is flawed or incorrect. It just means the borrow checker is unable to prove it correct.

> D lacks the most important and hardest kind of safety and that is reference safety

I look at compilations of programming safety errors in shipped code now and then. Far and away the #1 bug is out-of-bounds array access. D has solved that problem.

BTW, if you use the optional GC in D, the program will be memory safe. No borrow checker needed.

Post reply on HN