On Tuesday, 3 July 2018 at 14:42:58 UTC, Flaze07 wrote:
On Tuesday, 3 July 2018 at 14:32:01 UTC, Mike Parker wrote:
Resources allocated for the process will be released on exit.
I see...but it is dependant on the OS right ? because I have
seen other stuff relating to malloc as well, there are some out
there that said that there is no need to free any more because
the OS ( in this case windows ) will handle it
As far as I know, this is true on every operating system and has
always been true as long as I've been programming. The OS
allocates resources for the process and doles them out when you
request them, so of course it cleans it all up when you're done.
Things can get buggy when you're doing multithreading, or
spawning new processes (with e.g. fork()), as you can sometimes
wind up with zombie threads that cause the process to not
actually exit, or zombie processes that keep going in the
background, taking up resources.
But in general, yes, the OS will clean up behind you. You only
have to worry about leaks when your application is long-lived,
e.g. servers, text editors, games. If you're making a game and
you aren't releasing resources when they're no longer needed,
then your memory usage will keep going up the longer the game
runs.
DMD is a good example, too, even though it's a short-lived
program. It actually never releases any memory it allocates,
which is one part of its compilation speed story. That's just
fine, until you start compiling template/CTFE/mixin-heavy code.
Then it becomes a disadvantage as memory usage can ratchet up
real quick.
When I was learning C, it actually was drilled into my head that
every resource allocation must have a corresponding deallocation,
from the beginning to the end, and I faithfully implemented
things that way for years to the extent that early versions of
Derelict actually unloaded shared libraries in static
destructors. However, the reason that was pushed so strongly is
because it's so easy to forget to free resources during runtime
in C, causing leaks and other bugs to crop up, that it's best to
be religious about it so that you don't forget. But it's
absolutely not necessary to go through and release every single
allocated resource *at shutdown*.
That said, the GC in D runs when main exits anyway, so the
destructor in your example will be called. That's why I warned
earlier about it being nondeterministic. For example, if you have
a Texture instance that depends on the context of the
RenderWindow, but the RenderWindow's destructor runs first, you
could potentially see a crash on exit depending on the
implementation of DSFML, SFML, and the system graphics driver.
