Re: Supporting C++17

[Jonathan Wakely <gtkmm kayari org>]

On 4 April 2017 at 15:09, Jonathan Wakely wrote:
> On 4 April 2017 at 14:52, Murray Cumming wrote:
> > Noticed here:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1438766

> From that bug report:

(In reply to Murray Cumming from comment #6)
> This makes sense: C++17 will remove support for old-style exception
> specifications, so we'd need some cleverness to support both the old and new
> ways in glibmm. I guess this will break lots of C++ code.

Why try to support the old way?

Dynamic exception specifications are not very useful, and have been
recommended against for many many years. Simply removing them (so the
functions are implicitly noexcept(false)) shouldn't break any code.

Even if you have virtual functions using throw(X), user code that
overrides them would still compile if you removed them:

struct X {
  virtual void f() noexcept(false) { }
};

struct Y : X {
  void f() throw(int) { }
};

This is still OK, because the Y::f override has a stricter exception
specification.


The other way around doesn't work. If you have throw(std::bad_cast) on
a virtual function then users who override it are forced to also use a
deprecated dynamic exception specification, they can't use
noexcept(false):

struct X {
  virtual void f() throw(int) { }
};

struct Y : X {
  void f()  noexcept(false) { }
};

v.cc:6:8: error: looser throw specifier for ‘virtual void Y::f()
noexcept (false)’
  void f()  noexcept(false){ }
       ^
v.cc:2:16: error:   overriding ‘virtual void X::f() throw (int)’
  virtual void f() throw(int) { }
               ^

(I don't see any uses on virtual functions in glibmm or gtkmm so this
might not be a problem anyway).

Simply removing them from your headers seems the best solution.