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

Subject: Re: [Boost-users] [boost][multiprecision] compile error with gcc 4.8.4
From: John Maddock (jz.maddock_at_[hidden])
Date: 2016-09-24 11:31:52

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_at_[hidden]
> *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 <jz.maddock_at_[hidden] 
> <mailto:jz.maddock_at_[hidden]>> wrote:
>
>>
>>
>> On 17/09/2016 18:35, Rob Conde wrote:
>>> The following works with me in visual studio with toolset v120 and v140.
>>>
>>> #include <boost/multiprecision/cpp_int.hpp>
>>> #include <boost/multiprecision/cpp_bin_float.hpp>
>>> #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<int128_t>());
>>>
>>>   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<int128_t>().
>>>
>>> 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_at_[hidden] <mailto:Boost-users_at_[hidden]>
>> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users