On Sun, 14 Dec 2008 14:26:14 +0100 "Germán Diago" <[email protected]> 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 _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
