On Tue, 4 Apr 2017 22:56:22 +0100 Chris Vine <ch...@cvine.freeserve.co.uk> wrote: > On Tue, 04 Apr 2017 18:13:46 +0200 > Murray Cumming <murr...@murrayc.com> wrote: > > On Tue, 2017-04-04 at 15:09 +0100, Jonathan Wakely wrote: > > > On 4 April 2017 at 14:52, Murray Cumming wrote: > > > > Any ideas about how we should support C++17 in gtkmm-3.0 without > > > > losing > > > > C++11/14 compatibility and without breaking ABI? > > > > > > Replace all dynamic exception specifications with noexcept(false) > > > (or just no exception specification). That's not an ABI > > > change. > > > > That's great to know. I'll take care of that then. > > I would check that. It didn't affect ABI in C++11/14, but I am not so > sure about C++17. According to > http://en.cppreference.com/w/cpp/language/noexcept_spec, > in C++17 "The noexcept-specification is a part of the function type > and may appear as part of any function declarator." If it is part of > the type then it might feature in name mangling, so this is worth > checking with the compiler writers.
On second thoughts, noexcept(true) might possibly change ABI in C++17, but it seems inconceivable that noexcept(false) would. It also seems weird that merely applying -std=c++17 to your code should break its ABI. The more I think about it, the less clear I am what making the noexcept specification part of the function type in C++17 actually involves compiler-wise, or what it achieves. _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
