std.allocator ready for some abuse
Namespace
rswhite4 at googlemail.com
Fri Oct 25 02:13:44 PDT 2013
On Friday, 25 October 2013 at 08:50:23 UTC, Maxim Fomin wrote:
> On Friday, 25 October 2013 at 08:27:52 UTC, Namespace wrote:
>>
>> Something like that:
>> http://forum.dlang.org/thread/l4btsk$5u8$1@digitalmars.com?page=3#post-pfoxyfzyjxqcqwnvgnpi:40forum.dlang.org
>>
>> Every array has an internal allocator property which can be
>> reset:
>> ----
>> int[] arr;
>> arr.allocator = Mallocator;
>> ----
>>
>> or
>>
>> ----
>> int[] arr;
>> arr.useAllocator(Mallocator);
>> ----
>
> That's doable.
>
>> But maybe a design without some alias notation would be more
>> preferable:
>> ----
>> {
>> ScopeAllocator m;
>> int[] arr;
>> arr.useAllocator(m);
>>
>> arr ~= 42; /// Use m.allocate
>> } /// end of scope: ScopeAllocator collects all remaining
>> memory.
>> ----
>>
>> And:
>> ----
>> int[] arr;
>> assert(arr is null);
>> {
>> ScopeAllocator m;
>> arr.useAllocator(m);
>>
>> arr ~= 42; /// Use m.allocate
>> } /// end of scope: ScopeAllocator collects all remaining
>> memory.
>> assert(arr is null);
>> ----
>
> That's also doable. TypeInfo will be bloated more and there
> would be cost of some sort of scope exit, and, ideally, a check
> that reference does not escape, but this is doable.
Why the cost of scope(exit)? If ScopeAllocator m get out of
scope, the DTor is called and ideally the collect method is
called. That's all. Or am I wrong?
More information about the Digitalmars-d
mailing list