They don't play nicely with arena allocators. And arenas is what you reach for if you have clear lifetime bounds: e.g. a single request with arena never de-allocates individual objects, nukes arena when done. That gives you an easy verifiable protection against leaks, data (and cache) locality and deallocation that cost zero cpu cycles.
Have a boxed object have implemented drop, then when the box leaves some scope the Box will clean up it's stuff (drop implementation if there is any) and deallocate it's memory using the allocator (which the arena will treat as noop).
It's technically possible to perform arena-based allocation and still have compiler checks. The compiler just need to track objects allocated with an allocator and prevent destructing the allocator itself as long as there is at least one object using it.
It's like view span objects in rust. The compiler knowns that a span is logically connected to the parent object and don't allow destroying it when such span exists.
Rust supports arena allocator <a href="https://docs.rs/bumpalo/latest/bumpalo/" rel="nofollow">https://docs.rs/bumpalo/latest/bumpalo/ and the dropping plays well with arena as long as you use bumpalo::boxed::Box
Panzerschrek · · focus · HN ↗
That's why having no auto-destructors is a dead-end. This is the greatest mistake of such languages like Zig or Odin.
delamon · · focus · HN ↗
tcfhgj · · focus · HN ↗
Have a boxed object have implemented drop, then when the box leaves some scope the Box will clean up it's stuff (drop implementation if there is any) and deallocate it's memory using the allocator (which the arena will treat as noop).
delamon · · focus · HN ↗
tcfhgj · · focus · HN ↗
delamon · · focus · HN ↗
tcfhgj · · focus · HN ↗
Panzerschrek · · focus · HN ↗
It's like view span objects in rust. The compiler knowns that a span is logically connected to the parent object and don't allow destroying it when such span exists.
delifue · · focus · HN ↗