New adapter: std.allocator.quantizer

Timon Gehr via Digitalmars-d digitalmars-d at puremagic.com
Mon May 11 11:31:11 PDT 2015


On 05/11/2015 08:06 PM, Timon Gehr wrote:
> 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.
>

Oh, and

- The assertion in line 141 may fail. (expand can return false.)
   (Rant: Go on, conflate assert and assume in -release and then, when a 
sufficiently smart optimizer runs, suddenly expand will always return 
true and user code that checks for success of expand will be removed. 
Awesome.)

- 'expand' ought to call 'allocate' when passed an empty buffer in case 
the parent does not define 'expand', no?


More information about the Digitalmars-d mailing list