std.allocator ready for some abuse

[Andrei Alexandrescu via Digitalmars-d]

On 09/11/2015 07:46 PM, bitwise wrote:
> 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?

Say you have a container that uses its own allocator inside, yet offers 
the user to store objects with indirections that use the GC. Then indeed 
the container would need to call addRange and removeRange on its own 
internal structures.

If, on the contrary, the container imposes that its own held objects use 
the container's allocator as well (a rare but not implausible design), 
it wouldn't need to do that.


Andrei