For cycle in RC you either do it like other RC system and break
cycles manually, or create a parent owner to own every things
pointing to each other and having cycles.
On Thursday, 27 July 2017 at 11:43:37 UTC, Steven Schveighoffer
wrote:
This is an unworkable solution.
Not at all
Consider reference counting with cycles. The proposal from
Walter/Andrei is to do reference counting to clean up
everything but cycles. For cycles, the GC will take care of it.
That is the PHP way to do things. :) It's neat but I still think
the only real thing to deal with resources is
On 7/27/17 4:23 AM, Guillaume Piolat wrote:
On Wednesday, 26 July 2017 at 22:29:50 UTC, Steven Schveighoffer wrote:
Today, the finalizer is essentially a last-effort to clean up
resources that would otherwise leak.
My point is that this "last chance" to clean up resources should only be
used
On Wednesday, 26 July 2017 at 22:29:50 UTC, Steven Schveighoffer
wrote:
Today, the finalizer is essentially a last-effort to clean up
resources that would otherwise leak.
My point is that this "last chance" to clean up resources should
only be used to tell deterministic destruction wasn't
I might be hated for saying this but I still think the GC problem
should not be apart of D language. Make it the user's or third
party problem.
On 7/26/17 8:20 PM, Moritz Maxeiner wrote:
On Thursday, 27 July 2017 at 00:00:08 UTC, Steven Schveighoffer wrote:
On 7/26/17 7:28 PM, Moritz Maxeiner wrote:
On Wednesday, 26 July 2017 at 22:33:23 UTC, Steven Schveighoffer wrote:
On 7/26/17 2:33 PM, Moritz Maxeiner wrote:
A finalizer may
On Thursday, 27 July 2017 at 00:00:08 UTC, Steven Schveighoffer
wrote:
On 7/26/17 7:28 PM, Moritz Maxeiner wrote:
On Wednesday, 26 July 2017 at 22:33:23 UTC, Steven
Schveighoffer wrote:
On 7/26/17 2:33 PM, Moritz Maxeiner wrote:
A finalizer may freely work on non-pointer members and pointer
On 7/26/17 7:28 PM, Moritz Maxeiner wrote:
On Wednesday, 26 July 2017 at 22:33:23 UTC, Steven Schveighoffer wrote:
On 7/26/17 2:33 PM, Moritz Maxeiner wrote:
On Wednesday, 26 July 2017 at 17:38:28 UTC, Dgame wrote:
I don't get it. The GC collects the objects which aren't in use
anymore. The
On Wednesday, 26 July 2017 at 23:28:38 UTC, Moritz Maxeiner wrote:
This falsely assumes that all members point into the GC pool. A
finalizer may freely work on non-pointer members and pointer
members that target objects outside the GC pool which the
programmer knows to be valid at
On Wednesday, 26 July 2017 at 22:33:23 UTC, Steven Schveighoffer
wrote:
On 7/26/17 2:33 PM, Moritz Maxeiner wrote:
On Wednesday, 26 July 2017 at 17:38:28 UTC, Dgame wrote:
I don't get it. The GC collects the objects which aren't in
use anymore. The order in which this is currently happening
On 7/26/17 2:33 PM, Moritz Maxeiner wrote:
On Wednesday, 26 July 2017 at 17:38:28 UTC, Dgame wrote:
I don't get it. The GC collects the objects which aren't in use
anymore. The order in which this is currently happening is not
specified. So, how are the destructors supposed to be called in the
On 7/26/17 12:01 PM, Guillaume Piolat wrote:
On Wednesday, 26 July 2017 at 15:15:03 UTC, Steven Schveighoffer wrote:
On 7/26/17 10:57 AM, Guillaume Piolat wrote:
I'll defend the view point that there is _nothing_ useful to do in a
finalizer except to check if the destructor has already been
On Wednesday, 26 July 2017 at 20:02:02 UTC, Moritz Maxeiner wrote:
On Wednesday, 26 July 2017 at 19:18:48 UTC, Dgame wrote:
Alright, thanks for the clarification. I've briefly hoped for
some sort of miracle such as deterministic object lifetime
without manual interaction. :)
I'm not sure
On Wednesday, 26 July 2017 at 19:18:48 UTC, Dgame wrote:
Alright, thanks for the clarification. I've briefly hoped for
some sort of miracle such as deterministic object lifetime
without manual interaction. :)
I'm not sure what scheme you are trying to describe here, could
you give a code
On Wednesday, 26 July 2017 at 18:33:58 UTC, Moritz Maxeiner wrote:
On Wednesday, 26 July 2017 at 17:38:28 UTC, Dgame wrote:
I don't get it. The GC collects the objects which aren't in
use anymore. The order in which this is currently happening is
not specified. So, how are the destructors
On Wednesday, 26 July 2017 at 17:38:28 UTC, Dgame wrote:
I don't get it. The GC collects the objects which aren't in use
anymore. The order in which this is currently happening is not
specified. So, how are the destructors supposed to be called in
the right order? Manually? ARC?
After the
I don't get it. The GC collects the objects which aren't in use
anymore. The order in which this is currently happening is not
specified. So, how are the destructors supposed to be called in
the right order? Manually? ARC? As far as I understand it, the GC
can't do it, otherwise we wouldn't
On Wednesday, 26 July 2017 at 15:15:03 UTC, Steven Schveighoffer
wrote:
On 7/26/17 10:57 AM, Guillaume Piolat wrote:
I'll defend the view point that there is _nothing_ useful to
do in a finalizer except to check if the destructor has
already been called.
The thing to do in a finalizer that
On Wednesday, 26 July 2017 at 15:42:45 UTC, jmh530 wrote:
On Wednesday, 26 July 2017 at 14:57:14 UTC, Guillaume Piolat
wrote:
But then no transition path.
Does seem a bit like a nightmare...
It may facilitate a transition to add a destructor member
function as well (C# has dispose as an
On Wednesday, 26 July 2017 at 14:57:14 UTC, Guillaume Piolat
wrote:
But then no transition path.
Does seem a bit like a nightmare...
It may facilitate a transition to add a destructor member
function as well (C# has dispose as an interface, maybe that's
better?). Then have a deprecation
On 7/26/17 10:57 AM, Guillaume Piolat wrote:
I'll defend the view point that there is _nothing_ useful to do in a
finalizer except to check if the destructor has already been called.
For instance, a destructor could destroy recursively all members at that
time.
A finalizer would not be
On Wednesday, 26 July 2017 at 14:10:19 UTC, Moritz Maxeiner wrote:
AFAICT that was mostly because it would have broken plenty of
existing code.
The validity or purposefulness of such code is up to debate, a
separate debate granted.
Let's assume there is working code that such a change will
@delete() {}
delete() {}
On Wed, Jul 26, 2017 at 3:08 PM, jmh530 via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Wednesday, 26 July 2017 at 12:55:17 UTC, Mike Parker wrote:
>
>> ---
>>> ~this() {}// Finalizer
>>> ~this() @nogc {} // Finalizer
>>>
On Wednesday, 26 July 2017 at 13:54:15 UTC, Guillaume Piolat
wrote:
On Wednesday, 26 July 2017 at 12:35:19 UTC, Mike Parker wrote:
On Wednesday, 26 July 2017 at 12:19:15 UTC, Guillaume Piolat
wrote:
I don't get the distinction between destructors and
"finalizers" but imho the problem is very
On Wednesday, 26 July 2017 at 12:35:19 UTC, Mike Parker wrote:
On Wednesday, 26 July 2017 at 12:19:15 UTC, Guillaume Piolat
wrote:
I don't get the distinction between destructors and
"finalizers" but imho the problem is very much that the GC is
calling ~this.
Destructors are deterministic,
On 7/26/17 8:57 AM, Mike Parker wrote:
On Wednesday, 26 July 2017 at 12:43:27 UTC, Steven Schveighoffer wrote:
Regarding the OP, I think we really should strive to have something to
fix this issue.
A poor-mans distinction could be done by checking whether the GC is
currently the one
On Wednesday, 26 July 2017 at 12:55:17 UTC, Mike Parker wrote:
---
~this() {}// Finalizer
~this() @nogc {} // Finalizer
~this @deterministic {} // Destructor
~this @nogc @deterministic {} // Destructor
}
Yeah, this brings with it more flexibility. I'd
On Wednesday, 26 July 2017 at 12:43:27 UTC, Steven Schveighoffer
wrote:
Regarding the OP, I think we really should strive to have
something to fix this issue.
A poor-mans distinction could be done by checking whether the
GC is currently the one destroying (a flag is available, but
isn't
On Wednesday, 26 July 2017 at 09:29:15 UTC, Moritz Maxeiner wrote:
As class destructors (in contrast to class finalizers) are then
called exclusively in a deterministic fashion, there's no
reason to forbid them from allocating using the GC, so I don't
think using the @nogc attribute would be
On 7/26/17 8:19 AM, Guillaume Piolat wrote:
On Wednesday, 26 July 2017 at 02:58:00 UTC, Mike Parker wrote:
When cleaning up, the GC will ensure that all destructors are run
where they exist, followed by all finalizers. And destroy would be
changed to call rt_destruct instead of rt_finalize.
On Wednesday, 26 July 2017 at 12:19:15 UTC, Guillaume Piolat
wrote:
I don't get the distinction between destructors and
"finalizers" but imho the problem is very much that the GC is
calling ~this.
Destructors are deterministic, finalizers are not. At least,
that's how I understand the
On Wednesday, 26 July 2017 at 02:58:00 UTC, Mike Parker wrote:
When cleaning up, the GC will ensure that all destructors are
run where they exist, followed by all finalizers. And destroy
would be changed to call rt_destruct instead of rt_finalize.
Thoughts?
I don't get the distinction
On Wednesday, 26 July 2017 at 02:58:00 UTC, Mike Parker wrote:
Regarding the issue with `destroy` not being @nogc, I my
understanding is it comes down to `rt_finalize` not being
@nogc. I haven't dug too deeply into the discussions around it,
but I'm wondering if it's possible to separate the
On Wednesday, 26 July 2017 at 02:58:00 UTC, Mike Parker wrote:
Internally, the runtime will treat each differently. an
rt_destruct would call all every __dtor in a hierarchy and
rt_finalize would be changed to call every __finalizer (a new
addition) in a hierarchy. When cleaning up, the GC
Regarding the issue with `destroy` not being @nogc, I my
understanding is it comes down to `rt_finalize` not being @nogc.
I haven't dug too deeply into the discussions around it, but I'm
wondering if it's possible to separate the concept of destruction
from finalization in the implementation?
35 matches
Mail list logo
