Re: Gtkmm widgets move semantics.

[Chris Vine <chris cvine freeserve co uk>]

On Sun, 14 Dec 2008 14:26:14 +0100
"Germán Diago" <germandiago gmail com> wrote:
> Move semantics is a feature of c++0x that would allow to use widgets
> by value. It's very easy to add this to
> widgets (it's just one function which is very trivial for every
> movable widget). It makes sense to have move semantics for
> widgets (but no copy semantics).
> It would enable return by value of widgets and containers could store
> widgets by value without the use
> of shared pointers, which can cause problems with cycles.
> 
> class Button
> {
>     Button(Button && other);
> };
> 
> Gtk::Button create_custom_button(...)
> {
>   Gtk::Button button;
>   ...
>   return button;
> }
> 
> //Gtk::Button is movable, so it can be used in c++0x containers.
> std::vector<Gtk::Button> contbuttons;
> 
> //This doesn't trigger any copy in c++0x, it just uses move
> constructor contbuttons.push_back(create_custom_button(...));
> 
> This also enables the poly object idiom, (which I want to use in my
> programs), which allows
> value semantics and polymorphism without inheritance. For example, you
> can do things like this:
> 
> class poly_button {
>   ...
> };
> 
> std::vector<poly_button> contbuttons;
> contbuttons.push_back(poly_button(Gtk::Button("hello")));
> contbuttons.push_back(poly_button(Gtk::ToggleButton("another
> button"));
> 
> And you could extend it even for non-gtk buttons easily, if it is
> needed.
> 
> Take a look if you want at this paper, it explains how this is
> accomplished:
> 
> http://www.speakeasy.org/~mmarcus/papers/MPOOL2007-marcus.pdf
> 
> > What do you mean by a move constructor for a widget?  It doesn't
> > seem to make any sense.  An example of what you mean might be
> > helpful.
> >
> > Are you perhaps looking for Gtk::Widget::reparent()?

OK, well it would be relatively trivial to write a constructor taking a
r-value reference to its own type for a gtkmm widget because it would
only be a matter of passing the pointer to the underlying GTK+ object.
However, isn't this addition to the C++ standard mainly intended for
efficiency purposes, by saving unnecessary copying where it is not
necessary?  On this point:

(i) gtkmm and GTK+ widgets only exist for the purpose of putting them in
a GTK+ container.  Leaving aside C++ containers and initialising them
with a temporary (which is what your proposal would permit), gtkmm
widgets do not have, and will not have, a normal copy constructor or
assignment operator allowing pass by value, so having a move constructor
to pass temporaries by value does not seem to have any particular
purpose (but I may have misunderstood your proposal - see below).

(ii) having move constructors won't avoid reference cycles in other
parts of the code because GObjects/GtkObjects are reference counted and
as I have said GTK+ widgets only have meaning when they are in a GTK+
container, which will own a reference to them.

However, I am only a user of gtkmm/glibmm and I don't contribute (except
very rarely) so you will need to persuade the library maintainers.  I
may have misunderstood the purpose of your proposal (I have not
particularly been following the evolution of C++0x) so for their
benefit by all means expand on it.

Chris