Re: [boost] Infinite precision integer draft

From: Jarrad Waterloo (jwaterloo_at_[hidden])
Date: 2006-05-30 11:12:57

Thanks for the welcome of all the other enhancements, especially in the area
of conversion, to make your integer library easy to use for everyone.

Further, don't get discouraged as your colleagues discuss the meaning of 0,
life and the universe while people who actually would use it already
understand what 0 means because we have been without, 0, this library for so
long.

'Feed a mouse a cookie and he will ask for a glass of milk.'

> Creating integers with variable size on the stack,
> that is in any case something that I will not
> specify, but users that want to use these tricks
> can just override the integer_allocator.

Currently you have an integer class which takes an integer_allocator base
class. Even though the spec doesn't mention this or I glossed over reading
it but you probably are going to provide a heap_integer_allocator class that
could be named whatever but exists as the default integer_allocator for the
integer class. This way users can just start using the library right away
instead creating there own allocator the first time they use this library.

What I was suggesting was not a change to the integer, integer_allocator
base class or the currently unnamed heap_integer_allocator! Rather the
addition of a stack_integer_allocator<size_t> : public integer_allocator.

The reasons for the library to provide this instead of the end user is as
follows:
1) Performance, stack based allocations are faster than heap based and in
some field domains one will know the upper limit on size. This generates the
need for multiple people wanting to do this especially when performance
matters.
2) Standardization, if you foresee that many people are going to need this
functionality than your library becomes easier because you can go ahead and
provide the class instead of a large unsigned integer of people having to
reinvent the wheel and create the exact same class themselves.
3) Maintain ease of use as complexity increases, in just this one area this
library could suffer from the opposite problem of the standard library. The
standard library algorithms was all passing 2 iterators around which allows
for maximum flexibility for more complicated scenarios but lacked the
overrides like boost Range where you could pass the collection and the
algorithm uses begin and end for the more common and simple scenarios.
Integer library does the opposite which is mostly good, it provides the heap
allocator for the most common and general use but as complexity increases
and someone needs stack based allocator the user is left in the lurch and
have to right there own, over and over again from user to user. I just
believe this library would be more feature complete if it would just go
ahead and provide the both implementations up front.
4) Architectural consistency, this library is designed to behave like
existing integer types that can be created both on the stack and on the
heap.