rational - 1.64 version shear?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

rational - 1.64 version shear?

Boost - Users mailing list
With boost/rational.hpp, the code:

    boost::rational<int> a{1};
    long b{1};
    auto c{a * b};

Works fine up to 1.63.0, but fails to compile in 1.64+ on the
multiplication with "error: invalid operands to binary expression".
This seems to be due to some restructuring that changed the way
multiplications are declared, which (as far as I can tell), meant the
operation declaration became conditional on number of representable
digits.

This breaking change isn't listed on the release notes or the
::rational documentation, so I'm wondering if it was accidental and
therefore a bug (whose behaviour might change), or a deliberate change
to prevent downcasting and just undocumented?

Nick

(I've come onto a project stuck on 1.56 and trying to update it)
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: rational - 1.64 version shear?

Boost - Users mailing list


On 13/07/2017 23:17, Nicholas Devenish via Boost-users wrote:

> With boost/rational.hpp, the code:
>
>      boost::rational<int> a{1};
>      long b{1};
>      auto c{a * b};
>
> Works fine up to 1.63.0, but fails to compile in 1.64+ on the
> multiplication with "error: invalid operands to binary expression".
> This seems to be due to some restructuring that changed the way
> multiplications are declared, which (as far as I can tell), meant the
> operation declaration became conditional on number of representable
> digits.
>
> This breaking change isn't listed on the release notes or the
> ::rational documentation, so I'm wondering if it was accidental and
> therefore a bug (whose behaviour might change), or a deliberate change
> to prevent downcasting and just undocumented?

That was my change - it was a bug fix, and actually brings the behaviour
closer to what was always documented, in particular that accidental
assignment from float's should be prohibited.  At the same time I
tightened up integer conversions so that "lossy" conversions have to be
explicitly casted.  And yes, it should have been documented... I'll sort
something out for that.

Best, John.

>
> Nick
>
> (I've come onto a project stuck on 1.56 and trying to update it)
> _______________________________________________
> Boost-users mailing list
> [hidden email]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>


---
This email has been checked for viruses by AVG.
http://www.avg.com

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Loading...