GC vs. Manual Memory Management Real World Comparison

[Rob T]

On Saturday, 27 October 2012 at 01:03:57 UTC, Rob T wrote:
> On Friday, 26 October 2012 at 23:10:48 UTC, bearophile wrote:
>> Rob T:
>>
>>> Is this happening with dmd 2.060 as released?
>>
>> I'm using 2.061alpha git head, but I guess the situation is 
>> the same with dmd 2.060. The code is linked in my post, so 
>> trying it is easy, it's one small module.
>>
>> Bye,
>> bearophile
>
> I tried it with dmd 2.60 (released), and gdc 4.7 branch. I 
> tried to check if memory was being freed by creating a struc 
> destructor for JavaMemoryTrade, but that did not work as 
> expected, leading me down the confusing and inconsistent path 
> of figuring out why destructors do not get called when memory 
> is freed.
>
> Long story short, I could not force a struct to execute its 
> destructor if it was allocated on the heap unless I used 
> delete. I tried destroy and clear, as well as GC.collect and 
> GC.free(), nothing else worked.
>
> Memory heap management as well as struct destructors appear to 
> be seriously broken.
>
> --rt

OK my bad, partially.

Heap allocated struct destructors will not get called using clear 
or destroy unless the struct reference is manually dereferenced. 
I got confused that class references behave differently than heap 
allocated struct references. I cannot be the first person to do 
this, and it must happen all the time. The auto dereferencing of 
a struc pointer when accessing members may be nice, but it makes 
struct pointers look exactly like class references, which will 
lead to mistakes.

I do get the concept between classes and structs, but why does 
clear and destroy using a struct pointer not give me a compiler 
error or at least a warning? Is there any valid purpose to clear 
or destroy a pointer that is not dereferenced? Seems like a bug 
to me.

--rt