Understanding the GC

[Steven Schveighoffer]

On Fri, 01 Feb 2013 10:46:11 -0500, monarch_dodra <monarchdodra at gmail.com>  
wrote:

> On Friday, 1 February 2013 at 15:37:25 UTC, Steven Schveighoffer wrote:

>> This is a GC limitation, since structs do not contain a pointer to  
>> their typeinfo like classes do, and there is no provision for storing a  
>> pointer to the typeinfo of a block.  It could be fixed by a more  
>> precise GC.  AIUI, we have something like that coming, but I've been  
>> hearing that for more than a year ;)
>>
>> -Steve
>
> Oh. Wow. That's news to me.
>
> I'd say as long as you don't new your structs, you are fine, but  
> apparently, dynamic arrays don't clean up after themselves either (!)  
> That's a whole other ballgame...

Dynamic arrays do clean up the array memory.  For arrays of objects, or  
arrays of structs that have only GC-based resources, those items are also  
individually cleaned up by the GC.  But if you had, for instance, an array  
of self-closing file descriptor structs, those would NOT be cleaned up by  
the GC.

> That's quite scary. It brings back into question a few of my  
> implementations...

People should definitely be aware of this limitation.  It usually is not  
of any concern because it is rare to have a struct that has a non-GC  
reference on the heap.  But it is something to be aware of.

Note that if your struct is a *member* of a class, it's destructor will be  
called because it's destructor is called as part of the object's  
destructor.  But this isn't always what you want!

I think people have been harping on this limitation of File (and  
reference-counted structs in general) for a long time.  There is a  
bugzilla issue for it somewhere.

-Steve