The compiler supports std::exception_ptr but does not support uniform
initialization syntax.
Co-authored-by: Emil Dotchevski <emildotchevski@gmail.com>
* Attempt to solve issue #10
In boost::current_exception(), after all supported types of exception have
been checked for, a boost::unknown_exception is stored in the
boost::exception_ptr as a last resort to signal that an exception was indeed
stored, but that the actual type and value of the exception was lost.
Now, in case C++11 std::current_exception() is supported, the
std::exception_ptr result of calling std::current_exception() is what
gets stored inside the boost::exception_ptr. Later, inside
boost::rethrow_exception, the std::exception_ptr is retrieved from
the boost::exception_ptr and whatever exception it stores is thrown via
std::rethrow_exception().
The main benefit is than now any exception thrown via plain 'throw'
can be trasnported via boost::exception_ptr. Before this change it was
required that the throw site either used boost::enable_current_exception()
or boost::throw_exception() or threw an exception type inheriting from
boost::exception, which was impossible for third party software
that does not use Boost.Exception.
The detection of std::current_exception() is currently done via config macro
BOOST_NO_CXX11_NOEXCEPT, assuming that if 'noexcept' is supported then
std::exception_ptr is also supported. A better solution would require a new
dedicated macro in Boost.Config.
* Detect support for std::current_exception() via config macro BOOST_NO_CXX11_HDR_EXCEPTION
The temporary solution via BOOST_NO_CXX11_NOEXCEPT was an ugly hack
that is no longer necessary now that Boost.Config has
BOOST_NO_CXX11_HDR_EXCEPTION (pending merge to develop).
* Attempt to solve issue #10
In boost::current_exception(), after all supported types of exception have
been checked for, a boost::unknown_exception is stored in the
boost::exception_ptr as a last resort to signal that an exception was indeed
stored, but that the actual type and value of the exception was lost.
Now, in case C++11 std::current_exception() is supported, the
std::exception_ptr result of calling std::current_exception() is what
gets stored inside the boost::exception_ptr. Later, inside
boost::rethrow_exception, the std::exception_ptr is retrieved from
the boost::exception_ptr and whatever exception it stores is thrown via
std::rethrow_exception().
The main benefit is than now any exception thrown via plain 'throw'
can be trasnported via boost::exception_ptr. Before this change it was
required that the throw site either used boost::enable_current_exception()
or boost::throw_exception() or threw an exception type inheriting from
boost::exception, which was impossible for third party software
that does not use Boost.Exception.
The detection of std::current_exception() is currently done via config macro
BOOST_NO_CXX11_NOEXCEPT, assuming that if 'noexcept' is supported then
std::exception_ptr is also supported. A better solution would require a new
dedicated macro in Boost.Config.
* Detect support for std::current_exception() via config macro BOOST_NO_CXX11_HDR_EXCEPTION
The temporary solution via BOOST_NO_CXX11_NOEXCEPT was an ugly hack
that is no longer necessary now that Boost.Config has
BOOST_NO_CXX11_HDR_EXCEPTION (pending merge to develop).
* Document detection of C++11 std::current_exception through BOOST_NO_CXX11_HDR_EXCEPTION
* Added dist: trusty for Travis config, as recommended by pdimov in issue #10
* Stupid gcc 4.7 and 4.8 are confused initializing a reference with braces, using equal sign hoping it works (tested similar code on godbolt).
Generate cmake target that builds the library and which can
be used by other libraries to express their dependency on
this library and retrieve any configuration information
such as the include directory, binary to link to,
transitive dependencies, necessary compiler options or the
required c++ standards level.
Test are failing on Visual C++ 7.1, I think because it's not importing
error_info_base into the class' namespace, so hopefully this will fix it. I
don't have access to the compiler, so I'm not sure.
