On 26 June 2013 10:14, Murray Cumming <[email protected]> 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 <[email protected]>:
> > >>>> 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
> [email protected]
> www.murrayc.com
> www.openismus.com
>
> _______________________________________________
> gtkmm-list mailing list
> [email protected]
> https://mail.gnome.org/mailman/listinfo/gtkmm-list
>
_______________________________________________
gtkmm-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
