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
