Boost Users :
Subject: Re: [Boost-users] [boost.multiprecision] export_bits throws on a negative cpp_int number
From: John Maddock (jz.maddock_at_[hidden])
Date: 2016-04-28 08:08:52
On 28/04/2016 08:05, Tassilo Glander wrote:
> Dear List,
> When calling export_bits on a negative boost::multiprecision number based on cpp_int, an exception is thrown from the internal method msb ("testing individual bits in negative values is not supported").
> boost::multiprecision::checked_int128_t i (-1); // use negative number
> std::vector<unsigned char> v;
> export_bits(i, std::back_inserter(v), 8); // throws
> How can I extract the content of a boost::multiprecision number? Boost documentation says, export_bits is designed to be used for data exchange, so in my understanding it would be a major flaw, if it cannot export supported values.
> I learnt that a workaround might be to directly access the backend's limbs, but this way I am accessing internals that may change.
The issue here is that there is no portable bit-format for negative
numbers, and in particular cpp_int does not use a 2's complement format
if that's what you were expecting.
So... while this should probably work to some degree (or at least give a
better error message), what you're doing leads to all kinds of undefined
behaviour. Bottom line, is that depending what you intend to do with
the bits, you will need to handle negative values separately anyway. So
a better workaround would be to only call export_bits on positive
values. Of course this is potentially inefficient in that you will need
a temporary copy of the value.... so thinking about it, yes you're right
it's a bug, export_bits should export the unsigned value of the object
even when the object is negative.
> I also asked this on http://stackoverflow.com/questions/36890928/boostmultiprecisionexport-bits-throws-on-a-negative-cpp-int-number, but this list is probably the better place.
> Boost-users mailing list
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net