Am 08.02.2016 um 21:50 schrieb Murray Cumming: > On Mon, 2016-02-08 at 21:13 +0100, Jonas Platte wrote: >> 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 > > The more I see how awkward my suggestion can be, the more I hesitate to > deprecate Gtk::manage() even if we have support unique_ptr<>. > >> and use std::make_unique in >> the implementation and reduce the implementation complexity for later >> releases this way. > [snip] > > The implementation is in GObject and GtkObject. My hope is to use > std::unique_ptr<> to express ownership, and avoid leaks, until we add > the child to a container.
The logic for the ownership management is in the C libraries? There is no equivalent to Gtk::manage in gtk+ though, right? > [snip] >> Have you considered std::shared_ptr as well? > [snip] > > I think we'd eventually like to replace Glib::RefPtr<> with > std::shared_ptr<>, keeping a single GObject ref shared between all > std::shared_ptr<>. And hopefully we could make that work with widgets > too. But that's a far bigger, and incompatible, change. Maybe for gtkmm > 4 one day. > > To use std::shared_ptr<> now, for this simpler use, would cause > confusion with Glib::Reftr<> and be almost as hard to make work. Well, if the implementation uses Glib::RefPtr<>, why not just create overloads of all the functions that take references, so they also allow Glib::RefPtr<>? Then you could create a replacement for Gtk::manage that is the equivalent of std::make_shared() for Glib::RefPtr<>. And if you were to move to std::shared_ptr<> in a later version, the transition would be a simple 's/make_ref_ptr/make_shared/'. _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
