On 12/09/2011 13:10, John Maddock wrote:
It's not: the issue is that a proto-ized type is used as an argument to template functions, so you get quite a deep instantiation tree even before the proto-expressions start to get instantiated. That said I don't have any issues instantiating those functions with mpfr_class (http://math.berkeley.edu/~wilken/code/gmpfrxx/) - which uses it's own (admittedly fairly simple) expression-template code.
You could directly use your own backend with the associated evaluation functions that don't require any expression templates. I don't really see what expression templates bring to your big_number classes. The only use I see for that kind of thing is recognizing certain patterns of operators to call a better primitive. But in the internals you know what the patterns are, and you can optimize them by hand. Otherwise, I gave a cursory look at your code, and it doesn't seem to be making good use of Proto, especially in the file big_number_base.hpp The whole expression_type thing seems unnecessary and the assign_and_eval_imp look like badly-written (and slow) grammars.