std.allocator ready for some abuse
Michel Fortin
michel.fortin at michelf.ca
Thu Oct 24 18:00:13 PDT 2013
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.
--
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca
More information about the Digitalmars-d
mailing list