On Monday, 26 September 2022 at 02:14:08 UTC+1 Pierre wrote:

For FLTK 1.3.8,

I'v seen documentation and discussion show how easy it is to dynamically create widgets as in:

       Fl_Button *fluidButton = new Fl_Button(25, 80, 70, 50, "button2");

but did not see much code where those dynamically allocated objects are freed (deleted) in destructors.

I would assume that the objects allocated by ``new`` statements would have to be freed by corresponding ``delete`` statements in destructors.  I can understand that it's not that important in the main() function of a program since once it terminates all process memory will be reclaimed by the C++ library code and process termination but for other classes that might be located else where and could be created during the execution a long-running program I would think that not freeing the widgets is just bad practice and memory leaks.

Am I missing something?  

The key point is that the fltk container widgets (typically groups or windows, or derivatives thereof) will reap all of their children when they are themselves destroyed.

So if a window is deleted or goes out of scope, it will also remove all of its children. (Though if you want a widget to persist after its parent container is removed you can explicitly remove the child widget from the parent before disposing of the parent, of course...) 

This is in the docs somewhere - I know I've read it!

(A rider to this is that you sometimes need to be aware NOT to delete widgets that have already been deleted by their parent...)

Another point is that it is often, at least with fltk, cheaper to hang onto "temporary" widgets you have created, to use them again later, rather than instantiating them and deleting them all the time as you go along, since many "temporary" widgets actually get used many times during the lifetime of the program, and the retained footprint of a hidden widget in fltk is generally pretty small.

So, it turns out that explicitly deleting the widgets may not be needed, in many cases - there will always be cases where a widget really is transient and used only once, and in that case deleting it explicitly will reduce memory usage and is correct, but there are a lot of cases where just hanging on to the widget and using it again later is faster and cheaper overall.