Grk::manage() solves the specific problem of lifetime management for hierarchies of widgets. And it solves it well.
Smart pointers (
shared_ptr in particular) have broader application range, and therefore will be less efficient when used to address this specific problem. Lifetime management for hierarchies of widgets can be solved with
shared_ptr, but it will be:
- not as concise as using
manage() (as you pointed out yourself);
- less efficient in terms of memory usage, since using
shared_ptr's will introduce memory overhead as
shared_ptr memory footprint is going to contribute to your widget's size (as opposed to manage(), which as far as I'm aware uses variables, such as, say
Gtk::Object.referenced_, that are part of your
Widget base class anyways, no matter you use
manage() on it or not); So in case you have significant amount of
Widgets it might become an issue worth considering;
- not as mainstream as using
manage() in Gtk (has quite a few consequences, including clarity and maintainability).
As of idea of favoring
manage() because it is part of C++ Standard, while
Gtk::manage is not - I'm not sure it is going to be a game changer for average application, as by not using
manage() you don't cut your dependency on Gtk anyways. So your application is not going to gain any better portability if you'd go for
I would rather leverage native Gtk API, for sake of clarity and efficiency.
p.s. there is actually a smart pointer
GLib::RefPtr, which can address lifetime management for
Widgets in a manual way. Again, as it is a feature native to GLib it leverages built-in facilities of
Glib::ObjectBase, and therefore more efficient then
shared_ptr for certain applications (e.g. reference to reference counter is not stored in the pointer object, as reference counter is embedded to the object, and therefore
RefPtr is more lightweight than
shared_ptr, which will make a significant difference if you have many pointers to a few objects).