On Monday, 23 September 2013 at 07:31:46 UTC, Jacob Carlborg
wrote:
On 2013-09-23 01:49, Andrei Alexandrescu wrote:
I am making good progress on the design of std.allocator, and
I am
optimistic about the way it turns out. D's introspection
capabilities
really shine through, and in places the design does feel really
archetypal - e.g. "this is the essence of a freelist
allocator". It's a
very good feeling. The overall inspiration comes from Berger's
HeapLayers, but D's introspection takes that pattern to a
whole new level.
I agree with Manu here. I thought the whole point was to come
up with a design and API how the allocators are supposed to be
used. How they integrate with user code.
Here's a quick idea:
I can think of at least four different usage patterns how an
allocator can be set. Hopefully this will be backwards
compatible as well.
1. Globally - The same allocator is used in the whole
application by all threads
2. Thread local - The allocator is set per thread. Different
threads can used different allocators
3. Function local - This is the most intrusive. Sets the
allocator for a given function call
4. Block local - The allocator is used during a given block
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.
