On 4 April 2017 at 23:08, Chris Vine wrote: > On second thoughts, noexcept(true) might possibly change ABI in C++17, > but it seems inconceivable that noexcept(false) would.
Right. You can verify this fairly easily: https://godbolt.org/g/akduU4 Notice that the type of foo (as used in the type of f1) is the same for c++98, c++14 and c++17. The type of bar (as it shown in the type of f2, which godbolt's demangler doesn't even support!) changes for c++17. foo is a noexcept(false) function, and is the same whether it uses throw(bad_cast) or noexcept(false). bar is a noexcept(true) function, and is the same whether it uses throw() or noexcept(true), but is not the same for c++17 comapred with earlier versions. But what makes a difference is -std=c++17, not whether you use throw(...) or noexcept(...). > 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. It allows overloading on whether a function can throw, and specializing templates on it, and deducing it from template arguments. So if you take the address of a function you don't lose it's "noexceptiness". Previously this static assertion could never pass: void f() noexcept; template<typename F> void g(F f) { static_assert( noexcept( f() ), "callback won't throw" ); } int main() { g( &f ); } In C++17 it compiles. _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
