Re: [boost] [system] Add noexcept to conform with C++11

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:
>>>>> Hi,
>>>>> 
>>>>> 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?
>> chrono?
>> 
>> 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
>>> version.
>> 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
>> break?
> 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

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