I'm wondering if the following compiles and what is the type of c
mp_uint128_t a; mp_uint256_t b; auto c = a + b;
From the documentation I have the impression that we can not mix back-ends.
Correct, it's a compiler error. Allowing mixed type arithmetic opens up a whole can of worms it seems to me, plus I don't even want to think about how complex the operator overloads would have to be to support that! So for now, if you want to conduct mixed arithmetic, you must explicitly cast one of the types.
It seems to me that fixed precision and allocation are orthogonal features. Why the fixed precision types can not use an allocator?
Good question. It seemed to me that the most common use case for fixed precision types was for types "just a bit wider than long long", where it was important not to be allocating memory. Plus if you're going to allow memory allocation, wouldn't it be safer to use the arbitary precision type and avoid the risk of overflow altergether?
I'm working on a fixed_point library (see the sandbox code, sorry, but there is no doc yet but http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html is quite close ).
That paper is interesting, particularly in it's allowance of mixed-mode arithmetic.
I would like to see if your front-end could also improve the performances in this case. I will try to adapt it to the back-end constraints soon.
Unless your number types perform memory allocation, the chances are that expression templates may well not be an optimization (or even a slight dis-optimization). Even when memory allocation is performed and temporaries are expensive to construct, subjectively, the big performance gains only really happen when the system is under load - makes sense when you think about it - not sure how to go about quantifying that though :-( BTW, it's not documented, and may be slightly out of date now, but there's a trivial adapter template in boost/multiprecision/arithmetic_backend.hpp that allows any type with the usual arithmetic operators to be used with the expression template front end, so use would be: mp_number<arithmetic_backend<YourType> > It certainly won't give you optimized performance, but it may give you a quick and dirty idea as to whether writing a proper backend is worthwhile. HTH, John.