I'm learning D from 8 years in C++. My question is with regards to D garbage collection - when do I use delete, and when don't I need to?
相关问题
- What uses more memory in c++? An 2 ints or 2 funct
- C# GC not freeing memory [duplicate]
- Achieving the equivalent of a variable-length (loc
- garbage collection best practices
- Too many Garbage collection threads
相关文章
- MPI and D: Linker Options
- -fno-objc-arc not working to disable ARC
- How would a heap-allocated const object differ fro
- Why do we need Dispose() method on some object? W
- On scala project - Getting error GC overhead limit
- Azure Web App Temp file cleaning responsibility
- Is there a way to release unmanaged resources when
- Why am I not getting a stack overflow?
Take a look at Garbage Collection in the D documentation. As noted, it is (almost) never necessary to explicitly manage memory. Of course after spending a handful of bullet points trying to convince you of the GC's power, they include a few scenarios where garbage collection falls short. To address these short-falls (they call them constraints), Digital Mars offers tips for Memory Management.
If possible, let the D garbage collector do its thing. Ignore explicit memory management. In a few very specific scenarios, there's a potential for an unacceptable GC pause or memory that can't be reclaimed. If your app includes one of these scenarios (test and profile to prove it), isolate the cause of the problem and explicitly manage memory where necessary. D lets you start as an optimist. If things don't work out perfectly, it's reassuring that you can fall back on explicit memory management.
You don't. Delete is not to be used with D version 2 and intended to be removed from the language. What the hold up is, I am not sure. Instead you use a function, destroy(object), which calls the destructor where you can free resources that are not GC memory. The destructor will be caused again during GC collection of the objects own memory. This is explained in "The D Programming Language".
The idea is to reclaim resources earlier than what the GC would provide and prevents memory corruption from dangling pointers. To be less safe the core.memory module provides GC.free(object) which can be used to free the memory, after calling destroy(object).
As I'm not a C++ programmer, I don't really know the RAII pattern, but this and reference counting is the expected strategy if you wish to avoid the GC.