News for hackers. Stuff that matters.
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.