Managing malloced memory

anon anon at anon.com
Mon Oct 11 10:53:15 UTC 2021


On Thursday, 7 October 2021 at 11:55:35 UTC, Steven Schveighoffer 
wrote:
> The GC is technically not required to free any blocks ever. But 
> in general, it does.
>
> When it does free a struct, as long as you allocated with 
> `new`, it should call the dtor.

In practice when I played around with it, destructor always got 
called by GC. But: https://dlang.org/spec/class.html#destructors 
says at point 6:
>The garbage collector is not guaranteed to run the destructor 
>for all unreferenced objects.
Is it the same for structs or are these destructors guaranteed to 
be called? Would it be suitable to clean up tempfiles with 
GC-managed structs?

> Just FYI, you should reply to the posts that you quote, or at 
> least copy the "X Y wrote" line so people understand the thread.

Alright. If I want to reply to multiple people, should I post 
twice or quote both in the same post?

> The destructor is called once per copy. This is why disabling 
> copy prevents double freeing.
>
> There are cases where the compiler avoids calling the 
> destructor because the instance is moved. Such as returning a 
> newly constructed item (typically referred to as an "rvalue"), 
> or passing a newly constructed item into a parameter. The 
> parameter will be destroyed, but the call-site constructed item 
> will not.
>
> e.g.:
>
> ```d
> struct S
> {
>    int x;
>    ~this() { writeln("destructor called"); }
> }
>
> void foo(S s) {
>
>    // destructor for s called here
> }
>
> S makeS(int x)
> {
>    return S(x); // no destructor called here.
> }
>
> void main()
> {
>    foo(S(1)); // no destructor called for this rvalue
>    auto s = makeS(1);
>    // destructor for s called here.
>    foo(makeS(1)); // only one destructor called at the end of 
> foo
> }
> ```
Is there any reference for exactly how these rules apply, or is 
this implementation defined? The 
[specification](https://dlang.org/spec/struct.html#struct-destructor) says that destructors are called when objects go out of scope. Your examples seem to suggest that this is untrue in some cases.


More information about the Digitalmars-d-learn mailing list