From what I have read from other bigint and other boost api's serialization is prefered if it was in a seperate header so that it won't become part of
Could use constructors that take 64 bit integers Yes, wchar_t and wstring support is required conversion to and from string probably should go into static function; other people's preference Could we have conversions to and from strings of different bases 2-36 the build if not used.
On a side note sometimes people need bigger_ints that are not of infinite precision that could be created on the stack. Problem domains would include RFID and other identification schemes. As such it would be nice to have
"Jarrad Waterloo" wrote in message... the
following: Ability to created a stack allocated bigger_int<128> similar in design to the bitset 2nd to be able get and set sub integers for instance give me the integer at bit 7 and goes for 21 bits.
Other proposals out there for review are Proposal for an Infinite Precision Integer for Library Technical Report 2 Draft by M.Kronenburg@inter.nl.net
Yes, that is N2143 on http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/#mailing2007-01 Currently I am working (in my free time) on an implementation, which will also have assembler for x86, and will thus be only a little slower than GMP on x86. An integer allocated on the stack will I suppose be about as fast as an integer allocated in a memory pool. Also I will add a memory pool allocator to my implementation. The problem I see with a fixed size integer is that everyone will be using different sizes for essentially the same problems. How should the programmer choose the size to be used? Regards, Maarten.