This reads like cope because you're re-inventing RAII from first principles.

I cannot take this seriously as tutorials on robust Zig Allocation Pools will store a deinit method for each item within the pool, so when the pool deinits, all internal objects can be deinit'd.

That is just RAII & dtors from first principles, except with extra overhead of manually storing fat pointers yourself (and the bugs that come with this). Instead of using a language with builtin guarantees & optimizations around handling this so your object pools don't need to carry around a bunch of function pointers. C++ has aggressive de-virtualization passes so at runtime a lot of the 'complex object hierarchies' can be flattened to purely static function calls.

▲

MintPaw 14 hours ago | parent | next [-]

This is a general problem with destructors, you can't "batch delete" objects. To free a lot of stuff you're required to go pointer by pointer through the tree to clean up each object. To get real performance gains from pools you can't have per-object/subobject custom cleanup code.

	▲	aabhay 12 hours ago \| parent [-]
		Not necessarily. Drop semantics are just syntactic sugar, and can thus be aggressively inlined or auto vectorized by the compiler.

▲

jstimpfle a day ago | parent | prev [-]

I've argued elsewhere some things that are wrong with RAII and C++ objects in general.

Here I would just like to mention that if you have to rely on "de-virtualization" passes, you're in a miserable situation architecturally. If you have code where the overhead of virtual function calls might be too much to pay, don't do virtual functions then. End of story.

To deconstruct a pool of objects, I don't see what should ever be wrong with a function pointer. The overhead of loading the function pointer will get divided by the number of objects being deconstructed. Care to explain what's the issue here?

▲

hugmynutus a day ago | parent [-]

> I don't see what should ever be wrong with a function pointer. [...]Care to explain what's the issue here?

1. You're writing code you don't have to

2. That adds runtime overhead

3. That when you screw up has non-trivial security & resource management side effects

This is objectively indefeasible in nearly any vaguely professional context.

▲

jstimpfle 20 hours ago | parent [-]

1. No, you're not writing code you don't have to. It's not different to implementing this as non-virtual methods, in fact I'd argue doing simple functions is more straightforward.

2. And the code being compiled is abstract & generic, it won't be instantiated for every type and bloat the executable or instruction cache.

3. Security concerns: With C++ virtual methods every object carries a mutable pointer too (to a vtable containing function pointers). What resource management side effects please?

▲

kllrnohj 15 hours ago | parent [-]

Re #3: vtable pointers aren't mutable...?

▲

jstimpfle 11 hours ago | parent [-]

Of course they are. The pointers to the vtable are part of the object. They aren't mutable fields as per the language, but for security concerns it doesn't matter what the language thinks. Being part of the object, the vtable pointer has to live in a writeable memory mapping (like stack / heap).

▲

Conscat 8 hours ago | parent | next [-]

Clang pointer authentication makes any type of vtable attack impossible in C++.

	▲	jstimpfle 7 hours ago \| parent [-]
		Fair enough, this is an extension though and I suppose you could use it with manually constructed vtables as well?

▲

kllrnohj 6 hours ago | parent | prev [-]

Then I don't understand your argument. If you're just saying what could go wrong with heap corruption, then your vtable complaint also applies to storing function pointers in arena allocators in Zig? Zig doesn't have anything special here?

	▲	jstimpfle 3 hours ago \| parent [-]
		I asked you what's wrong with pool destructor function pointers. You gave a reason what's wrong and I refuted it. So no, I'm not saying that storing a function pointer is special, just that nothing's wrong with it. (And implying that since there's nothing wrong and it's probably the most straightforward thing to do, it's also probably the right thing).