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.
