This is more of a question than an issue, and potentially a feature request.
I have a class managing a kind of a graph data structure, where standard containers (maps and lists) are used to store relationships between the graph elements, and a foonathan/memory is used with a memory_pool to avoid allocation overhead.
The managing class "owns" the tree and is therefore also holding the memory_pools. I have naively assumed that a defaulted move constructor would "do the right thing (TM)", but it leads to nasty segmentation faults. As far as I can tell, the move constructor for the pool moves the ownership of the memory as expected, and the move constructor for the containers do transfer ownership of the nodes within the moved memory correctly too. However, the moved stl_allocator will keep a pointer to the original memory_pool object, which does not own the memory of the nodes anymore.
Is there a way to make this work, perhaps with an explicit update of the std_allocator (unlikely, not designed for in the STL), or potentially with a different allocator?
This is more of a question than an issue, and potentially a feature request.
I have a class managing a kind of a graph data structure, where standard containers (maps and lists) are used to store relationships between the graph elements, and a
foonathan/memory
is used with amemory_pool
to avoid allocation overhead.The managing class "owns" the tree and is therefore also holding the
memory_pools
. I have naively assumed that a defaulted move constructor would "do the right thing (TM)", but it leads to nasty segmentation faults. As far as I can tell, the move constructor for the pool moves the ownership of the memory as expected, and the move constructor for the containers do transfer ownership of the nodes within the moved memory correctly too. However, the movedstl_allocator
will keep a pointer to the originalmemory_pool
object, which does not own the memory of the nodes anymore.Is there a way to make this work, perhaps with an explicit update of the
std_allocator
(unlikely, not designed for in the STL), or potentially with a different allocator?