On Mon, 2016-02-08 at 12:40 +0000, 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
the confusion caused by my choice of words.
> But it's not ideal because it doesn't allow rvalues
> to be passed straight from factory functions to sinks. You must
> create
> an intermediate local variable, extract a raw pointer, then use
> std::move to cast back to an rvalue.
>
> Options (2) and (3) both allow rvalues to be passed straight from
> factories to sinks, but allow a non-owning pointer to be obtained at
> the same time.
[snip]
Ah, now I see your point. Thanks.
I do find your suggested API awkward (I've renamed add_unique() to add()):
Button* b = nullptr; //I don't like this being even momentarily
uninitialized. murrayc.
c.add(pass_and_observe(button_factory("some button"), b));
b->blahblah();
However, it's just one pass_and_observe() template that works on top of the
simple
add(unique_ptr<>) overloads. People could use it they wanted to, or use a
get_child()
method if they preferred, trying to leave an explicit std::move() as late as
possible
so they didn't need to. I hope we can improve the occasional API that makes this
difficult currently.
By the way, would you want people to use this even without a factory method?
For instance:
Button* b = nullptr; //I don't like this being even momentarily
uninitialized. murrayc.
c.add(pass_and_observe(std::make_unique<Gtk::Button>("some button"), b));
b->blahblah();
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
