Re: [boost] Boost::Bigint header draft - suggestions are welcome!

From: Maarten Kronenburg (M.Kronenburg_at_[hidden])
Date: 2007-05-07 15:04:46

"Jarrad Waterloo"  wrote in message...
> 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
> >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
> 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
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_at_[hidden]
>
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.