www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - struct destructor

reply Alain De Vos <devosalain ymail.com> writes:
When I do a "new" in a struct constructor to assign to a member 
variable of this struct, what do i write in the same struct 
destructor to free the memory ?
May 15
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 15 May 2021 at 16:52:10 UTC, Alain De Vos wrote:
 When I do a "new" in a struct constructor to assign to a member 
 variable of this struct, what do i write in the same struct 
 destructor to free the memory ?
If you used `new` the garbage collector is responsible for it.
May 15
parent reply Alain De Vos <devosalain ymail.com> writes:
On Saturday, 15 May 2021 at 16:53:04 UTC, Adam D. Ruppe wrote:
 On Saturday, 15 May 2021 at 16:52:10 UTC, Alain De Vos wrote:
 When I do a "new" in a struct constructor to assign to a 
 member variable of this struct, what do i write in the same 
 struct destructor to free the memory ?
If you used `new` the garbage collector is responsible for it.
Can I send a kind message to the garbage collector to please free that speficic memory at that time specified ?
May 15
parent reply Alain De Vos <devosalain ymail.com> writes:
Feature request, a function old which does the opposite of new, 
allowing deterministic,real-time behavior and memory conservation.
May 15
next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Saturday, 15 May 2021 at 17:55:17 UTC, Alain De Vos wrote:
 Feature request, a function old which does the opposite of new, 
 allowing deterministic,real-time behavior and memory 
 conservation.
You can use [object.destroy](https://dlang.org/phobos/object.html#.destroy) to destruct, and [GC.free](https://dlang.org/phobos/core_memory.html#.GC.free) to free memory allocated with `new`.
May 15
next sibling parent reply Alain De Vos <devosalain ymail.com> writes:
Thanks, good idea but,
It does not initiate a GC cycle or free any GC memory.
May 15
next sibling parent Alain De Vos <devosalain ymail.com> writes:
Sorry free does , indeed.
May 15
prev sibling parent reply cc <cc nevernet.com> writes:
On Saturday, 15 May 2021 at 18:24:19 UTC, Alain De Vos wrote:
 Thanks, good idea but,
 It does not initiate a GC cycle or free any GC memory.
Personally I wish D would re-implement "delete" and make it "just work" like one would assume, but from what I've seen there have been many many debates on that and it isn't going to happen. If the goal is to absolutely squeeze the GC back down after using new or dynamic arrays, I find destroy + GC.free often fails to do the trick (e.g. GC.stats.usedSize remains high). For whatever reason (I glanced at the code but haven't found the magic yet), the deprecated __delete does a more thorough job of making sure that memory actually gets "given up" on a collection cycle (particularly if you invoke it manually with `GC.collect(); GC.minimize();`. Presumably this isn't a desirable coding behavior, though. In my field (games), I do do something like this after initially loading the data to free up all the unused clutter and scaffolding, but it's very slow to call it every frame if you've been using the GC to create and delete game entities. So like Adam says, standard C malloc/free are probably the best way to go in this case. ```d import core.stdc.stdlib; import core.lifetime; class Foo {} auto foo = cast(Foo) malloc(__traits(classInstanceSize, Foo)); emplace!Foo(foo, /*constructor args*/); // ... destroy(foo); free(cast(void*)foo); ``` Another alternative is something like the memutils library: https://code.dlang.org/packages/memutils ```d class Foo {} auto foo = ThreadMem.alloc!Foo(/*constructor args*/) ThreadMem.free(foo); // calls destroy for you, but can still destroy manually ``` You'll still need to be very careful about any GC mem that gets allocated within a class like this as it can get lost into the ether and cause permanent bloat. I've been doing a lot of iteration tests lately across a whole bunch of different memory management solutions and the state of discrete memory management in D for gaming applications is.. not great. I love D, but for all that it's designed to help reduce programmer error, it goes the opposite way once you start breaking free of the GC and having to be extra careful tiptoeing around its edges. Unfortunately I don't like doing the pure nogc/betterC route either, the GC is still really handy to have when you need it (and are aware that it's being used!), but GC collections during high intensity gaming are unacceptable (and deferring them to some later point doesn't help much either). Fair warning, I'm not one of the D elite with a deep guru-level knowledge of just precisely how everything is operating under the hood, so part of this may come down to learning better practices, but a problem I see IMO is a perceived lack of support or sympathy for coders who want to use the GC when it's nice, but not have it smack them in the face when it isn't. Even with the various articles and forum threads explaining D's memory options, there's still a general air of "You really should just be using the GC, so enjoy your no-man's land, you're on your own." Whether this is only an unfair perception and matter of documentation, or something that actually needs to be addressed in the language, is beyond simply me to decide, but I think a lot of outsiders coming into D may run into the same situation.
May 16
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 16 May 2021 at 08:04:06 UTC, cc wrote:
 If the goal is to absolutely squeeze the GC back down after 
 using new or dynamic arrays, I find destroy + GC.free often 
 fails to do the trick (e.g. GC.stats.usedSize remains high).
destroy + GC.free has a quirk - GC.free only works on what GC.malloc returns, a base pointer, NOT what `new` returns. The documentation says this but it is a subtle detail easy to miss... ...including by other stdlib authors. __delete is simply incorrectly implemented and an accidental no-op in most cases! https://issues.dlang.org/show_bug.cgi?id=21550 The documentation that describes how to migrate away from `delete` made this same error. I tracked down the problem but wasn't 100% sure about the fix. Adding the GC.baseOf thing works for me but i didn't upstream since idk if it works for everyone else. maybe i should just do it though.
May 16
next sibling parent mw <mingwu gmail.com> writes:
On Sunday, 16 May 2021 at 11:42:19 UTC, Adam D. Ruppe wrote:
 On Sunday, 16 May 2021 at 08:04:06 UTC, cc wrote:
 If the goal is to absolutely squeeze the GC back down after 
 using new or dynamic arrays, I find destroy + GC.free often 
 fails to do the trick (e.g. GC.stats.usedSize remains high).
destroy + GC.free has a quirk - GC.free only works on what GC.malloc returns, a base pointer, NOT what `new` returns. The documentation says this but it is a subtle detail easy to miss...
Right, we should always enforce malloc/free, new/delete are used in pairs, but not mixing them. Un-deprecate `delete`?
May 16
prev sibling next sibling parent frame <frame86 live.com> writes:
On Sunday, 16 May 2021 at 11:42:19 UTC, Adam D. Ruppe wrote:
 On Sunday, 16 May 2021 at 08:04:06 UTC, cc wrote:
 I tracked down the problem but wasn't 100% sure about the fix. 
 Adding the GC.baseOf thing works for me but i didn't upstream 
 since idk if it works for everyone else.

 maybe i should just do it though.
I don't know it it is really affected but there is also a GC.free with just .ptr in AAs implementation in resize(). As I am understanding this issue it would lead to memory leaks on buckets (on re-used AA or if it cannot be set to null) with many items that are shrinking or growing over time. And any pointer in the buckets entry would be seen alive too? I know that are edge cases but still... maybe you could have a look at these things in the runtime source too.
May 20
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 16 May 2021 at 11:42:19 UTC, Adam D. Ruppe wrote:
 On Sunday, 16 May 2021 at 08:04:06 UTC, cc wrote:
 [...]
destroy + GC.free has a quirk - GC.free only works on what GC.malloc returns, a base pointer, NOT what `new` returns. The documentation says this but it is a subtle detail easy to miss... ...including by other stdlib authors. __delete is simply incorrectly implemented and an accidental no-op in most cases! https://issues.dlang.org/show_bug.cgi?id=21550 The documentation that describes how to migrate away from `delete` made this same error. I tracked down the problem but wasn't 100% sure about the fix. Adding the GC.baseOf thing works for me but i didn't upstream since idk if it works for everyone else. maybe i should just do it though.
I'd say do it and then >9000 devs will comment, possibly leading to the truth. No comments = it's already acceptable.
May 20
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 15 May 2021 at 18:15:24 UTC, Dennis wrote:
 On Saturday, 15 May 2021 at 17:55:17 UTC, Alain De Vos wrote:
 Feature request, a function old which does the opposite of 
 new, allowing deterministic,real-time behavior and memory 
 conservation.
You can use [object.destroy](https://dlang.org/phobos/object.html#.destroy) to destruct, and [GC.free](https://dlang.org/phobos/core_memory.html#.GC.free) to free memory allocated with `new`.
Specifically you wanna do: ``` .destroy(*ptr); GC.free(GC.addrOf(ptr)); ```
May 15
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 15 May 2021 at 17:55:17 UTC, Alain De Vos wrote:
 Feature request, a function old which does the opposite of new, 
 allowing deterministic,real-time behavior and memory 
 conservation.
You're best off doing malloc+free if you want complete control though.
May 15
next sibling parent Alain De Vos <devosalain ymail.com> writes:
I'll try first the first tip of Adam, here the code,

```
import std.stdio:writeln;
import core.memory: GC;
void myfun(){
class C{
	int[10000] x;
	}//class C
	
struct S {
	C c=null;
	 disable this();

	this(int dummy) {
		c=new C();
		writeln("Constructor");
		};//Constructor

	~this(){
		writeln("Destructor");
		.destroy(c);
		void * address=GC.addrOf(cast(void *)c);
		GC.free(address);
		};//destructor
}//struct S
S mys=S(0);
};//myfun()

void main(){
	myfun();
};//main
```
May 15
prev sibling parent mw <mingwu gmail.com> writes:
On Saturday, 15 May 2021 at 18:26:08 UTC, Adam D. Ruppe wrote:
 On Saturday, 15 May 2021 at 17:55:17 UTC, Alain De Vos wrote:
 Feature request, a function old which does the opposite of 
 new, allowing deterministic,real-time behavior and memory 
 conservation.
You're best off doing malloc+free if you want complete control though.
You can use the heapAlloc / heapFree pair: https://wiki.dlang.org/Memory_Management#Explicit_Class_Instance_Allocation Which I added to my package here :-) https://code.dlang.org/packages/jdiutil https://github.com/mingwugmail/jdiutil/blob/master/source/jdiutil/memory.d
May 15