On 10/24/13 5:13 PM, Michel Fortin wrote:
On 2013-10-24 19:54:41 +0000, Andrei Alexandrescu
<[email protected]> 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
