On 2/20/16 12:22 AM, Andrei Alexandrescu wrote:
On 02/19/2016 10:12 PM, Steven Schveighoffer wrote:
On 2/19/16 9:21 PM, Steven Schveighoffer wrote:
I'm trying to use the std.experimental.allocator API more in my new io
library, and I'm having a few stumbling points:
Another thought:
Allocators return void[] when requesting allocations, reallocations,
etc. For C malloc, the assumption must be that what you requested is
what you got, because the actual block size isn't given. However, for GC
(and I assume other allocators), we have mechanisms to know upon
allocation the amount of data received.
I would assume since we are returning both pointer and length, it would
be possible for an allocator to return more data than requested (why
waste it?). But it appears that the GC allocator just returns the amount
of data requested, even though it could return the extra data that was
received.
Should the API assumptions allow returning more data than requested? It
means code has to be wary of this, but creating a wrapper allocator that
truncates the data would be trivial, no?
I want to write some PRs to fix this, but I'm unclear what is expected.
Allocators are guaranteed to return the size requested. This is by
design. -- Andrei
Given that there is "goodAllocSize", this seems reasonable. But for
ease-of-use (and code efficiency), it may be more straightforward to
allow returning more data than requested (perhaps through another
interface function? allocateAtLeast?) and then wrap that with the other
allocation functions that simply slice the result down to size.
In the GC, expanding is done a page at a time. If I request an expansion
of 1 byte, that's 4095 wasted bytes. I don't expect goodAllocSize to
help me here.
BTW, just pushed an update to my i/o library that uses allocators
exclusively for buffers. But I make the default a custom GC allocator
that has the properties I need. I'm hoping there will be a way to get
the desired behavior from the phobos version at some point.
-Steve
