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