On 4 April 2017 at 23:28, Chris Vine <ch...@cvine.freeserve.co.uk> wrote: > 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.
Not any code, only code that depends on the type of function pointers in mangled names. The mangled names of the functions themselves don't change, only names that depend on them. Using https://godbolt.org/g/akduU4 again, foo anr bar do not change their mangled names. But f2, which depends on decltype(&bar), does change. However, it's uncommon to actually use decltype(&bar) like that in a function signature. Far more common would be something like: using func_type = void(*)(); void f2(func_type); And this wouldn't change, because func_type doesn't include the exception specification (because it wasn't allowed to in C++14). There's an implicit conversion from R(*)(Args...) noexcept to R(*)(Args...) so calling f2(&bar) would still work whether it's declared to take void(*)() or void(*)()noexcept. Some code may well be affected, and we don't know exactly how much, but it's not as catastrophic as you suggest. It's a good reason not to require C++17 for glibmm yet though :-) > What benefit accrues from making the noexcept specification part of > the type which is worth all that ABI breakage? See my previous email. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0012r1.html also gives some (terse) rationale. _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
