Boost logo

Boost :

From: Jarrad Waterloo (jwaterloo_at_[hidden])
Date: 2007-05-07 09:31:28

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
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]

-----Original Message-----
From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
On Behalf Of Arseny Kapoulkine
Sent: Monday, May 07, 2007 8:54 AM
To: boost_at_[hidden]
Subject: [boost] Boost::Bigint header draft - suggestions are welcome!


I am the student that was lucky enough to be selected as the developer of
Boost Bigint library as a Summer Of Code project. I've started working on
the project earlier than I had to, and there is a header draft ready which
I'd like to share with you - there are some issues that are not quite clear
(I've marked them with comments), and I would very much like to hear
possible problems with the current interface/suggestions about

The header is here: (the SVN repository
was just set up, so I did not have enough time to upload all necessary files
to it).

Note, that while the reference (GMP-based) implementation is more than 50%
done (actually, it's almost done, some issues with string conversion and
64-bit correctness remain), I've stripped everything related to
implementation from the header - implementation is subject to change, it's
not finished, and possible interface changes could affect either the
implementation class interface or the actual implementation.

The suggestions that ARE known:
- the bigint class may benefit from expression templates/move semantics
regardless of the actual implementation behind the scenes. This is a known
thing, and I'll address it once all base things (stable header, 2 stable
implementation, test suite, documentation) are finished
- initially the approach that allowed to freely mix implementation strategy
(i.e. performing calculations) and storage strategy (memory management) was
selected, but after concept drafts it was clear that it will restrict the
possible implementations or make writing a wrapper for existing libraries
too complicated or even impossible. Now the implementation has to performn
its own memory management, though the default implementation (portable C++
one which will not depend on any third-party libraries) will provide a
reusable storage strategy (if that was unclear,

Thanks in advance.
Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at