std.allocator ready for some abuse

[safety0ff]

On Friday, 1 November 2013 at 02:43:00 UTC, Andrei Alexandrescu 
wrote:
> On 10/31/13 7:26 PM, safety0ff wrote:
>> I noticed that the GCAllocator provides no way of controlling 
>> the memory
>> block attributes 
>> (http://dlang.org/phobos/core_memory.html#.GC.BlkAttr
>> ,) all allocations get the default (no attributes.) This is a 
>> leaky
>> abstraction, a data structure or composed allocators may 
>> desire to
>> control the attributes to reduce GC pressure.
>
> These attributes seem to be informed by the types stored, which 
> would be above the charter of untyped allocator.
>
> Andrei

The attributes are informed by whatever code is calling the GC, 
the GC interface deals in void*'s.

Consider an AA implementation that wishes to use FancyAllocator 
with fallback GCAllocator with block attributes NO_INTERIOR and 
NO_SCAN.
With your proposed GCAllocator you either need to rewrite 
GCAllocator, or you need to add some nasty code to set the 
attributes depending on whether the primary allocator or 
secondary allocator own the memory.

By fixing the leaky abstraction this use case can be coded as 
follows:
FallbackAllocator!(FancyAllocator, 
GCAllocator!(GC.BLkAttr.NO_INTERIOR | GC.BLkAttr.NO_SCAN)) a;