On Sunday, 22 September 2013 at 23:49:56 UTC, Andrei Alexandrescu
wrote:
1. Typed allocator, i.e. every request for allocation comes
with the exact type requested;
2. Untyped allocator - traffics exclusively in ubyte[].
This is a good design.
Perhaps this is a later concern, but we should make sure that
node-based containers (e.g. linked list, trees) have a way to
access the allocation size needed for the node. STL did not do
this.
* alignment is a compile-time constant yielding the alignment
of allocated data. Many allocators offer the maximum alignment
of the platform (for which I used real.alignof above). This
constant is required for all allocators.
What if, for example, I wanted to allocate a 4096 byte aligned
block from the GC allocator? Do I have to create a new allocator
backed by the GC allocator?
What if the alignment is not known at compile time (e.g. hard
disk page size or CPU cache line size)?
Might be better to pass the desired alignment in the allocate
method.
* available is a property that returns how many total (not
necessarily contiguous) bytes are available for allocation. The
NullAllocator knows statically it has 0 bytes available so it
implements it as an enum. Generally allocators will implement
it as a @property. This property is optional.
It would be useful to know the maximum available contiguous block
size too, so that you can find out if an allocation will succeed
without calling allocate. It's also useful for diagnosing
fragmentation issues e.g. "allocation failed, free memory = X,
max contiguous = Y". If X is high and Y is low then you are
highly fragmented.
Of course, this should be optional.
* allocate(s) returns a ubyte[] with length at least s, or
null. (It does not throw on out-of-memory because that would
hurt composability; it turns out many elemental allocators do
naturally run out of memory.) This method is required for all
allocators. In most allocators this method should be @safe.
What are the semantics of allocate(0)? malloc(0) is
implementation defined.
