Subject: Re: [boost] [review] Multiprecision review (June 8th - 17th, 2012)
From: John Maddock (boost.regex_at_[hidden])
Date: 2012-06-17 04:36:43
Many thanks for the review, some specific comment follow...
>I would expect the result of unary operator-() always signed. This
>operation is not defined in the front end as it isn't unary operator+().
The operators are defined as non-members.
>I would expect the result of binary operator-() always signed.
That's probably possible, although it makes the behaviour noticably
different from builtin integers.
>Adding mp_uint128_t and mp_int128_t and assign it to a mp_int256_t needs
>two explicit conversions. This interface limits some possible
I'll do what I can do in this area, but the code is already pretty complex
and I worry about it becoming untestable, as well as the issues in deciding
what the "right thing to do" is for mixed arithmetic.
>* I would expect the library provide a back-end for representing N-bits
>integers with exactly (N/8)+1 bytes or something like that.
>* And also an overflow aware back-end for fixed precision integers.
OK, I'll see what I can do.
>* shift operations
>An overload of the shift operations with a unsigned should be provided (in
>addition of the signed one) in order to avoid the sign check.
It's there already - the backend is always fed an unsigned value, and
mp_number only range checks the value provided if it's signed.
>The library interface should use the noexcept (BOOST_NOEXCEPT, ...)
There are some interfaces where that's trivial (for example the operator
overloads returning an expression template). For mp_number's member
functions, I don't know enough about noexcept in non trivial situations to
know if it's possible (can a template member function be noexcept when
whether it throws or not, depends on a dependant type?) There are also
plenty of functions which should be noexcept as they only call external C
library functions, but probably can't be marked as such without modifying
third party headers (gmp.h for example).
>It is unfortunate that the generic mp_number front end can not make use
contexpr as not all the backends can ensure this.
>It will be worth however seen how far we can go.
I think the functions that return an expression template can be constexp.
Will investigate other uses.
>The library doesn't provide some kind of literals. I think that the
>mp_number class should provide a way to create literals if the backend is
>able to. For example
>will produce a nonnegativefixed point constant with a range and resolution
>just sufficient to hold the value 2884*2^-4.
Again I don't yet know enough about constexp in non-trivial use cases to
know if we can do this. Will investigate.
>Adding a move constructor from the backend maybe could help.
>constexpr mp_number<BE>::mp_number(const BE&&);
>Boost.Move should be used to emulate move semantics in compilers don't
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk