On 23 September 2013 23:38, Jacob Carlborg <[email protected]> wrote: > On 2013-09-23 11:31, qznc wrote: > > 5. Class local - The allocator is used for specific types (e.g. ASTNode >> in a compiler) >> >> 6. Class-hierarchy - The allocator is used for a specific type hierarchy >> (e.g. ASTNode might have sub classes Statement,BinOp,etc) >> >> 7. Container local - The C++ way which binds allocation to a wrapping >> container >> >> 8. Task local - like Thread local but for std.parallelism.Task >> >> That's it for now. >> >> This is quite a long list, which means it is probably exhaustive. There >> should be a generic approach which encompasses at least those cases. >> > > That's a good addition to the list.
Another situation that I've encountered on a few occasions... Imagine I declare a particular allocator for my application, when dealing with 3rd party libs, I expect it to allocate within my application's heap. Seems like a situation where I might set a global allocator... Mr 3rd party library also has its own allocators though, things like pools or groups which it uses explicitly within it's code. I don't actually want to override these allocators, since they're effectively a higher-level construct, but I *do* want to override these allocator's memory source. Ie, they should allocate their pools from my application's heap, rather than the default heap. So in this way, it's important to be able to set overrides at multiple levels.
