On 13 May 2014 14:39, Kagamin via Digitalmars-d <[email protected]> wrote: > On Saturday, 10 May 2014 at 19:17:02 UTC, Xavier Bigand wrote: >> >> My concerns as Dlang user are : >> - Even if GC is the solution, how long I need suffer with destructor's >> issues (calls order)? > > > What issues do you have with destructors and how they affect you? > > >> - When we will able to see a performant GC implementation can satisfy >> someone like Manu :) ? Months, years, a decade? > > > Neither GC nor C heap will satisfy Manu's requirements. When it comes to > shooters, the only way is to not allocate and write accurate code, even in > C++. Even substitution of allocator won't help him, if the code relies on GC > in a non-trivial way.
I'm not quite sure what you're saying, but I don't think it's quite as stringent as you suggest, at least, not anymore. We so try to minimise allocations, but some dynamic memory usage is just a modern reality. There is only a single requirement I see for automatic memory management to be practical, and it is very simple; time associated with whatever memory management needs to be fine-grained and evenly distributed. It needs to be amortised in some way. This obviously lends itself to eager-freeing systems like ARC. If a GC can be made that is reasonably nonintrusive; like one that is decently concurrent, ideally incremental in some way, maybe has split pools, where a high-frequency/small-allocation/temporary pool (ie, runtime temp data, closures, strings) may clean up very quickly without resulting in full memory scans... maybe it's possible. I don't know. The problem is, it's been years, nobody seems to know how to do it. It's still not clear that would be acceptable, and I have no reason to believe such a GC would be higher performance than ARC anyway... but I'm more than happy to be surprised, if someone really thinks it can be done. The other topic is still relevant to me too however (and many others). We still need to solve the problem with destructors. I agree with Andrei, they should be removed from the language as they are. You can't offer destructors if they don't get called. And the usefulness of destructors is seriously compromised if you can't rely on them being executed eagerly. Without eager executed destructors, in many situations, you end up with effective manual releasing the object anyway (*cough* C#), and that implies manually maintaining knowledge of lifetime/end of life and calling some release. I see memory management as a moot offering as soon as that reality exists. If we do end out with a GC that is somehow acceptable (I'm still skeptical), then this discussion about what to do with destructors is still ongoing. Do we ARC just those objects that have destructors like Andrei suggested? It's a possibility, I can't think of any other solution. In lieu of any other solution, it sounds like we could very well end up with ARC tech available one way or another, even if it's not pervasive, just applied implicitly to things with destructors.
