(All taken from http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/ht... )
* "Fixed at compile time values, for example 50 decimal digits"
Boost.LargeInt is designed to stick-together two existing integer or integer- like types, so although also being fixed at compile-time, it is fixed to a number of binary-bits rather than decimal digits.
Please note the "for example" part. Fixed precision integers are fixed to the number of bits in Boost.Multiprecision the same as yours are.
* "A header-only Boost license version is always available (if somewhat slower)."
Boost.LargeInt is solely header and template based, and so is fully compatible with, Boost License v1.0 without restriction. So, it performs as optimally as possible regardless of licensing requirements.
So no difference then? ;-)
* "You have to be careful to cast the result of an expression to the actual number type when passing an expression to a template function"
The results of all arithmetic operators in Boost.LargeInt are themselves boost::large_int::large_int based types, and so their use is fully transparent.
You can turn expression templates off in the multiprecision lib, in which case it behaves as yours does - in fact the expression templates are turned off for the fixed precision integer part, as it adds nothing there.
* All logical, arithmetic and bitwise operators in Boost.LargeInt have constant, O(1) complexity; except for multiplication ('*'), division ('/') and modulus ('%') which are O(n) on the number of bits in the respective large_int type. Hence support for non power-of-2 large_ints of 96bits, 160bits or otherwise may be used to improve calculation performance.
Congratulations, the Fields medal is clearly on it's way! Seriously, you might want to think again on those complexities...
* All boost::large_int::large_int based types are comparable against long-type literal values. (These get an automatic promotion to a boost::large_int equivalent to service said comparison.)
Likewise the multiprecision lib (in fact promotion to the extended type first isn't strictly necessary - you can do things more efficiently than that). Cheers, John.