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