std.allocator needs your help

[Dan Schatzberg]

On Tuesday, 24 September 2013 at 17:38:34 UTC, Dan Schatzberg 
wrote:
> What is your objective though? Aren't you trying to define a 
> hierarchy of allocators where more specific allocators can be 
> composed from general ones? In which case what is the concern 
> with including locality at the base level? It seems to be one 
> characteristic of memory that programmers might be concerned 
> with and rather trivially you can compose a non-locality aware 
> allocator from a locality aware allocator.

I'll elaborate on this point a bit just to make sure I'm clear. I 
understand your initial post here to be asking if the allocator 
interface you designed is comprehensive enough that all other 
allocators (within reason) could be constructed from it.

Whether or not it is inefficient to pass alignment, or locality 
domain arguments to an allocate call seems orthogonal to whether 
or not one can construct an allocator which does not take such 
arguments from one that does. As I'm sure your original design is 
intended for, one can imagine allocators which have a fixed size 
(constructed from the original allocator you proposed). The 
allocate path can then very efficiently hand off memory from a 
free-list or some other efficient structure. One can make 
analogous allocators that do not allow for dynamic alignment or 
NUMA locality.

The only reasonable argument against seems to be whether or not 
the flexibility is worth the semantic overhead of a larger 
hierarchy which is a completely reasonable and subjective 
argument to be had.