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 not executed multiple times.

import std.stdio;

class C {
  string fileName;

  this(string fileName) {
    writeln("constructing");
    this.fileName = fileName;
    writeln("creating file");
  }

  ~this() {
    writeln("destructing");
    if (fileName) {
      writeln("removing the file");

    } else {
      writeln("NOT removing the file");
    }
  }
}

void main() {
  auto c = new C("some imaginary file name");

  // Executes the destructor
  destroy(c);

  // This does not do anything
  destroy(c);

  // Neither does this
  import core.memory;
  GC.collect();
}

Ali

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 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()?

> To my surprise, even though 'c' is not null below, the destructor is not executed multiple times.
>
> import std.stdio;
>
> class C {
>   string fileName;
>
>   this(string fileName) {
>     writeln("constructing");
>     this.fileName = fileName;
>     writeln("creating file");
>   }
>
>   ~this() {
>     writeln("destructing");
>     if (fileName) {
>       writeln("removing the file");
>
>     } else {
>       writeln("NOT removing the file");
>     }
>   }
> }
>
> void main() {
>   auto c = new C("some imaginary file name");
>
>   // Executes the destructor
>   destroy(c);
>
>   // This does not do anything
>   destroy(c);
>
>   // Neither does this
>   import core.memory;
>   GC.collect();
> }
>
> Ali

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, 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

-- 
Freedom of speech: the whole world has no right *not* to hear my spouting off!

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 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

Unless the function is nothrow, that should really be:

    import core.memory : GC;
    C c = cast(C) GC.malloc(C.sizeof);
    scope(exit) {
        // 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
    }
    ... // use c

Or,

    import core.memory : GC;
    C c = cast(C) GC.malloc(C.sizeof);
    try {
        ... // use c
    } finally {
        // 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
    }

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) GC.malloc(C.sizeof);
>     ...

Also, that's not the correct way to manually allocate a class on the heap. C.sizeof is the size of a reference to C, not an instance of C, and we need to blit and construct the instance before it is safe to use:

    import core.memory : GC;
    C c = cast(C) GC.malloc(__traits(classInstanceSize, C));
    import core.lifetime : emplace;
    emplace(c, anyConstructorArgsGoHere);
    ...

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()?

Yes but perhaps with some extra functionality like the optional 'initialize':

  https://dlang.org/phobos/object.html#.destroy

Ali

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

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);
>>>      ...
>>     ...
>>     import core.memory : GC;
>>     C c = cast(C) GC.malloc(C.sizeof);
>>     ...
>
> Also, that's not the correct way to manually allocate a class on the heap. C.sizeof is the size of a reference to C, not an instance of C, and we need to blit and construct the instance before it is safe to use:
>
>     import core.memory : GC;
>     C c = cast(C) GC.malloc(__traits(classInstanceSize, C));
>     import core.lifetime : emplace;
>     emplace(c, anyConstructorArgsGoHere);
>     ...

good catch, thanks

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 from calling my own finalize-like method like
> freeResources()?
>
> Yes but perhaps with some extra functionality like the optional 'initialize':
>
>   https://dlang.org/phobos/object.html#.destroy
>
> Ali

Now about the behavior of a static destructor, like static ~this() { } is this guaranteed to be run?

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 instances go out of scope.

2. During program execution, class/struct destructors on GC-allocated instances are only called when the GC determines the instances are no longer referenced AND it needs to reclaim memory. There is no way to know when or if this will happen during the program's execution. Short-lived programs may never need to reclaim memory, so the destructors may never be called. The longer a program runs, and the more it allocates from the GC heap, the more likely it is that a given object's destructor will be called during execution since the GC will need to reclaim memory more often. This is a consequence of relying on the GC to manage memory.

3. After the main function exits, the runtime will invoke all module destructors. They do not belong to any class or struct instance, nor are they managed by the GC. They will always execute.

4. After module destructors are invoked, the GC will begin its shutdown. By default, it will invoke the destructors on every class/struct instance for which it hasn't. This can be disabled via a command-line argument for DRuntime.

So with the current implementation, all GC-managed class and struct destructors will end up being called at some point. But the spec does not require the GC to invoke destructors during shutdown--that's an implementation detail. Moreover, since the person executing the program can turn that behavior off via a command-line argument, you can't rely on the default behavior anyway. So that's why the documentation says that class and struct destructors are not guaranteed to be invoked by the GC.