4 ms·

You can definitely survive without the GC, personally I've gone through eliminating exceptions entirely and implementing my own allocators throughout. There ar

by Profan 11y ago

You can definitely survive without the GC, personally I've gone through eliminating exceptions entirely and implementing my own allocators throughout. There are a few gotchas sometimes, like array literals of certain kinds sometimes allocating when you don't expect them to, but these can usually be sorted. Something which also might bite you, but can be caught with the gc-tracking compiler flag, is the fact that delegate _closures_ use the GC, regular delegates however will not need the GC, one thing to keep in mind. There's quite a bit of info about how the GC impacts things, and how to get by without it around, so I think you'll survive without it's presence. Lately as well, efforts to annotate portions of the standard library which don't use the GC at all with a special annotation @nogc has been underway, which makes it explicit if something can allocate or not (this is transitive, so a @nogc annotated function can only call @nogc annotated functions which can't do any gc allocation in turn).

yoklov 11y ago
I could probably survive not using most of the standard library (I might try to do this anyway to avoid issues with deployment, as I have done in the past in C++). I'm not a huge fan of closures in many cases (if they outlive the scope of their defining function I think it leads to unclear code), so the fact that they might allocate is not a huge deal to me. Array literals silently allocating GCed memory concerns me greatly however... I remember hearing about efforts to remove a lot of the reliance on the GC, and I guess I was hoping that that was further along than it sounds like it is. Still, I'll try not to pass judgement until I try it out on something small. There are a lot of other potential issues unrelated to the GC that would probably be dealbreakers for me.
- Profan 11y ago
  The array literals problem isn't so bad, the thing is static arrays in D are distinct types, so you'd say int[2] = [1, 2]; which would go on the stack, but doing int[] = [1, 2]; would allocate since it would be a dynamic array then. Good luck with trying it out, you make tradeoffs as with any other language :)

by Profan 11y ago

yoklov 11y ago

I could probably survive not using most of the standard library (I might try to do this anyway to avoid issues with deployment, as I have done in the past in C++). I'm not a huge fan of closures in many cases (if they outlive the scope of their defining function I think it leads to unclear code), so the fact that they might allocate is not a huge deal to me. Array literals silently allocating GCed memory concerns me greatly however... I remember hearing about efforts to remove a lot of the reliance on the GC, and I guess I was hoping that that was further along than it sounds like it is. Still, I'll try not to pass judgement until I try it out on something small. There are a lot of other potential issues unrelated to the GC that would probably be dealbreakers for me.

Profan 11y ago
The array literals problem isn't so bad, the thing is static arrays in D are distinct types, so you'd say int[2] = [1, 2]; which would go on the stack, but doing int[] = [1, 2]; would allocate since it would be a dynamic array then. Good luck with trying it out, you make tradeoffs as with any other language :)