On Mon, Aug 27, 2012 at 2:43 PM, Olaf van der Spek <ml@vdspek.org> wrote:
On Mon, Aug 27, 2012 at 7:33 PM, Beman Dawes <bdawes@acm.org> wrote:
Ideas?
Can the derived classes be updated before the superclass is updated? If not, a flag day/release seems necessary which might be problematic for user libs & apps.
That worked OK for Boost.Filesystem's filesystem_error and a UDT that's part of the Boost.System test suite. So that will help with Boost's codebase; we can find and fix the affected code before actually changing Boost.System. But there is still a problem for user code. Also, BOOST_NOEXCEPT is null for C++03 libraries and compilers. But in some cases signature that has to be changed currently has a "throw()" throw-specifier. So I guess we need a BOOST_NOEXCEPT_NOTHROW macro defined as "noexcept" for C++11 and "throw()" for C++03. Otherwise we would be changing the semantics for C++03 compilers. That's similar to what libstdc++ does: // Macro for noexcept, to support in mixed 03/0x mode. #ifndef _GLIBCXX_NOEXCEPT # ifdef __GXX_EXPERIMENTAL_CXX0X__ # define _GLIBCXX_NOEXCEPT noexcept # define _GLIBCXX_USE_NOEXCEPT noexcept # define _GLIBCXX_THROW(_EXC) # else # define _GLIBCXX_NOEXCEPT # define _GLIBCXX_USE_NOEXCEPT throw() # define _GLIBCXX_THROW(_EXC) throw(_EXC) # endif #endif I guess that by defining _GLIBCXX_NOEXCEPT, _GLIBCXX_USE_NOEXCEPT, and _GLIBCXX_THROW(_EXC) yourself, it is possible to build the library from source any way you want. But that runs a serious risk of your library build getting out of sync with your program builds. --Beman