On Friday, 25 October 2013 at 01:00:04 UTC, Michel Fortin wrote:
On 2013-10-25 00:20:41 +0000, Andrei Alexandrescu
<[email protected]> 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.
