std.allocator ready for some abuse

[bitwise via Digitalmars-d]

On Friday, 11 September 2015 at 23:13:16 UTC, Andrei Alexandrescu 
wrote:
> On 09/11/2015 06:32 PM, bitwise 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
>>
>> Doesn't this race because the allocator instance is shared?
>>
>> I couldn't find 'setAllocator' in the source code.
>
> Yah, that was a rumination, not something already implemented. 
> -- Andrei

Ok, thanks. I thought that may be the case.

One more question:

I'd like to integrate these into the containers I'm building, but 
I'm not clear about how to determine if GC.addRange() should be 
called.

I've thought through this, and I'm pretty sure that I can call 
GC.addRange and GC.removeRange indiscriminately on any memory my 
container gets from an allocator, as long as the container finds 
that (hasIndirections!T == true).

My reasoning is that if an allocator calls GC.addRange on it's 
own memory, then it should also reinitialize that memory when it 
gets deallocated, which would include calling GC.addRange again 
if it had to. Also, calling GC.addRange or GC.removeRange on GC 
allocated memory should have no effect.

Does this sound right, or am I crazy?

    Bit