On Wed, Jan 31, 2018 at 01:38:07PM +, Bienlein via Digitalmars-d-learn
wrote:
> On Thursday, 21 December 2017 at 18:45:27 UTC, Adam D. Ruppe wrote:
> > On Thursday, 21 December 2017 at 18:20:19 UTC, H. S. Teoh wrote:
> > > When the scoped destruction of structs isn't an option,
> > >
On Wednesday, January 31, 2018 10:51:10 DanielG via Digitalmars-d-learn
wrote:
> On Wednesday, 31 January 2018 at 10:34:53 UTC, Mike Parker wrote:
> > delete is deprecated:
> >
> > https://dlang.org/deprecate.html#delete
>
> Ah, thanks! Actually double-thanks, because my progress through
> your
On Thursday, 21 December 2017 at 18:45:27 UTC, Adam D. Ruppe
wrote:
On Thursday, 21 December 2017 at 18:20:19 UTC, H. S. Teoh wrote:
When the scoped destruction of structs isn't an option,
RefCounted!T seems to be a less evil alternative than an
unreliable class dtor. :-/
Alas, RefCounted
On Wednesday, 31 January 2018 at 10:34:53 UTC, Mike Parker wrote:
delete is deprecated:
https://dlang.org/deprecate.html#delete
Ah, thanks! Actually double-thanks, because my progress through
your book is what prompted me to search for threads about class
destructors. The existence of
On Wednesday, 31 January 2018 at 10:14:53 UTC, DanielG wrote:
Pardon my probable ignorance (D newbie and all), but why
wouldn't a 'delete' work for this?
https://dlang.org/spec/expression.html#delete_expressions
delete is deprecated:
https://dlang.org/deprecate.html#delete
On Thursday, 21 December 2017 at 18:20:19 UTC, H. S. Teoh wrote:
I ended up calling .destroy on the class instance explicitly
just so the destructor would run at the right time, right
before nulling the reference so that the GC would collect the
memory.
Pardon my probable ignorance (D newbie
On Thursday, December 28, 2017 10:37:09 H. S. Teoh via Digitalmars-d-learn
wrote:
> On Sun, Dec 24, 2017 at 02:07:26PM -0700, Jonathan M Davis via
> Digitalmars-d-learn wrote: [...]
>
> > Regardless, even if it were the case that it were guaranteed that all
> > finalizers were run when the
On Sun, Dec 24, 2017 at 02:07:26PM -0700, Jonathan M Davis via
Digitalmars-d-learn wrote:
[...]
> Regardless, even if it were the case that it were guaranteed that all
> finalizers were run when the program exited, it would still be
> terrible practice to rely on it. It's trivial to end up in a
On Friday, December 22, 2017 01:23:26 Mike Parker via Digitalmars-d-learn
wrote:
> The class destructor is not run during the lifetime of the
> program. The fact that it's run during runtime termination is an
> implementation detail. Another implementation might not run a
> finalization at
On Friday, 22 December 2017 at 00:09:31 UTC, Mike Franklin wrote:
What condition(s) would cause a destructor for an object that
is managed by the GC to potentially not be called?
Good question. It's true that barring an Error, they should be
called by the GC at runtime termination.
On Friday, 22 December 2017 at 23:34:55 UTC, Mengu wrote:
i really wonder how Objective-C and Swift is pulling this off.
It isn't a fundamental problem, D just can't express it in the
existing language (heck, even D, as defined, could do it, the
implementation just isn't there.)
On Thursday, 21 December 2017 at 18:45:27 UTC, Adam D. Ruppe
wrote:
On Thursday, 21 December 2017 at 18:20:19 UTC, H. S. Teoh wrote:
When the scoped destruction of structs isn't an option,
RefCounted!T seems to be a less evil alternative than an
unreliable class dtor. :-/
Alas, RefCounted
On Thursday, 21 December 2017 at 18:20:19 UTC, H. S. Teoh wrote:
Even calling GC.collect directly did not guarantee the DB
handle was closed at the right time. This may have been a bug
in my code that left dangling references to it, or perhaps the
array of Database handles was still scanned
On Thursday, 21 December 2017 at 19:43:16 UTC, Steven
Schveighoffer wrote:
On 12/20/17 9:57 PM, Mike Franklin wrote:
[...]
It's implementation defined :)
The gist is, you cannot expect that destructors will be run in
a timely manner, or at all.
They may be called, and most of the time
On Friday, 22 December 2017 at 00:09:31 UTC, Mike Franklin wrote:
What condition(s) would cause a destructor for an object that
is managed by the GC to potentially not be called?
Here:
===
import std.stdio;
class Clazz {
~this() {
writeln("Class dest");
}
}
void
On Thursday, 21 December 2017 at 19:43:16 UTC, Steven
Schveighoffer wrote:
The gist is, you cannot expect that destructors will be run in
a timely manner, or at all.
They may be called, and most of the time they are. But the
language nor the current implementation makes a guarantee that
On Thursday, 21 December 2017 at 18:48:38 UTC, H. S. Teoh wrote:
Alas, RefCounted doesn't work well with inheritance...
Oh? What's the issue?
Implicit casts don't work so you can't pass a RefCounted!Class as
RefCounted!Interface except in simple cases using alias this
tricks.
On 12/20/17 9:57 PM, Mike Franklin wrote:
"Don't expect class destructors to be called at all by the GC"
I was a bit shocked to read that here:
https://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors
The document tries to clarify with:
"The garbage collector is not guaranteed to
On Thu, Dec 21, 2017 at 06:45:27PM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Thursday, 21 December 2017 at 18:20:19 UTC, H. S. Teoh wrote:
> > When the scoped destruction of structs isn't an option, RefCounted!T
> > seems to be a less evil alternative than an unreliable class dtor.
On Thursday, 21 December 2017 at 18:20:19 UTC, H. S. Teoh wrote:
When the scoped destruction of structs isn't an option,
RefCounted!T seems to be a less evil alternative than an
unreliable class dtor. :-/
Alas, RefCounted doesn't work well with inheritance...
Though, what you could do is
On Thu, Dec 21, 2017 at 06:50:44AM +, Mike Parker via Digitalmars-d-learn
wrote:
[...]
> I just don't even bother with class destructors. Without a guarantee
> that they can run and without any sort of deterministic behavior, it's
> really not appropriate to refer to them as destructors and
On Thursday, 21 December 2017 at 06:50:44 UTC, Mike Parker wrote:
On Thursday, 21 December 2017 at 04:10:56 UTC, user1234 wrote:
[...]
[...]
[...]
The root of the problem is that in D, class destruction and
finalization are conflated. It would be much more accurate to
refer to ~this
On Thursday, 21 December 2017 at 14:26:55 UTC, Guillaume Piolat
wrote:
On Thursday, 21 December 2017 at 06:50:44 UTC, Mike Parker
wrote:
That's what I've taken to doing manually, by implementing a
`terminate` function in my classes that I either call directly
or via a ref-counted templated
On Thursday, 21 December 2017 at 06:50:44 UTC, Mike Parker wrote:
That's what I've taken to doing manually, by implementing a
`terminate` function in my classes that I either call directly
or via a ref-counted templated struct called Terminator.
I feel like I'm rambling but..
The problem with
On Thursday, 21 December 2017 at 04:10:56 UTC, user1234 wrote:
On Thursday, 21 December 2017 at 02:57:00 UTC, Mike Franklin
Unfortunately, that doesn't really shed much light on this
oddity. So, specifically, under what circumstances are
destructors not called?
When the GC is unaware
On Thursday, 21 December 2017 at 02:57:00 UTC, Mike Franklin
wrote:
"Don't expect class destructors to be called at all by the GC"
I was a bit shocked to read that here:
https://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors
The document tries to clarify with:
"The garbage
"Don't expect class destructors to be called at all by the GC"
I was a bit shocked to read that here:
https://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors
The document tries to clarify with:
"The garbage collector is not guaranteed to run the destructors
for all unreferenced
27 matches
Mail list logo
