On Tue, 4 Apr 2017 23:09:33 +0100 Jonathan Wakely <gt...@kayari.org> wrote: > On 4 April 2017 at 22:56, Chris Vine wrote: > > 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. > > In C++17 the exception spec is part of the type, so noexcept(true) > functions are mangled differently from functions that are > noexcept(false).
As I said in my follow-up email, on reflection I agree with you about noexcept(false). But if this is correct about noexcept(true), and I am now beginning to doubt myself on this, then it seems a recipe for broken libraries. It makes any code with a noexcept(true) function specification which has been compiled with the -std=c++14 option ABI incompatible with the same code compiled with the -std=c++17 option. What benefit accrues from making the noexcept specification part of the type which is worth all that ABI breakage? _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
