Re:Speculations on arenas and non-trivial destructors
by Panzerschrek on Thursday October 23, 2025 @03:46AM
(#45679301)
This approach for arena-allocated objects destruction seems for me to be a little bit unusual. Why not creating wrapper classes similar to unique_ptr o vector, which allocate memory from an arena instance and call destructors of stored objects upon their destruction?
[ Parent
| on HN ]
Re:Speculations on arenas and non-trivial destructors
by lieks on Thursday October 23, 2025 @07:36AM
(#45680673)
Because the whole goal is to not need any sort of "pointer discipline". The way he does it, you can store as many pointers to the arena as you want without keeping track of them, as long as they don't survive the deallocation of the arena.
One example would be having a big graph inside the arena. Pointers to other elements can just be plain pointers.
With "conventional RAII" you need to know if your pointer is the only pointer left to know whether to call the destructor. That requires some sort of pointer tracking.
Re:Speculations on arenas and non-trivial destructors
by Panzerschrek on Thursday October 23, 2025 @08:17AM
(#45680983)
Now I understand. The approach described in the article above allows shared semantics (not only unique owner like with unique_ptr and vector) with little overhead. But some overhead is still present - destructors are called via indirection and thus can't be inlined.
Re:Speculations on arenas and non-trivial destructors
by menaerus on Thursday October 23, 2025 @12:07PM
(#45683505)
> With "conventional RAII" you need to know if your pointer is the only pointer left to know whether to call the destructor. That requires some sort of pointer tracking.
That's not really conventional in terms of RAII - this is called a shared-ptr what you're describing. In "conventional RAII" there is no pointer tracking, RAII serves the purpose of releasing the resource what that is - it doesn't have to be anything, and most of the time it isn't since many classes aren't resource classes anyway.