Date: Mon, 7 May 2007 09:31:28 -0400 From: "Jarrad Waterloo" jwaterloo@dynamicquest.com
Could use constructors that take 64 bit integers
There wass a problem with this approach, but it seems that defining 4 constructors (int, unsigned int, uint64, int64) satisfies all needs. Will do. Yes, wchar_t and wstring support is required Added to todo list. conversion to and from string probably should go into static function; other
people's preference
I followed the way things like stringstream and boost::format behave. Suggestion noted though, I'd like to hear other opinions. Could we have conversions to and from strings of different bases 2-36 Indeed, I don't know why I missed it. Added to todo list.
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.
Sorry, that was indeed unclear. I merged 2 headers in 1 for posting here, serialization is in a separate header. 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
As I noted this will not be supported for all implementations because of increased complexity. The library initially will contain 2 implementations, one will be faster and will be based on GMP - this implementation will NOT support stack-based allocation. Another implementation will allow for arbitrary storage implementation that meets the interface constraints, possible syntax will be bigint_base<bigint_default_implementation<bigint_static_storage<256> > > (oh wel, I guess I will need to provide a helper, something like static_bigint<256>::type) 2nd to be able get and set sub integers for instance give me the integer at
bit 7 and goes for 21 bits.
I don't quite get it, do you want the ability to fetch separate bits or separate limbs (digits, etc. - the internal representation)? And anyway, what do you need it for? What behavior do you want for it in case of for example negative numbers?
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
I'd be happy to look at it, but I found only the initial post that said the pdf is in Boost Vault - but it seems it is not there any more. Thank you for your answer!