Re: [boost] [multiprecision] General/design query about which conversions should be implicit/explicit

Subject: Re: [boost] [multiprecision] General/design query about which conversions should be implicit/explicit
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2014-05-31 14:37:02

On May 31, 2014 7:56:00 AM EDT, John Maddock <jz.maddock_at_[hidden]> wrote:
>Folks,
>
>I have an open bug report https://svn.boost.org/trac/boost/ticket/10082
>
>that requests that conversions from floating point to rational 
>multiprecision-types be made implicit (currently they're explicit).
>
>Now on the one hand the bug report is correct: these are non-lossy 
>conversions, so there's no harm in them being implicit.  However, it 
>still sort of feels wrong to me, the only arguments against I can come 
>up with are:
>
>1) An implicit conversion lets you assign values such as 0.1 to a 
>rational (which actually leads to 3602879701896397/36028797018963968
>not 
>1/10), where as making the conversion explicit at least forces you to 
>use a cast (or an explicit construction).
>2) Floating point values can result in arbitrarily large integer parts 
>to the rational, effectively running the machine out of memory. 
>Arguably the converting constructor should guard against that, though 
>frankly exactly how is less clear :-(

Apparently the problem isn't as bad as you first thought, but implicitly allocating significant amounts of memory is problematic. You could punt and use the preprocessor to control whether the conversion is explicit.

___
Rob

(Sent from my portable computation engine)