Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Moving containers with their memory pools #97

Open
burnpanck opened this issue Dec 25, 2020 · 1 comment
Open

Moving containers with their memory pools #97

burnpanck opened this issue Dec 25, 2020 · 1 comment

Comments

@burnpanck
Copy link
Contributor

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?

@foonathan
Copy link
Owner

Yeah, that's unfortunate.

As a quick workaround, you can heap allocate the pool itself. I'll see what I can do in the library side, but it doesn't look good.

Repository owner deleted a comment from zzk666666 May 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants