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

On Mon, 2016-02-08 at 21:50 +0100, Murray Cumming wrote: > 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<>. I plan to commit this, without deprecating Gtk::manage(), but probably not for gtkmm 3.20 because

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

On Mon, 2016-02-08 at 00:08 +0100, Murray Cumming wrote: > I think I'd be content with needing a call to a getter method after a > std::move(). I think that would make sense to people. > > But, for simple setup code, to arrange widgets in their initial > working > state, it would be nice if our

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

On 08/02/16 10:18 +1300, Ian Martin wrote: As you've said, using unique_pointer mandates a design with only one access point to the controlled object, That's not true. std::unique_ptr mandates one *owner* of the object, but that doesn't prevent you accessing it through any number of

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

On 08/02/16 13:19 +0100, Murray Cumming wrote: On Mon, 2016-02-08 at 11:56 +, Jonathan Wakely wrote: [snip] A cleaner API would operate in terms of rvalues returned from functions, and passed straight into other functions, avoiding std::move entirely. [snip] Do you mean like this?

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

On Mon, 2016-02-08 at 11:56 +, Jonathan Wakely wrote: [snip] > A cleaner API would operate in terms of rvalues returned from > functions, and passed straight into other functions, avoiding > std::move entirely. [snip] Do you mean like this? window.add(create_button("something")); That's

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

On 08/02/16 00:08 +0100, Murray Cumming wrote: On Sun, 2016-02-07 at 22:51 +0100, Dr. Diether Knof wrote: Hello, I think, to use std::unique_ptr and std::move instead of Gtk::manage is a good idea, but it is more difficult to use: > auto widget = std::make_unique("some button"); OK >

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

2016-02-08 15:40 GMT+01:00 Murray Cumming : > On Mon, 2016-02-08 at 12:40 +, Jonathan Wakely wrote: > [snip] > > You said (1) "doesn't seem much better" than use-after-move, which I > > disagree with. It's infinitely better because it is not undefined and > > doesn't

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

On Mon, 2016-02-08 at 12:40 +, Jonathan Wakely wrote: [snip] > You said (1) "doesn't seem much better" than use-after-move, which I > disagree with. It's infinitely better because it is not undefined and > doesn't crash :-) Of course. I don't want code that looks wrong and crashes. Sorry for

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

On Mon, 2016-02-08 at 15:44 +0100, Krzesimir Nowak wrote: > Just a minor hint here - Button* b {}; should do the trick and it is > not that lot more of typing. Thanks. Whether we should now use curly brackets for "uniform initialization" wherever possible is a whole other question we should

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

Am 08.02.2016 um 21:27 schrieb Jonathan Wakely: > No, std::make_unique is only available since C++14, std::make_shared > was in C++11. Right, thanks for correcting me. Don't know why I thought it was the other way around. ___ gtkmm-list mailing list

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

On 08/02/16 15:40 +0100, Murray Cumming wrote: On Mon, 2016-02-08 at 12:40 +, Jonathan Wakely wrote: [snip] You said (1) "doesn't seem much better" than use-after-move, which I disagree with. It's infinitely better because it is not undefined and doesn't crash :-) Of course. I don't want

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

Some additional thoughts: 1) Using std::shared_ptr encourages me, to use the pointer multible times in the same way. But this is not OK here. auto button = std::make_shared("a button"); { Gtk::Frame frame; frame.add(button); // OK button.set_label("text"); // OK } { Gtk::Frame frame2;

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

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

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

On 08/02/16 15:56 +0100, Murray Cumming wrote: On Mon, 2016-02-08 at 15:44 +0100, Krzesimir Nowak wrote: Just a minor hint here - Button* b {}; should do the trick and it is not that lot more of typing. Thanks. Whether we should now use curly brackets for "uniform initialization" wherever

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

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

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

So, I've read most of this conversation, and it seems this simple alternative hasn't come up yet: // Old code auto button = Gtk::manage(new Gtk::Button("a button"); button->show(); container.add(button); // New code auto button = container.add_managed("a button"); button->show();

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

On Mon, 2016-02-08 at 20:04 +0100, Jonas Platte wrote: > So, I've read most of this conversation, and it seems this simple > alternative hasn't come up yet: > > // Old code > auto button = Gtk::manage(new Gtk::Button("a button"); > button->show(); > container.add(button); > > // New

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

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

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

On Mon, 2016-02-08 at 22:26 +0100, Jonas Platte wrote: > The logic for the ownership management is in the C libraries? There > is > no equivalent to Gtk::manage in gtk+ though, right? It's the default behaviour with the C GTK+ API. We make it optional, so we can use normal C++ object lifetimes,

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

This patch adds the necessary method overloads and adapts the demos and tests to use them: https://bugzilla.gnome.org/show_bug.cgi?id=761665 The patch has //TODO comments where the API currently forces us to use the unique_ptr after we've std::move()ed it. This causes crashes. I'd welcome

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

Correct me if I'm wrong, but doesn't Gtk::manage work more like a shared pointer? i.e. maintain a count of the references to the object, deleting the object pointed to when the ref count goes to zero. As you've said, using unique_pointer mandates a design with only one access point to the

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

Hello, I think, to use std::unique_ptr and std::move instead of Gtk::manage is a good idea, but it is more difficult to use: > auto widget = std::make_unique("some button"); OK > notebook.append_page(std::move(widget), "something"); OK, but widget does no longer point to the botton, compare

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

On Sun, 2016-02-07 at 22:51 +0100, Dr. Diether Knof wrote: > Hello, > > I think, to use std::unique_ptr and std::move instead of Gtk::manage > is a good > idea, but it is more difficult to use: > > > auto widget = std::make_unique("some button"); > OK > >

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

On Mon, 2016-02-08 at 10:18 +1300, Ian Martin wrote: > Correct me if I'm wrong, but doesn't Gtk::manage work more like a > shared > pointer? i.e. maintain a count of the references to the object, > deleting > the object pointed to when the ref count goes to zero. Not quite. GObject has simple

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

One thing about this bothers me: Unlike a call to Gtk::manage(), a call to std::move() suggests that we shouldn't touch the std::unique_ptr again. But we have some API that seems to require that. For instance, we have code in demowindow.cc that would end up a little like this: auto widget =

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

The trend in modern C++ is to use std::unique_ptr<> by default to express ownership, usually via std::make_unique() (in C++14), insead of using a raw pointer via a "naked new". So, unless you know something else is necessary, this would be good: auto thing = std::make_unique(); instead of this:

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

The trend in modern C++ is to use std::unique_ptr<> by default to express ownership, usually via std::make_unique() (in C++14), insead of using a raw pointer via a "naked new". So, unless you know something else is necessary, this would be good: auto thing = std::make_unique(); instead of this: