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