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.
Tradition (in this list) dictates that at this point I trot out my anecdote, so here we go: Some (now many) years ago, we had a placement student, fresh from college, working for us. To get him familiar with the code he was set to refactoring one of the the support tools. Whilst doing this, he added explicit deletes for every widget that was created with new, because that was what they were taught at school.
This made absolutely no difference whatsoever to the runtime behaviour of the program - but it did trigger a flood of complaints from the end-users.
The previous version of this tool would exit "instantly" when it was closed.
The "improved" version would take "several minutes" (well, long enough for the users to notice and complain, anyway!), as it trudged it's way through all the explicit destructor stages.
He was made to go back and take out the explicit destructors, and was enlightened.
The point being that explicitly deleting everything that is "new" is not always necessary, and can have surprising negative consequences in some cases.
