Am 08.02.2016 um 20:42 schrieb Murray Cumming: > Thanks. But that wouldn't involve a std::unique_ptr<> at all. It > doesn't feel much different than what we have with Gtk::manage().
Well, you could still deprecate Gtk::manage and use std::make_unique in the implementation and reduce the implementation complexity for later releases this way. > It also forces the add() to to the beginning. I tend to prefer doing > that at the end, after setting up the child widget. I generally assume > that changing the state of the child after it is in a container might > trigger useless processing which I could avoid by doing it before > adding it to the container. Okay, I didn't know about this. In that case I think there will probably be no really satisfying solution with std::unique_ptr. Have you considered std::shared_ptr as well? I'd assume wouldn't have a noticable performance overhead over Gtk::manage, and again, this could mean a reduced implementation complexity in a future release where Gtk::manage would be removed. Otherwise it is pretty much the same though, with the small advantage that you don't have to use new anymore, although you could create a std::make_shared like version of Gtk::manage as well (and std::make_shared is only available in C++14, not C++11). > Allowing use of unique_ptr<> seems more flexible. I think flexibility wouldn't really be an advantage here, unless you plan to remove the ability to remove the ability to add Widgets to containers without the container owning the widget. You're even more flexible with manual memory management ;) _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list