Can't I allocate at descontructor?

Jack jckj33 at gmail.com
Sat Mar 6 04:27:18 UTC 2021


On Friday, 5 March 2021 at 21:02:08 UTC, H. S. Teoh wrote:
> On Fri, Mar 05, 2021 at 08:24:26PM +0000, 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 garbage collector for deterministic 
>> > destruction, no.
>> 
>> 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?
> [...]
>
> If you know when you can deallocate something, that means you 
> don't need the GC to collect it,

I'll modify the program so that I know the right state to call my 
finalize-like method or just destroy(c). Until I find out that 
destrutor behavior, I was going to just use the destrutor

  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 malloc/free.  You can 
> also optionally use GC.malloc/GC.free.
>
> E.g.:
>
> 	class C {...}
>
> 	import core.memory : GC;
> 	C c = cast(C) GC.malloc(C.sizeof);
> 	... // use c
>
> 	// We're done with c, destroy it
> 	destroy(c);	// this will call the dtor
> 	GC.free(cast(void*) c);
> 	c = null; // optional, just to ensure we don't accidentally 
> use it again
>
>
> T

I'll do something like this, thanks



More information about the Digitalmars-d-learn mailing list