Re: [boost] [review] Multiprecision review (June 8th - 17th, 2012)

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

Hello,

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

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

Good luck with the reviews,

-- 
Marc Glisse