GNOME Bugzilla – Bug 756593
gmmproc: Writing custom move constructor is not possible
Last modified: 2016-05-25 11:31:14 UTC
Sometimes we might need use custom fields in Glib::Object-based classes, e.g. of type std::unique_ptr. Then we need explicit move this field to another object. For now it's impossible, because we're not able to provide custom implementation of move constructor and move assignment operator. My patch solves this problem, by adding one more macro _CUSTOM_MOVE_OPERATIONS.
Created attachment 313338 [details] [review] proposed solution
Sure. This seems analogous to the existing need for custom constuctors. Please go ahead. But please also try to document this in gtkmm-documentation's gmmproc chapter.
Created attachment 313371 [details] [review] documentation OK, I also documented my change in gtkmm-documentation. Please review, and if everything is ok, I'll push both patches to upstream repository.
Created attachment 313373 [details] [review] documentation v2 (minor fix)
When I studied your documentation patch, I noticed that no _CUSTOM_* macros were mentioned in the gtkmm tutorial. Now I've added very short descriptions of them. https://git.gnome.org/browse/gtkmm-documentation/commit/?id=9fe25ec87058685dffcc0ff7d7dbb54c30466276 My descriptions don't contain code snippets. If you want a code snippet in the description of _CUSTOM_MOVE_OPERATIONS that's ok, but it should contain a call to _CLASS_GOBJECT. _CUSTOM_MOVE_OPERATIONS doesn't do anything wihout a _CLASS_GOBJECT, does it? The gmmproc patch looks ok. But wouldn't _CUSTOM_MOVE_OPERATIONS be more useful in _CLASS_GTKOBJECT in gtkmm? If I haven't misunderstood something, move operations are not useful for objects which are accessed via Glib::RefPtr (see bug 756962, part of comment 0). And most or all _CLASS_GOBJECT classes are accessed via RefPtr.
(In reply to Kjell Ahlstedt from comment #5) > My descriptions don't contain code snippets. If you want a code snippet in > the > description of _CUSTOM_MOVE_OPERATIONS that's ok, but it should contain a > call to _CLASS_GOBJECT. _CUSTOM_MOVE_OPERATIONS doesn't do anything wihout > a _CLASS_GOBJECT, does it? Correct. My mistake. > The gmmproc patch looks ok. But wouldn't _CUSTOM_MOVE_OPERATIONS be more > useful in _CLASS_GTKOBJECT in gtkmm? If I haven't misunderstood something, > move operations are not useful for objects which are accessed via > Glib::RefPtr > (see bug 756962, part of comment 0). And most or all _CLASS_GOBJECT classes > are accessed via RefPtr. I do agree; most _CLASS_GOBJECT classes are accessed via RefPtr. But as you pointed in your comment (bug 756962), we might have a situation: some_object11->operator=(std::move(*some_object22.operator->())); We might also consider add _CUSTOM_MOVE_OPERATIONS to boxed types, and as you already mentioned, to GTKOBJECT.
If you see a need for _CUSTOM_MOVE_OPERATIONS in _CLASS_GOBJECT or in other types of classes, feel free to add it.
For now I've added it only to _CLASS_GOBJECT. If someone needs it in other classes, then I'll add the same code to other files as well. https://git.gnome.org/browse/glibmm/commit/?id=fa77097d794e2979f60eadf94c2ed101f6455f79 https://git.gnome.org/browse/gtkmm-documentation/commit/?id=208ba72b7474516e7d8e4e17eeb4d69e2d5e6a84
Thanks. Closing then.
Reopening, because _CUSTOM_MOVE_OPERATIONS does not work if the class implements an interface. I noticed this when I tried to build gtkmm-2 with the latest gmmproc. (I know it's always a challenge to build gtkmm-2 like that.) The bug can show up even without involving gtkmm-2. I tested by adding _CUSTOM_MOVE_OPERATIONS in gio/src/application.hg, which implements ActionGroup and ActionMap. The last few lines in application.cc become } // namespace Gio , ActionGroup(std::move(src)) , ActionMap(std::move(src)) ActionGroup::operator=(std::move(src)); ActionMap::operator=(std::move(src)); Of course it won't compile.
Fixed by this commit: https://git.gnome.org/browse/glibmm/commit/?id=02f7016cc4cc96e2f85654a4fe80bd80c63b275e The bug was in tools/m4/base.m4 and has existed for many years. Perhaps this is the first time it has caused a real problem. The code pushed to SECTION_CC_MOVE_CONSTRUCTOR_INTERFACES and SECTION_CC_MOVE_ASSIGNMENT_OPERATOR_INTERFACES by _IMPLEMENTS_INTERFACE_CC in class_shared.m4 must be discarded, if it's not imported somewhere, e.g. by _END_CLASS_GOBJECT in class_gobject.m4.