std.allocator ready for some abuse

[Andrei Alexandrescu]

On 10/31/13 8:37 PM, safety0ff wrote:
> 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;

Migrating the flags into the type is a possibility but maybe it's 
easiest to add flags as runtime parameters.

Allocators can always define additional nonstandard routines. The 
standard routines concern mostly composition.

Of course, it is also possible to make such flags standard (it may be 
the case that typed allocators require such).


Andrei