digitalmars.D.learn - Why dtor are not executed when removing a struct from associative
- Learner (20/20) Sep 20 2021 I was expecting something like going out of scope for that
- Tejas (29/49) Sep 20 2021 I think it *is* being called:
- Tejas (3/33) Sep 20 2021 Oh dear, I made a mistake :(
- Tejas (38/75) Sep 20 2021 To make up for my mistake:
- Steven Schveighoffer (10/13) Sep 20 2021 Do not call `__delete` here, use `destroy`. `__delete` will attempt to
- Tejas (48/64) Sep 20 2021 It doesn't succeed when object is stack allocated, otherwise it
- Steven Schveighoffer (9/29) Sep 21 2021 Oh! I missed that subtle change. I thought you were deleting a pointer
- jfondren (16/36) Sep 20 2021 This looks to me like a bug, as
- Steven Schveighoffer (20/43) Sep 20 2021 AA values are not destroyed on removal. For a simple reason -- someone
- =?UTF-8?Q?Ali_=c3=87ehreli?= (38/40) Sep 20 2021 If you are sure the element can be destroyed, you can call destroy():
I was expecting something like going out of scope for that
```(D)
import std.stdio;
struct S
{
~this()
{
writeln("S is being destructed");
}
}
void main()
{
S[int] aa;
aa[1] = S();
aa.remove(1);
writeln("Why no dtor call on remove?");
}
I was expecting S instance dtor called
S is being destructed
```
Sep 20 2021
On Monday, 20 September 2021 at 12:23:00 UTC, Learner wrote:
I was expecting something like going out of scope for that
```(D)
import std.stdio;
struct S
{
~this()
{
writeln("S is being destructed");
}
}
void main()
{
S[int] aa;
aa[1] = S();
aa.remove(1);
writeln("Why no dtor call on remove?");
}
I was expecting S instance dtor called
S is being destructed
```
I think it *is* being called:
```d
import std.stdio;
struct S
{
int a;
this(int param){
a = param;
}
~this()
{
writeln("S(",a,") is being destructed");
}
}
void main()
{
S[int] aa;
aa[1] = S(5);
aa.remove(1);
aa[1] = S(10);
//writeln("Why no dtor call on remove?");
}
Output:
S(5) is being destructed
S(10) is being destructed
```
If the destructors were being executed based on the ending of
scope, `S(10)` would have been destroyed first.
Sep 20 2021
On Monday, 20 September 2021 at 13:48:01 UTC, Tejas wrote:On Monday, 20 September 2021 at 12:23:00 UTC, Learner wrote:Oh dear, I made a mistake :( Sorry, shouldn't have commented out the `writeln`[...]I think it *is* being called: ```d import std.stdio; struct S { int a; this(int param){ a = param; } ~this() { writeln("S(",a,") is being destructed"); } } void main() { S[int] aa; aa[1] = S(5); aa.remove(1); aa[1] = S(10); //writeln("Why no dtor call on remove?"); } Output: S(5) is being destructed S(10) is being destructed ``` If the destructors were being executed based on the ending of scope, `S(10)` would have been destroyed first.
Sep 20 2021
On Monday, 20 September 2021 at 14:03:09 UTC, Tejas wrote:On Monday, 20 September 2021 at 13:48:01 UTC, Tejas wrote:To make up for my mistake: In case you still want to delete stuff deterministically despite what Steve said, I suggest you make your `struct` a reference and use `core.memory.__delete`(not recommended to use this carelessly, btw) ```d import std.stdio; import core.memory:__delete; struct S { int a; this(int param){ a = param; } ~this() { writeln("S(",a,") is being destructed"); } } void absoluteRemove(AA, keyType)(AA assArray, keyType key){ __delete(assArray[key]); } void main() { S*[int] aa; aa[1] = new S(5); absoluteRemove(aa, 1); aa[2] = new S(10); absoluteRemove(aa, 2); writeln("Why no dtor call on remove?"); } Output: S(5) is being destructed S(10) is being destructed Why no dtor call on remove? ``` Because `__delete` cannot work on stack allocated objectsOn Monday, 20 September 2021 at 12:23:00 UTC, Learner wrote:Oh dear, I made a mistake :( Sorry, shouldn't have commented out the `writeln`[...]I think it *is* being called: ```d import std.stdio; struct S { int a; this(int param){ a = param; } ~this() { writeln("S(",a,") is being destructed"); } } void main() { S[int] aa; aa[1] = S(5); aa.remove(1); aa[1] = S(10); //writeln("Why no dtor call on remove?"); } Output: S(5) is being destructed S(10) is being destructed ``` If the destructors were being executed based on the ending of scope, `S(10)` would have been destroyed first.
Sep 20 2021
On 9/20/21 10:22 AM, Tejas wrote:In case you still want to delete stuff deterministically despite what Steve said, I suggest you make your `struct` a reference and use `core.memory.__delete`(not recommended to use this carelessly, btw)Do not call `__delete` here, use `destroy`. `__delete` will attempt to deallocate the block, which likely will fail since the key comes before the value, and GC.free on an interior pointer (I think) fails. But if it succeeded, it would not be good. This leaves a dangling pointer inside the AA. Rehashing the AA likely would result in a memory corruption. If you use destroy, the destructor will be called by the GC as well, but a struct should properly handle destroying the .init value. -Steve
Sep 20 2021
On Monday, 20 September 2021 at 18:13:53 UTC, Steven Schveighoffer wrote:On 9/20/21 10:22 AM, Tejas wrote:It doesn't succeed when object is stack allocated, otherwise it works; that's why I suggested changing `S` to `S*`. As for why I didn't use `destroy`, I assumed OP wanted to free the memory. If they just want the destructor to run, then `destroy` is better(and safer). (Also, `hashOf` seems to work just fine even after using `__delete`, not that it means using `__delete` should ever be recommended over using `destroy`) ```d import std.stdio; import core.memory:__delete; struct S { int a; this(int param){ a = param; } ~this() { writeln("S(",a,") is being destructed"); } } void absoluteRemove(AA, keyType)(AA assArray, keyType key){ //assArray.remove(key); __delete(assArray[key]); } void main() { S*[int] aa; aa[1] = new S(5); absoluteRemove(aa, 1); writeln(aa.hashOf); aa[2] = new S(10); writeln(aa.hashOf); absoluteRemove(aa, 2); writeln(aa.hashOf); writeln("Why no dtor call on remove?"); } Output: S(5) is being destructed 2451737883 5104465521 S(10) is being destructed 5378492086 Why no dtor call on remove? ```In case you still want to delete stuff deterministically despite what Steve said, I suggest you make your `struct` a reference and use `core.memory.__delete`(not recommended to use this carelessly, btw)Do not call `__delete` here, use `destroy`. `__delete` will attempt to deallocate the block, which likely will fail since the key comes before the value, and GC.free on an interior pointer (I think) fails. But if it succeeded, it would not be good. This leaves a dangling pointer inside the AA. Rehashing the AA likely would result in a memory corruption. If you use destroy, the destructor will be called by the GC as well, but a struct should properly handle destroying the .init value. -Steve
Sep 20 2021
Steven Schveighoffer <schveiguy gmail.com> On 9/21/21 2:06 AM, Tejas wrote:On Monday, 20 September 2021 at 18:13:53 UTC, Steven Schveighoffer wrote:Oh! I missed that subtle change. I thought you were deleting a pointer to S that lives in a `S[int]`. I still recommend against this because you can easily get a dangling pointer that way. Aside from that, if you are careful enough not to store a retrieved S* from the aa, you could do that. It will incur one extra allocation per element, which is not ideal. Using destroy should be the most effective and safest mechanism. -SteveOn 9/20/21 10:22 AM, Tejas wrote:It doesn't succeed when object is stack allocated, otherwise it works; that's why I suggested changing `S` to `S*`.In case you still want to delete stuff deterministically despite what Steve said, I suggest you make your `struct` a reference and use `core.memory.__delete`(not recommended to use this carelessly, btw)Do not call `__delete` here, use `destroy`. `__delete` will attempt to deallocate the block, which likely will fail since the key comes before the value, and GC.free on an interior pointer (I think) fails. But if it succeeded, it would not be good. This leaves a dangling pointer inside the AA. Rehashing the AA likely would result in a memory corruption. If you use destroy, the destructor will be called by the GC as well, but a struct should properly handle destroying the .init value.
Sep 21 2021
On Monday, 20 September 2021 at 12:23:00 UTC, Learner wrote:
I was expecting something like going out of scope for that
```(D)
import std.stdio;
struct S
{
~this()
{
writeln("S is being destructed");
}
}
void main()
{
S[int] aa;
aa[1] = S();
aa.remove(1);
writeln("Why no dtor call on remove?");
}
I was expecting S instance dtor called
S is being destructed
```
This looks to me like a bug, as
```d
import core.memory : GC;
GC.collect;
```
immediately after the `.remove` will call the struct's destructor.
I only see https://issues.dlang.org/show_bug.cgi?id=20379 as
related, though.
Here's another workaround:
```d
alias purge = (kv, k) { kv[k] = typeof(kv[k]).init; kv.remove(k);
};
```
with the same caveat of the `.init` structs also getting
destructed later, you can use that in place of `.remove`.
Sep 20 2021
On 9/20/21 8:23 AM, Learner wrote:
I was expecting something like going out of scope for that
```d
import std.stdio;
struct S
{
~this()
{
writeln("S is being destructed");
}
}
void main()
{
S[int] aa;
aa[1] = S();
aa.remove(1);
writeln("Why no dtor call on remove?");
}
```
I was expecting S instance dtor called
S is being destructed
AA values are not destroyed on removal. For a simple reason -- someone
might still be referencing it.
```d
struct S
{
int x;
}
void main()
{
S[int] aa;
aa[1] = S(5);
auto sptr = 1 in aa;
sptr.x = 6;
assert(aa[1].x == 6);
aa.remove(1);
assert(sptr.x == 6;
}
```
-Steve
Sep 20 2021
On 9/20/21 5:23 AM, Learner wrote:I was expecting S instance dtor called S is being destructedIf you are sure the element can be destroyed, you can call destroy(): import std.stdio; enum someSpecialInitValue = 777; struct S { int i = someSpecialInitValue; this(int i) { this.i = i; } ~this() { writeln("S with ", i, " is being destructed"); } } void destroyAndRemove(AA, Key)(AA aa, Key key) { auto found = key in aa; if (found) { destroy(*found); aa.remove(key); } } void main() { S[int] aa; aa[1] = S(1); aa.destroyAndRemove(1); writeln("Actually, 2 dtor calls! :)"); } destroy() puts the object to its initial state, which means, it gets destroyed again. That's why there are two destructor calls below for the same object. I used a special value to demonstrate the second destructor is called on the init state: S with 1 is being destructed Actually, 2 dtor calls! :) S with 777 is being destructed Ali
Sep 20 2021