Re: Replace Gtk::manage() with std::unique_ptr<>?

[Jonas Platte <jonasplatte gmail com>]

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/'.