Subject: Re: [boost] [system] Add noexcept to conform with C++11
From: Marshall Clow (mclow.lists_at_[hidden])
Date: 2012-12-09 13:28:46
On Dec 9, 2012, at 10:21 AM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:
> Le 09/12/12 15:03, Beman Dawes a écrit :
>> On Sun, Dec 9, 2012 at 5:00 AM, Vicente J. Botet Escriba
>> <vicente.botet_at_[hidden]> wrote:
>>> Le 08/12/12 21:19, Beman Dawes a écrit :
>>>> On Sat, Dec 8, 2012 at 8:42 AM, Vicente J. Botet Escriba
>>>> <vicente.botet_at_[hidden]> wrote:
>>>>> any news on https://svn.boost.org/trac/boost/ticket/7278.
>>>>> I could add them if you don't have the time now.
>>>> Go ahead!
>>> As the change is a breaking change I would like to update all the libraries
>>> at once. I have identified the following dependent libraries: asio,
>>> filesystem, thread. Are there other libraries?
>> 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.
>>> Should I introduce the change conditionally so that the users could comeback
>>> to the preceding semantics?
>>> I was thinking on defining a new BOOST_SYSTEM_NOEXCEPT that the users will
>>> use instead of BOOST_NOEXCEPT. The user could define BOOST_SYSTEM_NOEXCEPT
>>> as nothing to get the old semantic.
>>> Of course as the needed change in the user code is minor, we could also
>>> choose the drastic way and add a breaking change respect to the preceding
>> What happens if a user has built boost libraries without defining
>> BOOST_SYSTEM_NOEXCEPT but then compiles his or her own code with
>> BOOST_SYSTEM_NOEXCEPT defined, or visa versa? Isn't that an ODR
>> violation? Could this result in the generated code for a call to a
>> boost.system function being incompatible with the code that was
>> generated when the library was built? And wouldn't such a bug be
>> particularly insidious because it might not cause a problem until
>> some future date when an error occurred?
>> 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
> Macros to configure the system should be limited to the Boost administrator. This could be added in the documentation.
> Whether we provide them or not is a question of whether we want to take in account the regression or not. If I was a user that had a lot of classes inheriting from system classes I would appreciate this macro as it give me some time to make the move.
>>> Beman up to you to decide.
>> I want to hear from others, particularly Chris, before making a decision.
> Sorry, I have committed the BOOST_SYSTEM_NOEXCEPT version https://svn.boost.org/trac/boost/changeset/81808.
I am opposed to having this macro appear in a release.
I understand the unwillingness to break existing code, but if the existing implementation does not match the C++ standard, then we should fix our implementation, and document why it changed.
Marshall Clow Idio Software <mailto:mclow.lists_at_[hidden]>
A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
-- Yu Suzuki