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? 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. Beman up to you to decide. Best, Vicente

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

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 break?

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: - 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 #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. 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. Cheers, Chris

Beman Dawes wrote

On Mon, Dec 10, 2012 at 2:44 AM, Christopher Kohlhoff <

chris@

> wrote:

...

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 break?

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.

I don't know what the C++ standard says, but at least MSVC 10.0, gcc-4.7.2 and gcc-4.8.0 complain when I define a virtual function as noexept when the original declaration was not noexcept. class future_error_category : public boost::system::error_category { public: virtual const char* name() const BOOST_NOEXCEPT; virtual std::string message(int ev) const; }; Note that this behavior was the reason I created the ticket for Boost.SysteM. ================== d:\boost\trunk\boost/thread/future.hpp(383) : warning C4913: user defined binary operator ',' exists but no overload could convert all operands, default built-in binary operator ',' used ..\..\..\libs\thread\src\future.cpp(27) : error C2761: 'const char *boost::thread_detail::future_error_category::name(void) const' : member function redeclaration not allowed ..\..\..\libs\thread\src\future.cpp(28) : error C2447: '{' : missing function header (old-style formal list?) ================== gcc.compile.c++ ..\..\..\bin.v2\libs\thread\build\gcc-mingw-4.7.2x\debug\threading-multi\future.o ..\..\..\libs\thread\src\future.cpp:27:41: error: declaration of 'virtual const char* boost::thread_detail::future_error_category::name() const' outside of class is not definition [-fpermissive] =========== gcc.compile.c++ ..\..\..\bin.v2\libs\thread\build\gcc-mingw-4.8.0x\debug\threading-multi\future.o ..\..\..\libs\thread\src\future.cpp:27:41: error: declaration of 'virtual const char* boost::thread_detail::future_error_category::name() const' outside of class is not definition [-fpermissive] =========== So the Chris proposal doesn't works.

...

- 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 #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:?

#ifndef BOOST_SYSTEM_NOEXCEPT # define BOOST_SYSTEM_NOEXCEPT BOOST_NOEXCEPT #endif

I would say that after the deprecation period the definition should be # define BOOST_SYSTEM_NOEXCEPT BOOST_NOEXCEPT as the user should not be able to comeback.

...

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:

If we prefer to avoid the break with BOOST_SYSTEM_NO_DEPRECATED, the boost libraries should use BOOST_SYSTEM_NOEXCEPT or check BOOST_SYSTEM_NO_DEPRECATED.

* 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.

I would not make modification on your docs as they are written using html directly. I will post here the text.

* We need to test the changes both with and without BOOST_SYSTEM_NO_DEPRECATED to make sure they work as expected.

I don't know how to add regression tests with and without the definition of BOOST_SYSTEM_NO_DEPRECATED. This would imply the construction of two different boost_system library. I can of course make some local test changing defining BOOST_SYSTEM_NO_DEPRECATED explicitly.

* We need to mark our personal calendars for, say, six months out to be sure to make the BOOST_SYSTEM_NO_DEPRECATED change.

Yes I think that 2 releases should be enough for the deprecation period.

Marshall, once the end of the transition period reached, this approach should address your concern about standards conformance if I understand it correctly.

So resuming we can - define BOOST_SYSTEM_NOEXCEPT as follows # ifdef BOOST_SYSTEM_USES_NOEXCEPT # define BOOST_SYSTEM_NOEXCEPT BOOST_NOEXCEPT # else # define BOOST_SYSTEM_NOEXCEPT # endif An Boost installer administrator could force the use of noexcept by defining BOOST_SYSTEM_USES_NOEXCEPT on his build. - Use the conditional BOOST_SYSTEM_NOEXCEPT on error_category-derived classes elsewhere in boost. - After a couple of releases remove the test for BOOST_SYSTEM_NO_DEPRECATED in defining BOOST_SYSTEM_NOEXCEPT. # define BOOST_SYSTEM_NOEXCEPT BOOST_NOEXCEPT - Users inheriting from error_category-derived could move to use directly BOOST_NOEXCEPT without breaking. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/system-Add-noexcept-to-conform-with-C-11-... Sent from the Boost - Dev mailing list archive at Nabble.com.

On Dec 10, 2012, at 1:33 PM, Christopher Kohlhoff <chris@kohlhoff.com> wrote:

This snippet illustrates what I mean:

class base { public: virtual const char* name() const = 0; };

class derived : public base { public: virtual const char* name() const noexcept; };

// ...

const char* derived::name() const noexcept { return ""; }

This compiles without error on gcc 4.7.2 (debian). Can you please confirm whether your experimental changes follow this form?

This compiles w/o error using clang as well. (even with -Wall -Wpedantic) -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

Vicente Botet wrote

Le 10/12/12 22:33, Christopher Kohlhoff a écrit :

...

Hi Vicente,

On Tue, Dec 11, 2012, at 01:27 AM, Vicente Botet wrote:

...

I don't know what the C++ standard says, but at least MSVC 10.0, gcc-4.7.2 and gcc-4.8.0 complain when I define a virtual function as noexept when the original declaration was not noexcept. This snippet illustrates what I mean:

class base { public: virtual const char* name() const = 0; };

class derived : public base { public: virtual const char* name() const noexcept; };

// ...

const char* derived::name() const noexcept { return ""; }

This compiles without error on gcc 4.7.2 (debian). Can you please confirm whether your experimental changes follow this form? This as well as the modification I checked on Windows-MinGW compiles well in MacOs for darwin-4.7.0x,darwin-4.6.2x,darwin-4.7.1x,clang-3.1xl,clang-3.2xl,darwin-latest_11,darwin-4.7.2x. on C++11 mode.

I will check your example tomorrow on MinGW. Could someone else check this simple example on MinGW with compiler supporting noexcept in C++11 mode?

My bad. I had a syntax error :( Ok. Lets go for the Chris proposal. Beman, I will post a patch. Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/system-Add-noexcept-to-conform-with-C-11-... Sent from the Boost - Dev mailing list archive at Nabble.com.

...

On Tue, Dec 11, 2012, at 01:27 AM, Vicente Botet wrote:

...

I don't know what the C++ standard says, but at least MSVC 10.0, gcc-4.7.2 and gcc-4.8.0 complain when I define a virtual function as noexept when the original declaration was not noexcept. This snippet illustrates what I mean:

class base { public: virtual const char* name() const = 0; };

class derived : public base { public: virtual const char* name() const noexcept; };

// ...

const char* derived::name() const noexcept { return ""; }

This compiles without error on gcc 4.7.2 (debian). Can you please confirm whether your experimental changes follow this form? This as well as the modification I checked on Windows-MinGW compiles well in MacOs for darwin-4.7.0x,darwin-4.6.2x,darwin-4.7.1x,clang-3.1xl,clang-3.2xl,darwin-latest_11,darwin-4.7.2x. on C++11 mode.

I will check your example tomorrow on MinGW. Could someone else check this simple example on MinGW with compiler supporting noexcept in C++11 mode?

It compiles with MinGW GCC 4.7.2. Regards, Nate

Le 10/12/12 23:44, Beman Dawes a écrit :

On Mon, Dec 10, 2012 at 9:27 AM, Vicente Botet <vicente.botet@wanadoo.fr> wrote:

...

I don't know what the C++ standard says, but at least MSVC 10.0, gcc-4.7.2 and gcc-4.8.0 complain when I define a virtual function as noexept when the original declaration was not noexcept.

class future_error_category : public boost::system::error_category { public: virtual const char* name() const BOOST_NOEXCEPT; virtual std::string message(int ev) const; }; MSVC hasn't shipped any versions that support noexcept. So something must be whacky. If you send me a .patch file with your changes, I'll take a look. I've also got MinGW installed.

This is quite confusing. I suspect that I have introduced a syntax error then. I will check tomorrow when I will have access to a PC Windows. Best, Vicente

Le 11/12/12 00:11, Vicente J. Botet Escriba a écrit :

Le 10/12/12 08:44, Christopher Kohlhoff a écrit :

...

Hi Beman, Vicente,

...

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

On Mon, Dec 10, 2012, at 01:03 AM, Beman Dawes wrote: that I can coordinate the changes to asio properly.

I will do it once we have find the correct way. Sorry for making these changes in your library without requesting before. Hi

here it is https://svn.boost.org/trac/boost/ticket/7797 Best, Vicente