Clarify that user sometimes must delete if managed [master]
[ see also !3 (merged) ]
I don't think I was fully aware of this until I noticed it incidentally during gtkmm#33 (comment 341220) in the
gtkmm documentation. I think I took most of my assumptions about
gtkmm-documentation instead, which doesn't mention this at all.. and I think it is really worth being clear about, so future readers won't end up with leaky code like I now have to go and fix.
container.ccgremembers whether the object was originally un-floated by
Gtk::manage()and, if so, restores that state during
Container.remove(), with the result that the removed widget is not deleted, as it would be in GTK+, but instead it is re-floated and requires the user to deal with (e.g. to add it to some other container or to finally call
This is documented in
container.hgbut nowhere that I can see in our tutorial, and I think it is worth mentioning here, since it is not completely intuitive: users might otherwise think that the fact manage() delegates lifetime management to the
Containermeans they get back the same behaviour of C widgets, i.e. that
remove()would cause destruction, but of course that is not the case, and we might thus encourage leaks.
So mention that
manage()only relieves the user of the burden of calling
deleteif they add the widget to a parent and do not remove it later, in both the Memory Management section and the part about deleting wrappers.