[multiprecision] noexcept() usage in gmp int
Hello, I was trying out the new multiprecision library (kudos!), and I ran into a problem. In order to make certain guarantees in my code regarding exception safety, I am mandating that types being used in generic containers are marked noexcept() for certain basic operations (namely, destruction and move operations). It seems like this is generally guaranteed in the multiprecision library (tried with cpp_int and the mpfr adaptor), with the important exception of the gmp integer class. A glance at the headers reveals that (gmp.hpp): // // Within this file, the only functions we mark as noexcept are those that manipulate // (but don't create) an mpf_t. All other types may allocate at pretty much any time // via a user-supplied allocator, and therefore throw. // Additionally, browsing the gmp documentation yields this snippet ( http://gmplib.org/manual/Custom-Allocation.html): """ There's currently no defined way for the allocation functions to recover from an error such as out of memory, they must terminate program execution. A longjmp or throwing a C++ exception will have undefined results. This may change in the future. """ Would it be possible then for the mp library authors to consider adding basic noexcept() guarantees to the gmp adaptor class in future versions? Cheers and thanks for the great library, Francesco.
I was trying out the new multiprecision library (kudos!), and I ran into a problem. In order to make certain guarantees in my code regarding exception safety, I am mandating that types being used in generic containers are marked noexcept() for certain basic operations (namely, destruction and move operations).
It seems like this is generally guaranteed in the multiprecision library (tried with cpp_int and the mpfr adaptor), with the important exception of the gmp integer class. A glance at the headers reveals that (gmp.hpp):
// // Within this file, the only functions we mark as noexcept are those that manipulate // (but don't create) an mpf_t. All other types may allocate at pretty much any time // via a user-supplied allocator, and therefore throw. //
Additionally, browsing the gmp documentation yields this snippet ( http://gmplib.org/manual/Custom-Allocation.html):
""" There's currently no defined way for the allocation functions to recover from an error such as out of memory, they must terminate program execution. A longjmp or throwing a C++ exception will have undefined results. This may change in the future. """
Would it be possible then for the mp library authors to consider adding basic noexcept() guarantees to the gmp adaptor class in future versions?
Looks like an oversight to me, added BOOST_NOEXCEPT to mpz_int destruct/move/swap operations in Trunk. On a related note, these noexcept specifications seem to be untestable to me, am I missing something? John.
Thank you John!
Best regards,
Francesco.
On 14 June 2013 13:41, John Maddock
I was trying out the new multiprecision library (kudos!), and I ran into a
problem. In order to make certain guarantees in my code regarding exception safety, I am mandating that types being used in generic containers are marked noexcept() for certain basic operations (namely, destruction and move operations).
It seems like this is generally guaranteed in the multiprecision library (tried with cpp_int and the mpfr adaptor), with the important exception of the gmp integer class. A glance at the headers reveals that (gmp.hpp):
// // Within this file, the only functions we mark as noexcept are those that manipulate // (but don't create) an mpf_t. All other types may allocate at pretty much any time // via a user-supplied allocator, and therefore throw. //
Additionally, browsing the gmp documentation yields this snippet ( http://gmplib.org/manual/**Custom-Allocation.htmlhttp://gmplib.org/manual/Custom-Allocation.html ):
""" There's currently no defined way for the allocation functions to recover from an error such as out of memory, they must terminate program execution. A longjmp or throwing a C++ exception will have undefined results. This may change in the future. """
Would it be possible then for the mp library authors to consider adding basic noexcept() guarantees to the gmp adaptor class in future versions?
Looks like an oversight to me, added BOOST_NOEXCEPT to mpz_int destruct/move/swap operations in Trunk.
On a related note, these noexcept specifications seem to be untestable to me, am I missing something?
John. ______________________________**_________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/**mailman/listinfo.cgi/boost-**usershttp://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
Francesco Biscani -
John Maddock