Boost logo

Boost :

From: Maarten Kronenburg (M.Kronenburg_at_[hidden])
Date: 2006-05-27 20:11:42

You were right, I will change the
const integer & parameters in get_sub
into size_type, just like in the allocator class,
and the highest_bit and lowest_bit will also
return size_type.
This also then holds for the shift parameters
of the shift functions.
When everything goes 64-bit the factor 8
argument will be history.
Regards, Maarten.

"Jarrad Waterloo" <jwaterloo_at_[hidden]> wrote in message
> Thank you for considering sub integers. Do you have a downloadable
> implementation of integer ready for people to play with? Where?
> Here are some final thoughts to consider?
> Revisions:
> > 1) The ability to extract sub integers out of an integer such as the
> integer
> > at bit offset 3 and length of 4. This is especially helpful in the area
> > RFID where large unsigned integers are partitioned into smaller
> >> As a response for a request for sub integers,
> >> in the document I will delete the is_even
> >> and is_odd member functions, and add:
> >> const integer highest_bit() const;
> >> const integer lowest_bit() const;
> >> const integer get_sub( const integer &, const integer & ) const;
> I would keep is_even and is_odd for performance and ease of use reasons
> because if highest_bit and lowest_bit represents a single bit than
> it should return a bool. Further, get_sub should have the following more
> frequently used overload.
> const integer get_sub( const unsigned long &, const unsigned long & )
> This function is easier to use with constants, faster because of no
> conversions to heavier objects and the most commonly used case because
> though infinite precision integers can have infinity of bits it is very
> unlikely that generally users will have a sub integer at offset 4 billion
> length 4 billion. What number would that reprensent! Doesn't the number of
> atoms in the known universal end before 256 bits! Anyway my point repeated
> throughout is ease of use to the user of the library with the best speed
> using the least memory even if it means making a library slightly more
> complex with extra commonly used methods or objects.
> > 2) The ability to convert integer to bases other than base 10; any
> > really from base 2-36
> >> The iostreams of the compilers I know only alow bases 8, 10 and 16,
> >> see also [lib.std.manip] setbase manipulator.
> >> The bases 2, 4, 5 can be easily converted from these bases.
> >> The other bases don't seem to have a useful application; they are
> >> also not supported for base type int, and not supported by printf
> >> formats or stream manipulators.
> itoa does take radix at runtime instead of a enumeration compile time
> constant. As such I was hoping the following methods were added.
> const std::string to string(const integer & arg, const unsigned char
> {
> // the implementation could use the algorithm where
> // the value is divided by the radix
> // the remained is pushed onto a stack of characters
> // and the dividend is fed back into this process until it is 0
> }
> Obviously it would be nice to have a constructor that could reverse this
> process. This method may perform better if there was a division method
> does / and % at the same time. Whether or not these methods should be
> functions instead of external or both is something I leave to be debated
> among OOP experts.
> > 3) An implementation of a fixed sized stack version of the
> > integer_allocator. This may be useful for performance when someone is
> > not working with an infinite precision integer but a very large one
> > such as 512 or 1024 bits.
> >> Users can implement such an allocator by deriving from
> >> override and implement allocate, reallocate and deallocate,
> >> and activate it.
> Yes users can do this themselves but if this is something that would be
> frequently considered or built by users than it might be better to go
> and make this library even more robust by providing it up front. Further
> this library is to behave like native int that can be created on the stack
> and the heap than it would still be part of your architecture to allow
> integer to be created on the stack and heap.
> > 4) An unsigned version of the integer class that benefits from the
> > higher performance of unsigned operations
> >> Users can implement an unsigned_integer by deriving from integer,
> >> but this will not give any performance gain.
> >> By the way I think base type unsigned int is also not faster
> >> than base type int.
> Yes users can do this themselves but if this is something that would be
> frequently considered or built by users than it might be better to go
> and make this library even more robust by providing it up front.
> Secondly, I had thought that a CPU processes unsigned faster than signed
> having evaluated the code of other C++ integer libraries the code for
> unsigned was less than for signed. However, I am no expert so I could be
> wrong on this performance question. As my first thought, people are in
> of this library now as a boost library or a preliminary boost library
> because most other libraries have awful license or is too difficult to
> in a windows environment as is the case of GMP. Help!
> _______________________________________________
> Unsubscribe & other changes:

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