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

short_alloc behavior upon calling clear() #11

Open
milad-khaledyan opened this issue Apr 3, 2024 · 1 comment
Open

short_alloc behavior upon calling clear() #11

milad-khaledyan opened this issue Apr 3, 2024 · 1 comment

Comments

@milad-khaledyan
Copy link

Hi Howard, thanks for the great implementation of short_alloc. I tried to use it for std::list or std::set, and am running into an issue where the behavior of underline container is different when using the short_alloc. So if I call clear() on a std::list which uses short_alloc, it only deallocates the last element in the buffer. But in standard std::list with the default allocator, it deallocates/releases all memory. I imagine same behavior is expected when calling clear() for the short_alloc (e.g., resetting the arena). So, let's say I have a capacity of 10 element in std::list with short_alloc. I push 10 elements and all goes on stack. When I call clear, I expect the arena deallocate all these 10 elements and if I push back 10 more elements, no overflow should happen, but with the current implementation, this is not happening and only the last element in arena is reset. Any idea on how to add this capability? A similar behavior happens when calling erase.

P.S., I looked at clear() implementation of std::list and it tries to get a copy of the allocator and calls deallocate on all elements. But it seems like when the allocator is short_alloc, the loop covers only last element's removal.

@HowardHinnant
Copy link
Owner

Hi. short_alloc is really just a demo. arena<N, alignment>::deallocate has been optimized for stack-order deallocation. You can make that arbitrarily more complex (and expensive) to suit whatever your application needs. If you make it sufficiently general purpose, you will have re-implemented malloc/free, and will have likely lost any benefit of a custom allocator.

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