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@wanadoo.fr> 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@wanadoo.fr> 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. Of course I can changes any BOOST_SYSTEM_NOEXCEPT by BOOST_NOEXCEPT or just change #ifndef BOOST_SYSTEM_NOEXCEPT #define BOOST_SYSTEM_NOEXCEPT BOOST_NOEXCEPT #endif by #define BOOST_SYSTEM_NOEXCEPT BOOST_NOEXCEPT Please let me know if I need to do something. Vicente