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
