Boost logo

Boost :

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.

>* noexcep:
>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).

>* 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
>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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at