On Mon, Apr 25, 2022 at 01:28:01PM +0000, Alain De Vos via Digitalmars-d-learn wrote:
> Could thc or hboehm provide solutions ?

In general, GC (of any kind) does not (and cannot) guarantee the order
objects will be collected in. So in the dtor, you cannot assume that any
objects you depend on still exist (they may have already been
collected).

There is also no guarantee that the object will *ever* get collected: in theory, the GC may only collect just enough to make space for further allocations, it's not obligated to collect *everything* that's collectible. Or the collection might not take place before the end of the program -- the GC may skip the final collection because it knows the OS will reclaim everything automatically anyway.

Basically, deterministic destruction and GC are antithetical to each other, and trying to have both is the road to trouble. If you wish to have deterministic destruction, don't use the GC; use RAII or reference counting instead.


T

-- 
What do you mean the Internet isn't filled with subliminal messages? What about all those buttons marked "submit"??

On 4/25/22 16:02, frame wrote:
> On Monday, 25 April 2022 at 02:07:50 UTC, Ali Çehreli wrote:
>> >      import core.memory: GC;
>>      GC.free(GC.addrOf(cast(void *)(i.ptr)));
>> That is wrong because you did not allocate that address yourself.
>
> Hmm? The GC did allocate here(?)

Yes. I still don't understand the need to free GC memory explicitly. I can understand GC.collect() but not the memory of a specific array.

>> On 4/24/22 17:26, Salih Dincer wrote:
>>
>> >    MEM.free(i.ptr);
>> >    // You don't need to addrOf(cast(void*)i)
>
> Wrong.

You are right. I missed the fact that addrOf is a GC function.

Ali

On Monday, 25 April 2022 at 14:25:17 UTC, H. S. Teoh wrote:
> On Mon, Apr 25, 2022 at 01:28:01PM +0000, Alain De Vos via Digitalmars-d-learn wrote:
>> Could thc or hboehm provide solutions ?
>
> In general, GC (of any kind) does not (and cannot) guarantee the order
> objects will be collected in. So in the dtor, you cannot assume that any
> objects you depend on still exist (they may have already been
> collected).
>
> There is also no guarantee that the object will *ever* get collected: in theory, the GC may only collect just enough to make space for further allocations, it's not obligated to collect *everything* that's collectible. Or the collection might not take place before the end of the program -- the GC may skip the final collection because it knows the OS will reclaim everything automatically anyway.
>
> Basically, deterministic destruction and GC are antithetical to each other, and trying to have both is the road to trouble. If you wish to have deterministic destruction, don't use the GC; use RAII or reference counting instead.
>
>
> T

When you can foresee a "maximum size" , you can create "deterministic" stack objects.

```
class C {
	@nogc this(){}
	@nogc this(int dummy){};
	@nogc int[3] fixarr=new int[3];
}//C

@nogc void myfun(){
	int a;
	scope c = new C();
	scope c2 = new C(5);
}//myfun

void main(){
	myfun();
}//main

```

It's just the variable length arrays which are "problematic". Feel free to elaborate.