Subject: Re: [boost] [multiprecision] General/design query about which conversions should be implicit/explicit
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2014-05-31 08:16:55
2014-05-31 13:56 GMT+02:00 John Maddock <jz.maddock_at_[hidden]>:
> 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
> 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 :-(
> Does anyone else have any strong views or insights into this?
I remember when discussing the interface of std::optional on
people were against having the conversion from U to optional<T> (where U is
convertible to T) because it incurred a run-time cost not immediately
visible to the guy that used the code:
fun(u); // may last longer than you think
Instead a more verbose/explicit construct was preferred.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk