digitalmars.D.learn - Clean way to tell whether a destructor is called by the GC
- ponce (21/21) May 12 2015 I need a robust "isCalledByGC" function to leak intentionally
- Adam D. Ruppe (9/9) May 12 2015 Let me suggest a completely different option: make a destructor
I need a robust "isCalledByGC" function to leak intentionally when a destructor is called as a result of the GC. It is a way to enforce deterministic destruction without ever relying on accidental correctness. class A { ~this() { if(iscalledByGC()) { [leak and write an error to stderr] } else { [normal release of resources] } } } Prior solution: http://forum.dlang.org/post/li2oj4$1avo$1 digitalmars.com but that involves modifying the runtime.
May 12 2015
Let me suggest a completely different option: make a destructor that works while the GC is running by managing the resources manually in both construction and destruction. Remember, it isn't *all* reference types that are problematic to access, it is just GC managed references. So anything from a C function is cool. Otherwise, accessing the runtime variable seems ok to me like the link said, hacky sure, but it'd work.... nothing else comes to mind, other than using a separate dispose() method when you delete it manually and leave the dtor for only the GC.
May 12 2015
On Tuesday, 12 May 2015 at 12:31:35 UTC, Adam D. Ruppe wrote:Let me suggest a completely different option: make a destructor that works while the GC is running by managing the resources manually in both construction and destruction.I see, but not all ressources can be disposed by any thread. I'd prefer to make it an error. Also, relying on GC destructors can make a program work by mistake.isn't *all* reference types that are problematic to access, it is just GC managed references. So anything from a C function is cool. Otherwise, accessing the runtime variable seems ok to me like the link said, hacky sure, but it'd work.... nothing else comes to mind, other than using a separate dispose() method when you delete it manually and leave the dtor for only the GC.I already have such a dispose() function. The problem is that to support Unique! and scoped! and friends, the destructor must call dispose(). Thus my need for a way to separate the GC-induced destructors within dispose() or ~this (same problem).
May 12 2015
On Tuesday, 12 May 2015 at 12:53:59 UTC, ponce wrote:I already have such a dispose() function. The problem is that to support Unique! and scoped! and friends, the destructor must call dispose(). Thus my need for a way to separate the GC-induced destructors within dispose() or ~this (same problem).Maybe it's simpler to copy-paste Unique and scoped and modify them to handle disposable objects?
May 13 2015
On Wednesday, 13 May 2015 at 11:24:10 UTC, Kagamin wrote:On Tuesday, 12 May 2015 at 12:53:59 UTC, ponce wrote:But then we would need a standardized name (some use "close", some use "dispose", some use "release") The closest thing we have to a standardized function name is the destructor.I already have such a dispose() function. The problem is that to support Unique! and scoped! and friends, the destructor must call dispose(). Thus my need for a way to separate the GC-induced destructors within dispose() or ~this (same problem).Maybe it's simpler to copy-paste Unique and scoped and modify them to handle disposable objects?
May 14 2015
On Thursday, 14 May 2015 at 17:25:55 UTC, ponce wrote:But then we would need a standardized name (some use "close", some use "dispose", some use "release")In .net the standardized name is "dispose" and IDisposable interface having the method: https://msdn.microsoft.com/en-us/library/System.IDisposable.aspx it also suggests possible operations "free" and "reset". "close" makes sense for files, but files are not the only type of disposable resource.
May 15 2015
Another idiom from .net is Dispose(bool) method, called with argument true from Dispose and with argument false from finalizer. https://msdn.microsoft.com/en-us/library/d9yzd5cx.aspx
May 15 2015