> I didn't see any delete being called. I tried to search for > overridden operator new in the FLTK2 doxygen generated > document but didn't find any mention there. > > Is it the case that since fltk::run() is the last command > in the main(), it somehow does not matter?
Why do you think that it *does* matter? You need to consider carefully the lifetime of your widgets, and when you would delete them. You also need to consider fltk's built-in widget management, and then you need to decide if there are any widgets you actually need to delete or not. Here's roughly how it goes: - If you destroy any fltk container widget, e.g. a group or a window, for example, it will attempt to tidy away all of the widgets that it has as children, recursively down the widget tree. So if you delete a group, it will tidy away all the widgets that you have added to, or created inside, that group. - If a widget exists for the entire lifetime of your application, i.e. is created at application start and persists until the application terminates (and actually, this is usually the case) then there's no need to delete it at all! The runtime provided by your OS will (on ALL supported system) recover ALL allocated memory from your application as it terminates, whether you explicitly delete the widgets or not. And it will do this significantly faster then walking the widget tree to delete things explicitly. Short (oft repeated) anecdote follows; Some years ago we had a guy fresh out of university, and one of the introductory tasks he was given was to do some housekeeping on a test framework we had. One of the things he did was add explicit deletion of all the widgets on app termination. This meant that an app that used to close as soon as you hit exit, now took several minutes (yes, minutes, it was a big framework...) to close. The users were Not Happy. He was made to go back and take them all out. Lesson learned. - So... That leaves us with widgets that are deleted dynamically during the life of the application. It is often more efficient just to hide these, and re-use them later in the lifetime of you app (e.g. for pop-ups, it is often more efficient to have one created and hidden, and re-use it for all pop-ups, rather than creating and deleting for every instance.) For widgets where that is not appropriate, then explicit delete is necessary. But these are often few and far between! The only specific gotcha in all this is any widgets you might have subclassed that are using resources that will not be automatically recovered - perhaps you lock some resource - then you need to ensure that you explicitly give that back. But again, this is quite rare in practice. Actually, I'm pretty sure some (all?) of this is covered in the docs, somewhere... It certainly comes up here pretty often, so must be getting into FAQ territory, I'd have thought. SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
