std.allocator ready for some abuse

Maxim Fomin maxim at maxim-fomin.ru
Fri Oct 25 01:09:29 PDT 2013


On Friday, 25 October 2013 at 07:19:48 UTC, Namespace wrote:
> On Friday, 25 October 2013 at 00:00:36 UTC, Andrei Alexandrescu 
> wrote:
>> On 10/24/13 2:38 PM, Namespace wrote:
>>> On Thursday, 24 October 2013 at 21:31:42 UTC, Namespace wrote:
>>>> Awesome! Will Appender get an option to use a suitable 
>>>> allocator?
>>>
>>> A dream of me, that will probably never come true, would be 
>>> also
>>> something like this:
>>> ----
>>> with (Mallocator) {
>>>    int[] arr;
>>>    arr ~= 42; /// will use Mallocator.it.allocate internal
>>> }
>>> ----
>>
>> Oddly enough this can be actually done.
>>
>> with (setAllocator!Mallocator)
>> {
>>   ...
>> }
>>
>> setAllcator returns an rvalue that changes the global 
>> allocator to the Mallocator in the constructor, and restores 
>> it to whatever it was in the destructor.
>>
>>
>> Andrei
>
> Are you saying that this code:
> ----
> with (setAllocator!Mallocator) {
>     int[] arr;
>     arr ~= 42; [1]
> }
> ----
> use the mallocator for [1]? So no GC memory is needed?
>
> Another examaple:
> ----
> with (setAllocator!ScopeAllocator) {
>     int[] arr;
>     arr ~= 42; [1]
> }
> ----
> Did [1] use ScopeAllocator for memory allocation? And is the 
> memory of arr automatically collected at the end of the scope 
> with ScopeAllocator?

This is impossible because with() has already another meaning. 
However nothing stops from inventing another name for this. 
Compiler can insert calls to druntime as well to other context 
dependent functions. After allocator design is defined we can 
move on to step 2, implementing this idea.


More information about the Digitalmars-d mailing list