Re: C++11 move constructors

[Reece Dunn <msclrhd googlemail com>]

On 26 June 2013 10:14, Murray Cumming <murrayc murrayc com> wrote:

On Mon, 2012-11-26 at 09:32 +0100, Kjell Ahlstedt wrote:
> 2012-11-24 12:13, Chow Loong Jin skrev:
> > On 24/11/2012 04:13, Murray Cumming wrote:
> >> On Fri, 2012-11-23 at 14:50 -0500, Tristan Matthews wrote:
> >>> 2012/11/23 Murray Cumming <murrayc murrayc com>:
> >>>> Maybe we could add C++11 move constructors to the gtkmm classes, where appropriate, inside ifdefs to prevent them from breaking the build when C++11 is not enabled/supported by the compiler.
> >>> How would you test for C++11? An AC_COMPILE_IFELSE test that builds a
> >>> class with a move constructor?
> >> Yes, I think that would be best.
> > I think we should still have it disabled by default in the public headers, and
> > opt-in using a macro that users can define manually.
> >
> > The reason for this is that move constructors will end up in public headers, and
> > will break compilations in applications that are not compiled with -std=c++(0x|11).
> >
> >
> Move constructors will probably end up both in public headers and in
> gtkmm's .cc files. If not all move constructors are inline or template,
> i.e. only in header files, a configure-time check is necessary. If gtkmm
> is configured and built without C++11 functionality (e.g. with gcc
> without -std=c++11), move constructors can't safely be enabled when an
> application program is compiled. The libgtkmm-3.0 library file will lack
> some necessary code. And you can't guarantee that a function is inlined.
> The 'inline' keyword is only a hint for the compiler, which it's not
> force to obey.
>
> It would probably be possible to build gtkmm with C++11 functionality
> and then build an application without, if the move constructors in the
> header files are preceded by something like
>
> #if GTKMM_CAN_USE_MOVE_CONSTRUCTORS && (__cplusplus >= 201103L ||
> defined(__GXX_EXPERIMENTAL_CXX0X__))
>
> where GTKMM_CAN_USE_MOVE_CONSTRUCTORS is defined in gtkmmconfig.h.
>
> In the libsigc++ bug https://bugzilla.gnome.org/show_bug.cgi?id=672555 I
> have argued against using a configure-time check for checking if the
> compiler accepts the 'decltype' C++11 keyword, but that's another case.
> 'decltype' is not needed when libsigc++ is built. It's only needed in
> some application programs.

It feels like time to explore C++11 properly and support it where we
can. Maybe we could even decide to support C++11 only if we are forced
to do a glibmm 3 anyway due to the expected glib GInterface change.

I started a glibmm branch with a couple of commits to use auto and
range-based for loops in examples:
https://git.gnome.org/browse/glibmm/log/?h=c%2b%2b11

In the server_without_bus example, the type is changed from `Glib::ustring` to `char *` in:

-static Glib::ustring introspection_xml =

+static auto introspection_xml =

     "<node>"

auto should only be used:

  1/  if it is shorter (e.g. std::unordered_map<Glib::ustring, Glib::ustring>::const_iterator)

  2/  if the deduced type matches the variable type

 

e.g. declaring the `GPid` type `auto` does not buy you anything in terms of improved readability.

Is there anything else simple that we could do there?

1.  right-angle brackets (`>>` instead of `> >`)

2.  static_assert

3.  nullptr

4.  defaulted/deleted functions (e.g. for nocopy objects)

--

Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com

_______________________________________________
gtkmm-list mailing list
gtkmm-list gnome org
https://mail.gnome.org/mailman/listinfo/gtkmm-list