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

141–150 of 226 posts

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

#141

Post by cmrdporcupine »

jcranmer wrote: post #117
cmrdporcupine wrote: post #87

Earlier quoted context omitted.

missing data structure helper -- didn't you already just name-check that though, since that's basically RefCell .. or if you're willing to roll the dice... UnsafeCell (aka "trust me I know what I'm doing")?

What you essentially want for the user to not write any unsafe code is this kind of interface: trait Allocator { fn allocate (&'a self, init: T) -> Handle ; fn deallocate (&'a self, handle: Handle ); fn read (&self, handle: Handle ) -> impl Deref ; fn write (&self, handle: Handle ) -> impl DerefMut ; } &'a RefCell is pretty close to a definition of Handle , except that Rust provides no implementations of allocate and…

Did you get a look at https://github.com/rust-lang/rfcs/pull/3446 at all?

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

#142

Post by School-Cotton »

mr_00ff00 wrote: post #107
dralley wrote: post #91

Earlier quoted context omitted.

> Slotmap uses unsafe everywhere, it's a memory usage pattern not supported by the borrow checker. Is disabling the borrow checker really a common pattern in Rust? Wrapping "unsafe" code in a safe interface is a common pattern in Rust, yes. There is absolutely nothing wrong with using "unsafe" so long as you are diligent about checking invariants, and keep it contained as much as possible. Obviously the standard libr…

If unsafe means “safe but the compiler cannot verify” then I guess just consider .cpp to mean “safe but the compiler cannot verify” and we have suddenly made C++ memory safe

The core value proposition of rust is that it’s memory safe by default, and it’s possible to limit the set of code that needs to be manually checked for UB. This isn’t the case for C++, as any code anywhere can invoke undefined behavior.

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

#143

Post by School-Cotton »

snek_case wrote: post #28
convolvatron wrote: post #24

Earlier quoted context omitted.

I really love parts of rust and kinda hate other parts. but this is what really ruins it for me. I want to play. I want to knock something together and work with it and see what kind of shape it is. rust demands that I cross every last t before I can run it at all. which is great if you already have a crystal notion of what you are building

> rust demands that I cross every last t before I can run it at all. It's worse than that IMO. Rust makes it very awkward/impractical to have cyclic data structures, which are necessary to write a lot of useful programs. The Rust fans will quickly jump in and tell you that if you need cycles, your program is wrong and you're just not a good enough programmer, but Maybe it's just that the Rust borrow checker is too li…

> The Rust fans will quickly jump in and tell you that if you need cycles, your program is wrong and you're just not a good enough programmer

I have absolutely never heard a Rust fan say this. AFAICT the fact that cyclic data structures are hard to write is widely accepted within the community as one of the negative tradeoffs of the language.

If you’re talking to people who claim that any language is better than all others in every possible way, for every possible use case, then they are zealots whose opinion can be ignored.

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

#144

Post by SubjectToChange »

oleganza wrote: post #108

The reason I use Rust is because I can bypass all this messy business altogether and have my sensible patterns wrapped in a usable syntax and enforced by the compiler out of the box. Whenever people say "just follow these rules" I read "just add this extra mental burden and do not slip up". Computers were invented to automate things. Rust automates ownership and borrowing rules. Suggestions like "do not forget to ini…

Keep in mind that a lot of C++ users really didn’t have a choice, it was either C or C++ for a lot of applications. In fact C++ is often still the only option, with some segments (like HPC) doubling down on their investments in the language.

So how do we serve those users? Rust doesn’t give them a path forward. Simply getting C++ compilers to agree is difficult enough, much less an entirely different language.

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

#145

Post by verdagon »

azakai wrote: post #5

There is also Type-After-Type: https://dl.acm.org/doi/10.1145/3274694.3274705 (though maybe that's covered by what the author meant by "arenas").

This is one of the other three secret blends that I think could bring memory safety to C++!

I wrote a bit about using type-after-type as the basis for an entire language (Arrrlang, with a parrot mascot) in my last article [0] and a little bit in a post about memory safety for unsafe languages [1] which we eventually talked about at Handmade Seattle.

The downside is the extra memory usage, but I think we can combine it with temporary regions [2] to reduce it pretty drastically.

TIL the phrase type-after-type! I've also heard it referred to as type stability. [3] [4] If you squint, this is what we often do manually with Rust when the borrow checker influences us to use indices/IDs into central collections.

[0] https://verdagon.dev/blog/myth-zero-overhead-memory-safety

[1] https://verdagon.dev/blog/when-to-use-memory-safe-part-1#the...

[2] https://verdagon.dev/blog/zero-cost-borrowing-regions-overvi...

[3] https://www.usenix.org/legacy/publications/library/proceedin...

[4] https://engineering.backtrace.io/2021-08-04-slitter-a-slab-a...

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

#146

Post by verdagon »

kubb wrote: post #4

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

I'm not sure if there's really any alternative besides using a subset, for a low-level language. Even Rust is only memory-safe within a certain subset.

Edit: Actually nevermind! CHERI is a hardware technique that can make C++ memory safe without using only a subset of the language.

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

#147

Post by jcranmer »

nyanpasu64 wrote: post #132
jcranmer wrote: post #117

Earlier quoted context omitted.

What you essentially want for the user to not write any unsafe code is this kind of interface: trait Allocator { fn allocate (&'a self, init: T) -> Handle ; fn deallocate (&'a self, handle: Handle ); fn read (&self, handle: Handle ) -> impl Deref ; fn write (&self, handle: Handle ) -> impl DerefMut ; } &'a RefCell is pretty close to a definition of Handle , except that Rust provides no implementations of allocate and…

Can you clone a Handle? If so, how do you handle using a clone after freeing it? If clones are refcounted, how do you handle cycles?

There are several different ways you can implement a Handle, depending on what features you want; the most important part of its implementation is that `fn is_valid(handle: Handle) -> bool` is possible. The simplest implementation is a (pointer, generation) pair, which can be packed into a u64 pretty easily even for 64-bit systems; every allocation and deallocation increments the generation counter in the allocator, and is_valid is thus implemented by checking if the allocator's generation matches the claimed generation for a Handle. This kind of Handle is effectively a Copy implementation (not merely Clone!).

Effectively, handles are like weak pointers in that you can detect when the underlying object has been freed, but unlike weak pointers, there's no need for a reference counter to know when to deallocate the object--the object is freed when the allocator itself dies, or it can manually be freed earlier. It is possible to write code that will attempt to use the freed object, and the compiler will be happy, but the runtime will detect that it has been freed and panic instead. (RefCell does something similar, except it only detects violations of multiple readers xor one writer requirement, not overall lifteime). You can also add other wrappers around Handles to automatically free those Handles on scope exit, but the point is you can now have multiple references to an object that can be upgraded to a mutable reference if you desire.

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

#148

Post by jcranmer »

cmrdporcupine wrote: post #141
jcranmer wrote: post #117

Earlier quoted context omitted.

What you essentially want for the user to not write any unsafe code is this kind of interface: trait Allocator { fn allocate (&'a self, init: T) -> Handle ; fn deallocate (&'a self, handle: Handle ); fn read (&self, handle: Handle ) -> impl Deref ; fn write (&self, handle: Handle ) -> impl DerefMut ; } &'a RefCell is pretty close to a definition of Handle , except that Rust provides no implementations of allocate and…

Did you get a look at https://github.com/rust-lang/rfcs/pull/3446 at all?

I'm not in the habit of regularly following new Rust RFCs, so I'd have no way of knowing about something made just last week. :-) But I'm taking a look now.

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

#149

Post by verdagon »

ajross wrote: post #19
coliveira wrote: post #12

The reason why safety in C++ is difficult to achieve is due to the memory model used by C and C++. The memory model is a flat space provided by the OS that can be addressed by pointers. In this sense, C++ is similar to assembly code. A language like Java, on the other hand, assumes a different model where you can only access objects with well defined behavior. To change this, one needs to disallow the use of native p…

That's pretty much what the article says though. "Don't use traditional pointers" is a fairly trivial rule to enforce via static analysis, and constructs like unique_ptr are syntactically identical anyway. The bit that has me confused is that it's inventing a new term, "borrowing affine style", to describe a longstanding paradigm that has traditionally been called "RAII". Now, neither term is very clear, but surely i…

I'm not sure this has much to do with RAII. RAII does indeed require affine types, but RAII doesn't provide memory safety. The article describes a method of memory safety.

(Also, I used the term "borrowless affine style" mostly because people might hear the term "affine style" and assume I'm talking about Rust, since that's what most people know.)

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

#150

Post by verdagon »

oleganza wrote: post #108

The reason I use Rust is because I can bypass all this messy business altogether and have my sensible patterns wrapped in a usable syntax and enforced by the compiler out of the box. Whenever people say "just follow these rules" I read "just add this extra mental burden and do not slip up". Computers were invented to automate things. Rust automates ownership and borrowing rules. Suggestions like "do not forget to ini…

I'd definitely agree, and the article proposes a static analysis tool (similar to the borrow checker) for that purpose.
Post reply on HN