std.allocator ready for some abuse

[deadalnix]

On Friday, 25 October 2013 at 01:00:04 UTC, Michel Fortin wrote:
> On 2013-10-25 00:20:41 +0000, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> said:
>
>> If that happens, perhaps AffixAllocator!(A, size_t) could be 
>> of use by sticking the allocated size just before the 
>> allocation. But then you have a different problem - tapping 
>> into possibly cold memory when deallocating.
>
> The size is already available in the classinfo, but the 
> underlying allocator doesn't need it when deallocating (the 
> size part will get ignored). The goal is to not have to give 
> the size to deallocate when it doesn't need it (to save you 
> from retrieving it). All you need is to know that deallocate() 
> ignores the size part of the given array telling you whether or 
> not it's safe to call deallocate(pointer[0..0]). You could add 
> an optional "deallocateIgnoresSize" property for that.
>
> By the way, I think the idea of adding a boolean property for 
> this offers less room for misuse than adding an optional 
> deallocate(void*b) overload. With an overload you're 
> duplicating the API and it won't be immediately clear whether 
> or not it's best to provide the size.
>
> But I'm still not sure it's worth the trouble. I'll leave 
> others be the judge of that.

Many allocators have different policies for different size. So, 
if you don't pass the size, you ends up have to recover it, which 
can be a tedious constraint.

If the length is not used, I hope that The compiler may be able 
to optimize it way if the allocator is simple (so the deallocate 
function is inlined). If the deallocate function is quite 
complex, then I guess this extra calculation is required anyway, 
and won't matter that much.