New adapter: std.allocator.quantizer
Timon Gehr via Digitalmars-d
digitalmars-d at puremagic.com
Mon May 11 11:06:57 PDT 2015
On 05/11/2015 05:28 PM, Andrei Alexandrescu wrote:
> On 5/10/15 5:08 AM, Timon Gehr wrote:
>> On 05/10/2015 01:48 PM, Timon Gehr wrote:
>>>
>>>
>>> "bool expand(ref void[] b, size_t delta);
>>> Post: !result || b.length == old(b).length + delta Expands b by
>>> delta bytes. If delta == 0, succeeds without changing b. If b is null,
>>> the call evaluates b = allocate(delta) and returns b !is null.
>>> Otherwise, *b must be a buffer previously allocated with the same
>>> allocator*. If expansion was successful, expand changes b's length to
>>> b.length + delta and returns true. Upon failure, the call effects no
>>> change upon the allocator object, leaves b unchanged, and returns
>>> false."
>>
>> Actually, reading that snippet of the documentation, I notice more
>> problems in the implementation of expand/the documentation of the
>> rounding function.
>>
>> If the rounding function returns a non-zero result for a zero argument,
>> expand can return invalid memory (starting from address 0) if given an
>> empty block 'b'.
>
> Thanks again for the great review.
No problem!
> Just updated quantizer.d, I think I've addressed all points:
>
> https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/quantizer.d
>
Unfortunately,
- If the rounding function is not piecewise constant with one fixed
point per piece, it can happen that 'allocated >= needed' but 'allocated
< goodAllocSize(needed)'. Then, the allocated size will be inconsistent
with goodAllocSize. (This is why I recommended to require the rounding
function to have this property, which is stronger than monotonicity.)
- If b.ptr is null, then line 113 is bad in case goodAllocSize(0) > 0.
More information about the Digitalmars-d
mailing list