Understanding the GC

[Jeremy DeHaan]

On Wednesday, 30 January 2013 at 10:29:26 UTC, monarch_dodra 
wrote:
> To add to that, you also have to keep in mind that when the 
> program terminates (even legally), instead of running a *full* 
> collect cycle, the program just leaves, and lets the OS clear 
> any allocated memory. This is both faster, and safer.
>
> What this means is that while there is a guarantee that 
> "collection=>destruction", there is no guarantee that actual 
> collection will happen.
>
> If you absolutely must be sure that something allocated gets 
> *destroyed*, either destroy it yourself via an explicit call, 
> or bind it to a stack based RAII scheme, possibly with 
> reference counting.
>

So there is no guarantee at all that a destructor will be called 
even at the end of the program? Because there is an example in 
the book using a class destructor to free allocated data.



I definitely understand now about how not to rely on a destructor 
to free up memory during runtime, but it seems counterintuitive  
to have the ability to write a destructor with no guarantee it 
would ever be called even at cleanup.