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
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.
On Wednesday, 13 May 2015 at 11:24:10 UTC, Kagamin wrote:
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 G
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 prob
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.
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
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