why allocators are not discussed here

Adam D. Ruppe destructionator at gmail.com
Wed Jun 26 14:05:53 PDT 2013


On Wednesday, 26 June 2013 at 21:00:54 UTC, Dmitry Olshansky 
wrote:
> Just don't use certain built-ins. Stub them out in run-time if 
> you like. The only problematic point I see is closures 
> allocated on heap.

Actually, I was kinda sorta able to solve this in my minimal d.

// this would be used for automatic heap closures, but there's no 
way to free it...
///*
extern(C)
void* _d_allocmemory(size_t bytes) {
         auto ptr = manual_malloc(bytes);
         debug(allocations) {
                 char[16] buffer;
                 write("warning: automatic memory allocation ", 
intToString(cast(size_t) ptr, buffer));
         }
         return ptr;
}


struct HeapClosure(T) if(is(T == delegate)) {
         mixin SimpleRefCounting!(T, q{
                 char[16] buffer;
                 write("\nfreeing closure ", 
intToString(cast(size_t) payload.ptr, buffer),"\n");
                 manual_free(payload.ptr);
         });
}

HeapClosure!T makeHeapClosure(T)(T t) { // if(__traits(isNested, 
T)) {
         return HeapClosure!T(t);
}



void closureTest2(HeapClosure!(void delegate()) test) {
         write("\nptr is ", cast(size_t) test.ptr, "\n");
         test();

         auto b = test;
}

void closureTest() {
         string a = "whoa";
         scope(exit) write("\n\nexit\n\n");
         //throw new Exception("test");
         closureTest2( makeHeapClosure({ write(a); }) );
}




It worked in my toy tests. The trick would be though to never 
store or use a non-scope builtin delegate. Using RTInfo, I 
believe I can statically verify you don't do this in the whole 
program,  but haven't actually tried yet.


I also left built in append unimplemented, but did custom types 
with ~= that are pretty convenient. Binary ~ is a loss though, 
too easy to lose pointers with that.


More information about the Digitalmars-d mailing list