3 ms·
Exactly. Stateful allocators were added to the standard library especially for this sort of problem. Before, allocators were assumed to have no internal state,
by humanrebar 11y ago
Exactly. Stateful allocators were added to the standard library especially for this sort of problem. Before, allocators were assumed to have no internal state, which made it problematic to manage memory from an arena or pool.
Perhaps there's a reason allocators wouldn't work here, but if so, it deserves a little discussion.
- quicknir 11y agoI did discuss stateful allocators. They're nice, I'm a big fan. But as I said, they would impose pointless space overhead of one extra pointer per array. Also, you now have more complicated issues: each of the arrays is now an owner. What if you try to make a copy of it? Move construction? What if the container tries to deallocate, how does our allocator handle that? When I copy Mesh, would I need to change the allocator's state in the copies? How would that even work? I think that once you think about trying to accomplish the very specific and relatively simple thing being done here with allocators, you'll see that it would be quite a bit more complexity to no benefit. I think I did give it a "little" discussion :-). Guess it depends on your definition of a little. I didn't want to talk more about it because I didn't want to get sidetracked, and this is ultimately the way I chose to do it. Hope that sheds some light on the post and the choices I made with it.