std.allocator ready for some abuse

[Andrei Alexandrescu]

On 10/24/13 5:13 PM, Michel Fortin wrote:
> On 2013-10-24 19:54:41 +0000, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> said:
>
>> Please destroy! I've literally sweat as I'm sending this :o).
>
> Seems good. Although I'm no expert on allocators I find it very easy to
> grasp. One remark though.
>
> While it generally makes sense that you know the size of an allocation
> when you want to deallocate, in some case it might be suboptimal to have
> to provide the size. For instance, you could use an allocator to
> allocate an object (with a virtual table and all). When comes the time
> to deallocate, to get the size you might have to dereference two
> pointers to extract the value from the classinfo, then create the proper
> void[] range to feed deallocate(). If your allocator is a wrapper for
> malloc/free, the size bit is ignored when calling free and all that work
> for retrieving the actual size of the object is wasted.
>
> I don't know if this is something worth addressing.

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.

I have plans to define a type that allows user-defined extra data 
grouped together (e.g. in an array or a list). Due to packing, subword 
per-allocation data can be stored efficiently. Such a design would allow 
storing all object sizes together.


Andrei