On Friday, 5 March 2021 at 20:28:58 UTC, Ali Çehreli wrote:
To my surprise, even though 'c' is not null below, the
destructor is not executed multiple times.
Hence why
https://p0nce.github.io/d-idioms/#GC-proof-resource-class works
as a detector of undeterminism.
On 3/5/21 8:29 PM, Jack wrote:
> Now about the behavior of a static destructor, like static ~this() { }
> is this guaranteed to be run?
I don't know any way of creating a module on the GC heap so their
destruction should not be related to GC collection. I would expect all
'static ~this()'
On Saturday, 6 March 2021 at 04:29:41 UTC, Jack wrote:
Now about the behavior of a static destructor, like static
~this() { } is this guaranteed to be run?
Yes. Some perspective:
1. During program execution, class/struct destructors on
stack-allocated instances are invoked when the
On Friday, 5 March 2021 at 21:24:08 UTC, tsbockman wrote:
On Friday, 5 March 2021 at 21:17:24 UTC, tsbockman wrote:
On Friday, 5 March 2021 at 21:02:08 UTC, H. S. Teoh wrote:
class C {...}
import core.memory : GC;
C c = cast(C) GC.malloc(C.sizeof);
...
...
On Friday, 5 March 2021 at 21:25:52 UTC, Ali Çehreli wrote:
On 3/5/21 12:57 PM, Jack wrote:
>> destroy() executes the destructor.
>
> but I would need to call it manually and only after I
somewhat I've
> determined I no longer need the resources, right? so
destroy(c) would be
> no different
On Friday, 5 March 2021 at 21:02:08 UTC, H. S. Teoh wrote:
On Fri, Mar 05, 2021 at 08:24:26PM +, Jack via
Digitalmars-d-learn wrote:
On Friday, 5 March 2021 at 20:18:44 UTC, Max Haughton wrote:
> On Friday, 5 March 2021 at 20:13:54 UTC, Jack wrote:
[...]
> > But the ones heap may never
On 3/5/21 12:57 PM, Jack wrote:
>> destroy() executes the destructor.
>
> but I would need to call it manually and only after I somewhat I've
> determined I no longer need the resources, right? so destroy(c) would be
> no different from calling my own finalize-like method like
freeResources()?
On Friday, 5 March 2021 at 21:17:24 UTC, tsbockman wrote:
On Friday, 5 March 2021 at 21:02:08 UTC, H. S. Teoh wrote:
class C {...}
import core.memory : GC;
C c = cast(C) GC.malloc(C.sizeof);
...
...
import core.memory : GC;
C c = cast(C)
On Friday, 5 March 2021 at 21:02:08 UTC, H. S. Teoh wrote:
If you know when you can deallocate something, that means you
don't need the GC to collect it, so you could just allocate it
on the malloc heap instead, and call destroy/free once you're
done. You could use the C version of
On Fri, Mar 05, 2021 at 08:24:26PM +, Jack via Digitalmars-d-learn wrote:
> On Friday, 5 March 2021 at 20:18:44 UTC, Max Haughton wrote:
> > On Friday, 5 March 2021 at 20:13:54 UTC, Jack wrote:
[...]
> > > But the ones heap may never run at all, is that right?
> >
> > You can't rely on the
On Friday, 5 March 2021 at 20:28:58 UTC, Ali Çehreli wrote:
On 3/5/21 12:24 PM, Jack wrote:
Are there some kind of replacement or I have to make my own
finalize-like method, once I determine somewhat the
application no longer need those resources?
destroy() executes the destructor.
but I
On 3/5/21 12:24 PM, Jack wrote:
Are there some kind of replacement or I have to make my own
finalize-like method, once I determine somewhat the application no
longer need those resources?
destroy() executes the destructor.
To my surprise, even though 'c' is not null below, the destructor is
On Friday, 5 March 2021 at 20:18:44 UTC, Max Haughton wrote:
On Friday, 5 March 2021 at 20:13:54 UTC, Jack wrote:
On Friday, 5 March 2021 at 20:10:39 UTC, Max Haughton wrote:
On Friday, 5 March 2021 at 20:03:58 UTC, Jack wrote:
On Friday, 5 March 2021 at 09:23:29 UTC, Mike Parker wrote:
On
On Friday, 5 March 2021 at 20:13:54 UTC, Jack wrote:
On Friday, 5 March 2021 at 20:10:39 UTC, Max Haughton wrote:
On Friday, 5 March 2021 at 20:03:58 UTC, Jack wrote:
On Friday, 5 March 2021 at 09:23:29 UTC, Mike Parker wrote:
On Friday, 5 March 2021 at 05:31:38 UTC, Jack wrote:
[...]
On Friday, 5 March 2021 at 20:10:39 UTC, Max Haughton wrote:
On Friday, 5 March 2021 at 20:03:58 UTC, Jack wrote:
On Friday, 5 March 2021 at 09:23:29 UTC, Mike Parker wrote:
On Friday, 5 March 2021 at 05:31:38 UTC, Jack wrote:
The following code returns a memory error. I did notice it
did
On Friday, 5 March 2021 at 20:03:58 UTC, Jack wrote:
On Friday, 5 March 2021 at 09:23:29 UTC, Mike Parker wrote:
On Friday, 5 March 2021 at 05:31:38 UTC, Jack wrote:
The following code returns a memory error. I did notice it
did happens whenever I did a memory allocation. Is this not
possible
On Fri, Mar 05, 2021 at 08:03:58PM +, Jack via Digitalmars-d-learn wrote:
> On Friday, 5 March 2021 at 09:23:29 UTC, Mike Parker wrote:
> > On Friday, 5 March 2021 at 05:31:38 UTC, Jack wrote:
> > > The following code returns a memory error. I did notice it did
> > > happens whenever I did a
On Friday, 5 March 2021 at 09:23:29 UTC, Mike Parker wrote:
On Friday, 5 March 2021 at 05:31:38 UTC, Jack wrote:
The following code returns a memory error. I did notice it did
happens whenever I did a memory allocation. Is this not
possible in the descontrutor? if so, why?
On Friday, 5 March 2021 at 05:42:03 UTC, evilrat wrote:
On Friday, 5 March 2021 at 05:31:38 UTC, Jack wrote:
The following code returns a memory error. I did notice it did
happens whenever I did a memory allocation. Is this not
possible in the descontrutor? if so, why?
GC prohibits
On Friday, 5 March 2021 at 05:31:38 UTC, Jack wrote:
The following code returns a memory error. I did notice it did
happens whenever I did a memory allocation. Is this not
possible in the descontrutor? if so, why?
On Friday, 5 March 2021 at 05:31:38 UTC, Jack wrote:
The following code returns a memory error. I did notice it did
happens whenever I did a memory allocation. Is this not
possible in the descontrutor? if so, why?
GC prohibits allocation during collection, since this dtor is
likely called
21 matches
Mail list logo
