std.expreimantal.allocator deallocate
Petar
Petar
Sun Jan 24 18:25:37 UTC 2021
On Sunday, 24 January 2021 at 16:16:12 UTC, vitamin wrote:
> On Sunday, 24 January 2021 at 14:56:25 UTC, Paul Backus wrote:
>> On Sunday, 24 January 2021 at 11:00:17 UTC, vitamin wrote:
>>> It is Ok when I call deallocate with smaller slice or I need
>>> track exact lengtht?
>>
>> It depends on the specific allocator, but in general, it is
>> only guaranteed to work correctly if the slice you pass to
>> deallocate is exactly the same as the one you got from
>> allocate.
>
> thanks,
> is guaranteed this:
>
> void[] data = Allocator.allocate(data_size);
> assert(data.length == data_size)
>
>
> or can be data.length >= data_size ?
Yes, it is guaranteed [0]. Even though some allocator
implementations will allocate a larger block internally to back
your requested allocation size, `allocate` [1] must return the
same number of bytes as you requested, or a `null` slice.
If an allocator has a non-trivial `goodAllocSize(s)` [2] function
(i.e. one that is not the identity function `s => s`) and you you
allocate say N bytes, while allocator.goodAllocSize(N) returns M,
M > N, it means that most likely calling `expand` [3] will
succeed - meaning it will give you the excess memory that it has
internally for free. I say "most likely", because this is the
intention of the allocator building blocks spec, even though it's
not specified. In theory, `expand` could fail in such situation
either because of an allocator implementation deficiency (which
would technically not be a bug), or because `allocate` was called
concurrently by another thread and the allocator decided to give
the excess space to someone else.
[0]:
https://dlang.org/phobos/std_experimental_allocator_building_blocks.html
[1]:
https://dlang.org/phobos/std_experimental_allocator.html#.IAllocator.allocate
[2]:
https://dlang.org/phobos/std_experimental_allocator.html#.IAllocator.goodAllocSize
[3]:
https://dlang.org/phobos/std_experimental_allocator.html#.IAllocator.expand
More information about the Digitalmars-d-learn
mailing list