[lieks]

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.

[menaerus]

> 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.

[Panzerschrek]

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.