Examples create a ton of dynamic visual objects via new but are never deleted!!!

[Juan Dent]

Hi,

Following the Tabs example, the main() function creates a bunch of GUI objects using new but never deletes them!! 

This is a bad approach!!

Please enlighten me!

Thanks

Juan

[Albrecht Schlosser]

You may not want to hear (read) this because your teachers taught you a
different story, but ...

Deleting GUI elements at the end of the program is not only not
necessary, it can also slow down your program when someone clicks the
"Exit" button or menu. Executing destructors takes some time, and
normally nobody wants to wait for that until the program _really_ exits.
Note that this is only true if the d'tors don't need to reset any other
program state like open files or such. If your widgets hold data that
need to be flushed at exit, running the d'tors may be essential.

That said, all resources required by GUI elements are free'd at program
exit anyway, so there's no need to do this explicitly.

And, BTW, if you really wanted to delete all GUI elements then you could
just 'delete foo_window;' after Fl::run() returns. This would delete all
GUI elements included in foo_window (see Fl_Window docs).

Something like this would do the trick:

foo_window->show(argc, argv);
Fl::run();
delete foo_window;
return 0;
}

In this case the CPU time difference can't be measured reliably, but
anyway: it's useless to do this, and we don't recommend this in the
general case. See exceptions above.

[Greg Ercolano]

On 09/29/16 13:11, Juan Dent wrote:
> Following the Tabs example, the main() function creates a bunch of GUI objects using new but never deletes them!!

The widgets are destroyed in the proper order when
the program closes.

FLTK widgets handle their own destruction on exit.
This is so that the widgets destroy themselves in the proper order.

The only time you yourself should destroy widgets is if you have
an app that needs to remain running while it creates and destroys
widgets.

For instance, an app that has a main UI that has small memory use,
but periodically opens a widget hierarchy that has a large footprint..
and when the user closes that widget hierarchy, it should all go away,
freeing up memory for the process to be able to use for other purposes.

In such a case you can delete the top level widget, and that will trigger
the entire widget hierarchy (children) to destroy themselves.

Normally you don't need to do this though; when widgets aren't
being used, or are used occasionally (like file browsers or dialogs),
you leave them allocated and just show() or hide() them as needed.

> This is a bad approach!!
> Please enlighten me!

This comes up a lot from folks who are fresh to programming
and have learned about new and delete, and that all new's should
be deleted, which is fine to prevent memory leaks within a program's
execution, but doesn't matter if the items last the length of the
program until it exits, which is the case with most gui elements.

Understand that when a process exits, all memory is automatically freed.

There's no such thing as a program leaking memory when it exits;
all memory it allocated with new/malloc are freed by the OS.

In GUI apps (such as tabs), there's no reason to delete anything
because the program UI remains at all times until the program is
closed, and at the point the process's memory associated with all
the widgets is freed cleanly and in the proper order.