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 Is there anything else simple that we could do there? -- Murray Cumming [email protected] www.murrayc.com www.openismus.com _______________________________________________ gtkmm-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtkmm-list
