1. atexit
- Posted by ags <eu at 531pi.co.nz>
Feb 08, 2006
Second Try :_)
After serious digging through the reference manual I still can't find anything
that performs a function similar to C's atexit().
Mainly to Robert Craig, are there any plans to incorporate such a feature into
Euphoria?
Since crash_routine exists, it would seem to me that the functionality would
not be too hard to implement? crash_routine even seems to behave similarly
to atexit 
Gary
2. Re: atexit
ags wrote:
> After serious digging through the reference manual I still can't find anything
> that performs a function similar to C's atexit().
>
> Mainly to Robert Craig, are there any plans to incorporate such a feature into
> Euphoria?
>
> Since crash_routine exists, it would seem to me that the functionality would
> not be too hard to implement? crash_routine even seems to behave similarly
> to atexit
In over 20 years of C programming, I've never used atexit().
But after looking it up, it seems to me it would be very easy
for you to just define a termination routine that you call
at the end of execution of your program. To make it a bit fancier,
and more like C's atexit(), you could append the routine id of
one or more Euphoria routines onto a sequence. Your termination
routine could step through this sequence calling each routine
in turn.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: atexit
Robert Craig wrote:
>
> ags wrote:
> > After serious digging through the reference manual I still can't find
> > anything
> > that performs a function similar to C's atexit().
> >
> > Mainly to Robert Craig, are there any plans to incorporate such a feature
> > into
> > Euphoria?
> >
> > Since crash_routine exists, it would seem to me that the functionality would
> > not be too hard to implement? crash_routine even seems to behave similarly
> > to atexit
>
> In over 20 years of C programming, I've never used atexit().
> But after looking it up, it seems to me it would be very easy
> for you to just define a termination routine that you call
> at the end of execution of your program. To make it a bit fancier,
> and more like C's atexit(), you could append the routine id of
> one or more Euphoria routines onto a sequence. Your termination
> routine could step through this sequence calling each routine
> in turn.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Hello,
For an example of just how handy this can be, see "ReTrack.ew" in my
WinClass library.
Cleanup manager overview:
Procedure "AddCleanup(atom rid)" adds another cleanup routine to the
list. At the end of your program (due to error or normal end) you call
"Cleanup()", which goes though the list of rid's and calls each and
every one of them before allowing the program to abort.
This is very handy because each 'class' (or simply each include file)
could have it's own cleanup routine which takes care of any local
cleanup of memory, handles, fonts handles, etc., that needs to be
deleted or free'd. When "Cleanup()" is called, the rid's get called
one after the other.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
4. Re: atexit
Al Getz wrote:
>
> Robert Craig wrote:
> >
> > ags wrote:
> > > After serious digging through the reference manual I still can't find
> > > anything
> > > that performs a function similar to C's atexit().
> > >
> > > Mainly to Robert Craig, are there any plans to incorporate such a feature
> > > into
> > > Euphoria?
> > >
> > > Since crash_routine exists, it would seem to me that the functionality
> > > would
> > > not be too hard to implement? crash_routine even seems to behave
> > > similarly
> > > to atexit
> >
> > In over 20 years of C programming, I've never used atexit().
> > But after looking it up, it seems to me it would be very easy
> > for you to just define a termination routine that you call
> > at the end of execution of your program. To make it a bit fancier,
> > and more like C's atexit(), you could append the routine id of
> > one or more Euphoria routines onto a sequence. Your termination
> > routine could step through this sequence calling each routine
> > in turn.
> >
> > Regards,
> > Rob Craig
> > Rapid Deployment Software
> > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
> Hello,
>
> For an example of just how handy this can be, see "ReTrack.ew" in my
> WinClass library.
>
> Cleanup manager overview:
>
> Procedure "AddCleanup(atom rid)" adds another cleanup routine to the
> list. At the end of your program (due to error or normal end) you call
> "Cleanup()", which goes though the list of rid's and calls each and
> every one of them before allowing the program to abort.
> This is very handy because each 'class' (or simply each include file)
> could have it's own cleanup routine which takes care of any local
> cleanup of memory, handles, fonts handles, etc., that needs to be
> deleted or free'd. When "Cleanup()" is called, the rid's get called
> one after the other.
>
Hi
Forgive me if I'm wrong, aren't these released when the interpreter exits -
if not wouldn't there be more significant (any) memory leaks?
Chris
>
> Al
>
>
> My bumper sticker: "I brake for LED's"
5. Re: atexit
ChrisBurch2 wrote:
>
> Al Getz wrote:
> >
> > Robert Craig wrote:
> > >
> > > ags wrote:
> > > > After serious digging through the reference manual I still can't find
> > > > anything
> > > > that performs a function similar to C's atexit().
> > > >
> > > > Mainly to Robert Craig, are there any plans to incorporate such a
> > > > feature into
> > > > Euphoria?
> > > >
> > > > Since crash_routine exists, it would seem to me that the functionality
> > > > would
> > > > not be too hard to implement? crash_routine even seems to behave
> > > > similarly
> > > > to atexit
> > >
> > > In over 20 years of C programming, I've never used atexit().
> > > But after looking it up, it seems to me it would be very easy
> > > for you to just define a termination routine that you call
> > > at the end of execution of your program. To make it a bit fancier,
> > > and more like C's atexit(), you could append the routine id of
> > > one or more Euphoria routines onto a sequence. Your termination
> > > routine could step through this sequence calling each routine
> > > in turn.
> > >
> > > Regards,
> > > Rob Craig
> > > Rapid Deployment Software
> > > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
> >
> > Hello,
> >
> > For an example of just how handy this can be, see "ReTrack.ew" in my
> > WinClass library.
> >
> > Cleanup manager overview:
> >
> > Procedure "AddCleanup(atom rid)" adds another cleanup routine to the
> > list. At the end of your program (due to error or normal end) you call
> > "Cleanup()", which goes though the list of rid's and calls each and
> > every one of them before allowing the program to abort.
> > This is very handy because each 'class' (or simply each include file)
> > could have it's own cleanup routine which takes care of any local
> > cleanup of memory, handles, fonts handles, etc., that needs to be
> > deleted or free'd. When "Cleanup()" is called, the rid's get called
> > one after the other.
> >
>
> Hi
>
> Forgive me if I'm wrong, aren't these released when the interpreter exits -
> if not wouldn't there be more significant (any) memory leaks?
>
> Chris
>
> >
> > Al
> >
> >
> > My bumper sticker: "I brake for LED's"
Hi there Chris,
How do you know what's released automatically and what isnt?
Isnt it a good habit to make sure to release anything you use?
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
6. Re: atexit
- Posted by ags <eu at 531pi.co.nz>
Feb 08, 2006
-
Last edited Feb 09, 2006
Al Getz wrote:
>
> How do you know what's released automatically and what isnt?
> Isnt it a good habit to make sure to release anything you use?
I had wondered about this myself. With SDL for example calling SDL_Quit()
frees everything you've allocated, ie:
SDL Library Documentation (C documentation)
-------------------------------------------------------------
SDL_Quit():
Description
SDL_Quit shuts down all SDL subsystems and frees the resources
allocated to them. This should always be called before you
exit. For the sake of simplicity you can set SDL_Quit as your
atexit call, like:
SDL_Init(SDL_INIT_VIDEO|SDL_INIT_AUDIO);
atexit(SDL_Quit);
-------------------------------------------------------------
It doesn't say anything about "Freeing any surfaces created with SDL", which
have no doubt been malloced by the dll.
And I'm pretty sure there are lots of other examples out there where a call to
an external C dll does a malloc(...) and has no idea that your program is about
to quit.
I agree with you that it is good practice to free everything you allocate and
not rely on assumption or possibly incomplete or ambiguous documentation.
Gary
7. Re: atexit
ags wrote:
>
> Al Getz wrote:
> >
> > How do you know what's released automatically and what isnt?
> > Isnt it a good habit to make sure to release anything you use?
>
> I had wondered about this myself. With SDL for example calling SDL_Quit()
> frees everything you've allocated, ie:
>
> SDL Library Documentation (C documentation)
> -------------------------------------------------------------
> SDL_Quit():
> Description
> SDL_Quit shuts down all SDL subsystems and frees the resources
> allocated to them. This should always be called before you
> exit. For the sake of simplicity you can set SDL_Quit as your
> atexit call, like:
>
> SDL_Init(SDL_INIT_VIDEO|SDL_INIT_AUDIO);
> atexit(SDL_Quit);
> -------------------------------------------------------------
>
> It doesn't say anything about "Freeing any surfaces created with SDL", which
> have no doubt been malloced by the dll.
>
> And I'm pretty sure there are lots of other examples out there where a call
> to
> an external C dll does a malloc(...) and has no idea that your program is
> about
> to quit.
>
> I agree with you that it is good practice to free everything you allocate and
> not rely on assumption or possibly incomplete or ambiguous documentation.
>
> Gary
Hi
It is good practice to release memory, I agree.
And some external libraries do need to have memory allocations released
(SDL, OpenGL, Allegro etc)
But, I can't help remember reading somewhere that euphoria released all
its memory allocations, and cleaned up itself, when it exited.
It is good practice to do this explicitly, but this (IMHO) dtracts from
eu's simplicity - you don't have to if you don't want to. To demand that
it be done, is to start to go down C's route of having to do everything
yourself (been there, done that).
Chris
8. Re: atexit
ChrisBurch2 wrote:
> But, I can't help remember reading somewhere that euphoria released all
> its memory allocations, and cleaned up itself, when it exited.
>
> It is good practice to do this explicitly, but this (IMHO) dtracts from
> eu's simplicity - you don't have to if you don't want to. To demand that
> it be done, is to start to go down C's route of having to do everything
> yourself (been there, done that).
>
> Chris
This is one of the things that drove me to Euphoria in the first place (nearly
ten years ago now, wow!). I loved that Euphoria cleanly managed its own
memory. But even with that, memory leaks are some of the hardest bugs to
discover and fix. I have yet to meet a MS product that didn't leak like a
rusty bucket. Even some of our most beloved open source projects like
Firefox are riddled with memory leaks. By making a habit of freeing anything
that's allocated manually, even if Euphoria will take care of it later, is
just plain good programming. And with shared libraries, there is no
guarantee that the Euphoria interpreter is even aware that the memory was
allocated to be able to free it on exit.
Michael J. Sabal
