Subject: Re: [boost] [system] Add noexcept to conform with C++11
From: Beman Dawes (bdawes_at_[hidden])
Date: 2012-12-10 07:57:22
On Mon, Dec 10, 2012 at 2:44 AM, Christopher Kohlhoff
> Hi Beman, Vicente,
> On Mon, Dec 10, 2012, at 01:03 AM, Beman Dawes wrote:
>> We need to contact Chris Kohlhoff to coordinate any asio changes with
>> him. I have a vague recollection that he maintains the asio codebase
>> elsewhere, so boost trunk is really just a mirror of some other repo.
>> But I could be wrong about that.
> Beman is correct. A change made to the boost tree only is liable to get
> clobbered. Vicente, if you don't mind can you please raise a ticket so
> that I can coordinate the changes to asio properly.
>> That seems a lot worse than the noisy compiler error that will happen
>> if user code just broke. How many folks are using a compiler that
>> supports C++11 noexcept, have C++11 turned on, and are deriving from
>> boost::system_error? Or am I missing other cases where user code would
> The main problem is that this change breaks user-defined error
> categories. These definitely exist in the wild, some in projects that
> use C++11. These uses are currently perfectly valid.
> If I understand correctly, a virtual function on a derived class is
> permitted to have a more restrictive exception specification than that
> on the base class. This should permit the following approach, which may
> be more gentle on users:
That's also my understanding, but I've never actually tried it with a
real C++11 compiler.
> - Document the non-noexcept forms in boost.system as deprecated.
> - Define BOOST_SYSTEM_NOEXCEPT in terms of BOOST_SYSTEM_NO_DEPRECATED:
> #ifndef BOOST_SYSTEM_NOEXCEPT
> # ifdef BOOST_SYSTEM_NO_DEPRECATED
> # define BOOST_SYSTEM_NOEXCEPT BOOST_NOEXCEPT
> # else
> # define BOOST_SYSTEM_NOEXCEPT
> # endif
> - Exclusively use the BOOST_SYSTEM_NOEXCEPT define in boost.system.
> - Use the non-conditional BOOST_NOEXCEPT on error_category-derived
> classes elsewhere in boost. This is ok because BOOST_NOEXCEPT will
> always be the same as or a more restrictive than BOOST_SYSTEM_NOEXCEPT.
> - After a couple of releases remove the test for
> BOOST_SYSTEM_NO_DEPRECATED in defining BOOST_SYSTEM_NOEXCEPT.
So after removal the BOOST_SYSTEM_NOEXCEPT define would look like this:?
# define BOOST_SYSTEM_NOEXCEPT BOOST_NOEXCEPT
> This means that:
> - User code is not immediately broken. The usual process of deprecation
> grants them a transitional period. (If some users choose to ignore the
> deprecation notice then that's their problem.)
> - Users may define BOOST_SYSTEM_NO_DEPRECATED to ensure that their code
> is forwardly compatible.
> I would certainly prefer something like this over immediate breakage.
Vicente, this sound good to me, but:
* The change needs to include doc updates, and is generally complex
enough that I'd like to review a diff of your changes before you
commit them to trunk.
* The release notice needs to have a Boost.System entry notifying
users of the changes.
* We need to test the changes both with and without
BOOST_SYSTEM_NO_DEPRECATED to make sure they work as expected.
* We need to mark our personal calendars for, say, six months out to
be sure to make the BOOST_SYSTEM_NO_DEPRECATED change.
Marshall, once the end of the transition period reached, this approach
should address your concern about standards conformance if I
understand it correctly.
Thanks for your help on this!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk