Re: Try/Catch
- Posted by Spock Feb 17, 2015
- 3946 views
Well, maybe I've been mistaken but I thought that all the bits of manually & OS allocated memory (some possibly obtained prior to the original calling point [EDIT: Relevant?]) would require a huge effort to clean up automatically. I will happily accept being proved wrong.
It depends on how you allocate them. There's an optional parameter in allocate() that will free the memory once the returned atom's reference count goes to zero. Other resources can use this, too, e.g., open() can automatically close files for you, too. The memory (all normal euphoria data) used by maps from std/map.e are automatically cleaned up.
This is one of those features of 4.0 that I don't want to live without.
Matt
Automatically freeing allocated memory is pretty cool. It doesn't really solve the problem, though.
If an allocation originates outside the routine (eg, in my fast string allocator or my dib32 library or font library etc.. which are used a lot in my programs) there is now direct exposure to memory leaks should an exception occur when the prgram is using them.
What about external accesses to, eg, Windows routines? Many of these follow the pattern:
Get resource (memory, handle, DC, etc..)
Do something with it
Return resource
The same pattern might occur in a 3rd party dll. Eg, the one I use for wave/sound control.
I can now forget about my planned JIT ASM compiler too.
So: Graphics, Fonts, Sound, ASM, Printing, other Windows ops have now been exposed to memory risks should an exception occur while they are being used.
However, if I only allocate & free the memory inside some routine, making sure not to indadvertently cause a double reference, and if I don't access any Windows stuff or any other DLL stuff, then there will be no problem.
Am I overstating the danger here ?!
Spock
