On 05/30/12 07:55, Greg Ercolano wrote:
> On 05/29/12 19:26, David Currie wrote:
>> Consider the following,
>
> When you receive control back from Fl::run(), your program
> is supposed to exit.
>
> When you hit ESC, fltk has already deleted the widgets.
> Doing the delete's outside the Fl::run() is redundant,
> causing the undefined behavior; by that time, the pointers
> are wild.
Also, keep in mind if an Fl_Window is destroyed, it's children
are automatically destroyed by FLTK. This means the destructors
are called.
This is why you don't see classes derived from FLTK widgets
that have destructors calling delete on any of the child widgets
its constructor might have made with 'new'.
FLTK handles it internally with the widget's base class dtor.
In general, it's very rare to see FLTK apps calling delete
on widgets.. widget destruction has to be done in a particular
order, because widget allocations may involve hardware as well
as memory, so it's best to leave that ordering for FLTK to handle.
This is why methods like Fl_Group::clear() should be used
if you want to delete all the widgets in a group.
Do that instead of delete.
To close windows, I don't delete them, I just hide() them.
I always let the program exit() handle actually deleting them.
Something you should know about C and C++:
exit()ing a program calls all destructors first before exiting.
_exit()ing a program does NOT call the destructors,
but memory is still freed altogether in one big chunk.
And in general with all OS's: when a program dies, no matter
how it died (killed, exited, crashed), all memory is freed.
The only possible exception I can think of would be shared memory.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
