do you mean that it's possible to use std::allocator methods in order to grow allocated space without the need to initialize it again with old data ?
No, I meant that you can use the realloc() function throughout the library without having to worry about whether the user passed in an allocator with std::allocator interface or an allocator that supports realloc(). By specializing a struct on the allocator type, it will act as a proxy and you call the struct's realloc() in the library. If the user passes in std::allocator the proxy realloc() function will still do an alloc/copy/destroy.
(4) decide if we have to use exception handling C++ constructs for arithmetic exceptions ( divide by zero, etc) or simply abort the program; this is essentially a matter of performance;
Not just a matter of performance but also one of interface, usually bigint will be used with data that comes from outside the program so programmer has to be prepared to catch bigint exceptions. This could be parameterized <bool use_exceptions = true/false>. A member variable to hold some state about the bigint will be useful, that way you can check for overflow, divide by zero and encode +inf, -inf, etc.
(12) it would be nice to support infinity and indefinite forms, but it could mean performance problems because we'd have to evaluate all possible cases, maybe it will be better realize a specific wrapper/adaptor class for such a goal, moreover this class adaptor could be used also for standard integral type;
I suggest as above having a state variable, I suspect checking for the states gets lost in the noise especially when the numbers get large.
I don't know if checking for states doesn't matter compared to the complexity of multi precision algorithms. It's possible, I should try.
parametrization for infinity, NaN and exception it's ok; anyway what I wanted to point out it's that in the case there is a performance loss, managing infinity and undefined states, then it is better to implement different classes and it's so even using template parameters: for instance classes big_integer<WITH_INF> and big_integer<WITHOUT_INF> ( WITH_INF = true, WITHOUT_INF = false, and I've omitted the other template parameters ) will exdend a common class in such a way to share as much as possible, but they will be two different template specialization of <bool use_inf>.
It sounds like this will make things more complex than necessary. I just looked at the GMP manual [http://gmplib.org/manual/] and it looks like they don't support infinities etc. in fact they don't handle division by zero either because "This lets a program handle arithmetic exceptions in these functions the same way as for normal C int arithmetic." Kevin