Return to Answer

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 shared_ptr over 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 shared_ptr.

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).

Gtk::manage() solves the specific problem of lifetime management for hierarchies of widgets. And it solves it well.

Smart pointers (std::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_ptrs will introduce memory overhead: shared_ptr has a memory footprint of its reference to its reference-count, which will use size - as opposed to manage(), which uses variables such as Gtk::Object.referenced_ that are part of your Widget base class already at all times. So, if you have a significant number of Widgets, that size difference might become an issue worth considering;
• not as mainstream as using manage() in gtkmm (which has quite a few consequences, including clarity and maintainability).

As of idea of favoring std::shared_ptr over Gtk::manage() because shared_ptr is part of C++ Standard, while 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 shared_ptr.

I would rather leverage native gtkmm API, for sake of clarity and efficiency.

P.S.: There is actually a smart pointer Glib::RefPtr, which handles lifetime management for certain gtkmm objects. Again, as it is a feature native to Glib, it leverages built-in facilities of Glib::ObjectBase, and is therefore more efficient then std::shared_ptr for certain applications, for the reasons explained in the 2nd point above.

Grk::manage() solves 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 shared_ptr over 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 shared_ptr.

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 then shared_ptr, which will make a significant difference if you have many pointers to a few objects).

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 shared_ptr over 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 shared_ptr.

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).

Grk::manage() solves 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 the same 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);
• 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 and references, such as, say Gtk::Object.referenced_, that are in your Widget already, no matter you use manage() on it or not); so if you have lots of Widgets - it might become an issue worth considering;
• not as mainstream as using manage() in Gtk.

As of your concern of using shared_ptr because it is part of C++ Standard, while Gtk::manage is not - I'm not sure it is going to be a game changer, as by not using manage() you don't cut your dependency from Gtk anyways.

I would rather leverage native Gtk API, for sake of clarity and efficiency.

p.s. there is actually GLib::RefPtr, which can allow you to manage lifetime of 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.

Grk::manage() solves 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 shared_ptr over 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 shared_ptr.

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 then shared_ptr, which will make a significant difference if you have many pointers to a few objects).