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