Re: [Boost-users] [boost][multiprecision] compile error with gcc 4.8.4

On 23/09/2016 19:13, Rob Conde wrote:

John,

In the meantime, consider the following workaround:

std::ostringstream o;

o << std::fixed << std::setprecision(1) << tmp;

int128_t roundedNanoseconds(o.str().substr(0,o.tellp() - std::streampos(2)));

Does that seem reasonable, or do you see a much cleaner or efficient approach?

Nod. As a temporary workaround that would work. Longer term a more efficient solution is to use ldexp/frexp to pull off N bits at a time.

Would be nicer to use setprecision(0), but:

https://svn.boost.org/trac/boost/ticket/10103

Yes, I know. That's another one I need to work on / think about. Best, John.

Thanks for your input,

Rob Conde

------------------------------------------------------------------------ *From:* Rob Conde *Sent:* Saturday, September 17, 2016 3:57:39 PM *To:* boost-users@lists.boost.org *Subject:* Re: [Boost-users] [boost][multiprecision] compile error with gcc 4.8.4 Understood...thanks for your effort.

Rob Conde

Sent from my iPhone

On Sep 17, 2016, at 2:43 PM, John Maddock mailto:jz.maddock@googlemail.com> wrote:

...

On 17/09/2016 18:35, Rob Conde wrote:

...

The following works with me in visual studio with toolset v120 and v140.

#include #include #include <iostream>

typedef boost::multiprecision::int128_t int128_t; typedef boost::multiprecision::cpp_bin_float_quad float128_t;

void main() { float128_t floatVal("6.0");

int128_t iVal(floatVal.convert_to());

std::cout << iVal << std::endl; }

If I change it to have a fractional component, then indeed I get an exception...maybe that's what you mean. I personally only need the above behavior (though keeping the c++ truncation semantics might make sense as a long term goal...but i digress). I always floor/ceil because call convert_to().

Using boost 1.61 and gcc version 4.4.7, the above also compiles and works.

OK, I see that compiles with 1.61, it does not with current master though (what will be 1.62).

In 1.61 the code performs a lexical_cast for the conversion - that works more or less by accident for small integers, but for large ones it fails at runtime (as an exception) as the numbers get printed in scientific format during the lexical_cast. Conversion to long long works fine though, and probably in all the cases that your conversion to int128_t does.

As I said, I need to figure out some more consistent behaviour for future releases.

John. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org mailto:Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users