Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making C++ safe without borrow checking, reference counting, or tracing GC

verdagon.dev

Post reply on HN
Print view View original

1–10 of 226 posts

Re: Making C++ safe without borrow checking, reference counting, or tracing GC

#2

Post by gavinray »

See also:

Thomas Neumann's current proposal for memory safe C++ using dependency tracking:

- https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27...

Google's proposal for memory safety using Rust-like lifetime analysis:

- https://discourse.llvm.org/t/rfc-lifetime-annotations-for-c/...

- https://github.com/google/crubit/tree/main/lifetime_analysis

Re: Making C++ safe without borrow checking, reference counting, or tracing GC

#6

Post by pjmlp »

gavinray wrote: post #2

See also: Thomas Neumann's current proposal for memory safe C++ using dependency tracking: - https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27... Google's proposal for memory safety using Rust-like lifetime analysis: - https://discourse.llvm.org/t/rfc-lifetime-annotations-for-c/... - https://github.com/google/crubit/tree/main/lifetime_analysis

And Microsoft' work on Visual C++ lifetime checker and SAL, as well.

It will never be perfect, but every little improvement helps.

Re: Making C++ safe without borrow checking, reference counting, or tracing GC

#8

Post by derefr »

pjmlp wrote: post #7
kubb wrote: post #4

it's not about making C++ memory safe, but about describing a safe subset of C++

Ideally we would have -fsafe and [[unsafe]], but it will take years for something like that.

Presuming syntax for “unsafe” that gracefully degrades in non-aware compilers, why couldn’t a particular compiler start doing it right now, starting with a very trivial safety checker than can be iteratively improved upon once the framework is in place?

Re: Making C++ safe without borrow checking, reference counting, or tracing GC

#9

Post by Voultapher »

> Tracing GC is the simplest model for the user, and helps with time management and development velocity, two very important aspects of software engineering.

> Borrow checking is very fast, and helps avoid data races.

One thing many people seem to assume is that not having to care about memory means you can program faster and get to your goal faster. As the author here seems to do. However as it turns out, if your program is more complex than a ~100-1000 lines of code, explaining in a explicit way who owns what and who gets to change state when, is a very useful way to avoid bugs.

Saoirse Shipwreckt aka withoutboats mentioned this a while ago in https://without.boats/hire-me/

> Rust works because it enables users to write in an imperative programming style, which is the mainstream style of programming that most users are familiar with, while avoiding to an impressive degree the kinds of bugs that imperative programming is notorious for. As I said once, pure functional programming is an ingenious trick to show you can code without mutation, but Rust is an even cleverer trick to show you can just have mutation.

and later follows up on this in https://without.boats/blog/revisiting-a-smaller-rust/

> I still think this is Rust’s “secret sauce” and it does mean what I said: the language would have to have ownership and borrowing. But what I’ve realized since is that there’s a very important distinction between the cases in which users want these semantics and the cases where they largely get in the way. This distinction is between types which represent resources and types which represent data.

Post reply on HN