Boost logo

Boost :

Subject: Re: [boost] [review] Multiprecision review (June 8th - 17th, 2012)
From: Marc Glisse (marc.glisse_at_[hidden])
Date: 2012-06-22 20:11:04


I just found this unsent draft. I don't remember what else I wanted to

On Sun, 17 Jun 2012, John Maddock wrote:

>> * 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?)

noexcept(noexcept(expression)) works great.

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

GMP functions that are noexcept are marked as such. Functions that may
allocate may throw and thus can't be noexcept (although a macro that says:
"assume there is enough memory" might make sense).

>> Adding a move constructor from the backend maybe could help.
>> constexpr mp_number<BE>::mp_number(const BE&&);

I am not sure I understand what that's good for?

Just to mention a few other things. For mixed arithmetic, having
operations like:
number<common_type<A,B>::type> operator+(number<A>,number<B>) that call
eval_add(common_type<A,B>::type&,A,B) seems good. If A==B, it doesn't
change anything. If a backend is implicitly convertible to another,
operations just work. And the backend writer can still overload eval_add
to optimize some operations. You could even consider turning that into a
result_trait<T...,op> that defaults to common_type<T...>::type but can be
specialized by backend writers and determines mp_exp<...>::result_type (I
notice you already have combine_expression that could be extended).

Having the public type (mp_number) and the expression type (mp_exp) be
specializations of the same template could save a few lines of code?

You seem to go further than I did in gmpxx to remove temporaries by
reusing the result: you check for aliasing within any expression, whereas
I stopped at depth one (I had a prototype for arbitrary depth, and it
simplified the code, but I was scared of the potential quadratic cost, I
probably shouldn't be). Although I am surprised that in a=expr1+expr2,
when a appears in expr1 but not expr2, you don't try to take advantage of
it (not that it would help much now, but it might if you eventually add

Good luck with the reviews,

Marc Glisse

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