Many thanks Jeff for managing the review!
Performance -------- Phil, the lone NO vote, lamented that the scope of the library was evidently beyond simple fixed-precision (e.g., 128-bit or 256-bit) integral types, which is his desired use case. Indeed, at least in an earlier version of MP, expression templates seemed to give a performance penalty relative to using the raw back-end types; in theory, expression templates should give no performance hit, but compilers just may not be there yet. In any case, several reviewers requested that the scope of the library be clarified up front in the documentation.
As noted in a recent post - the cost of wrapping a native type inside mp_number should be close to zero now *when expression templates are off*. When ET's are turned on, this will always IMO be slower, consider an operator returning an expression template - it's basically returning a pair of references (and larger objects still for more complex expressions), where as say a wrapped integer is actually returning a smaller cheaper to copy object in that case. So for a wrapped integer, returning the result by value will always win out, and that's before you even consider the cost of unpacking the expression template. So, basically reserve expression templates for objects that are either large and/or allocate memory: I'll try to make that clearer in the docs. ~~~~ I have an open question for you all: I was planning on working on cpp_int performance next, and trying to improve the computation geometry use cases. Obviously that pushes back a potential release. The alternative is to address all the issues relating to the front end first, and aim for an earlier first release. Which would folks prefer? Regards, John.