Vicente, 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 optimizations.
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.
* noexcep:
The library interface should use the noexcept (BOOST_NOEXCEPT, ...) facilities.
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).
* constexpr:
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.
* literals
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 to_nonnegative<2884,-4>()| 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&&);
Will add.
Boost.Move should be used to emulate move semantics in compilers don't providing it.
Will investigate. Regards, John.