On Mar 31, 2014, at 10:30 AM, Krzysztof Kosiński wrote:
2014-03-31 17:08 GMT+02:00 Markus Engel <p637777@...1081...>:
Hi, if you used references or pointers, where would you get the actual widgets from? "newing" them? Then please make sure that every single widget is correctly deleted no matter what happens. You probably don't want to do that.
With Gtk::manage() this task is actually rather simple - the widget is deleted automatically when its container is deleted. You just need to make sure you don't create any orphan widgets which are not actually added to any container.
That being said, I'm not sure if there is a compelling reason to change from one approach to the other.
Krzysztof is right in regards to Gtk::manage() and also the bigger issue about usefulness.
Another danger with using Gtk::manage() only, however, is if your code holds pointers to the objects. If their parents go out of lifecycle the would be deleted and code left with invalid dangling pointers. Writing the code to avoid such problems is something to keep in mind. As long as that is addressed, it does end up much better than the alternative Markus pointed out about having to manually delete everything.
Now moving #includes into the .cpp to avoid excessive Gtkmm includes is not going to be too useful for us (since those hardly ever change, etc.). However... for code *consuming* our header it can be a big gain. By moving members to be parts of a private struct/class that is not directly in the .h, the internal implementation details are not exposed. Leaving only the public API in the header first of all will make the class easier to use, easier to maintain, and in general increases the encapsulation which is a good software engineering principal.
Also, this means that whenever the details of a given dialog are changed (members added, types tweaked, etc.) they only affect a single .cpp instead of dozens of other files that directly or indirectly have included the initial header. During a developer's normal workday this savings makes working in areas go much faster, and shorter incremental builds pay off in developer productivity.
Of course, how to specifically implement this problem needs some annotated examples so that we can clearly see the different trade-offs. Since most guides on good C++ engineering recommend this encapsulation we should take a look at it.