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;
> 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
> 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
> RFID and other identification schemes. As such it would be nice to have
> 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
> bit 7 and goes for 21 bits.
> Other proposals out there for review are Proposal for an Infinite
> Integer for Library Technical Report 2 Draft by M.Kronenburg_at_[hidden]
Yes, that is N2143 on
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
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk