Boost logo

Boost :

Subject: Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-06-02 17:22:05


Le 31/05/12 22:24, Christopher Kormanyos a écrit :
>>> * having an implicit narrowing conversion from double to bigint is a bad idea,
>>> it should be explicit (it isn't completely obvious from the doc if that is the case).
>
>> It's pretty hard to have some constructor conversions implicit and others explicit.
>> Might be possible with enable_if though. Will investigate.
> It's a good comment. You know, a third of the people want it
> one way, another third want it the other way and the others
> don't care.
This is why creating generic libraries is hard. mp_number is a generic
class that should provide whatever implicit/explicit constructor the
backend supports. I expect enable_if to allow to define such interface.
I'm not saying I have a complete solution already. In general, I will
not provide implicit conversions when there is a lost of information.
Whether this is a major feature for your library is something we can
discuss.

>
> You know, my initial design of the floating-point type did not feature
> this kind of conversion. But my opinion differed from the established
> one of boost and I adapted to boost when writing for boost.
>
> In fact, I believe that Boost.Math already set the bar on this
> one because when using Boost.Math with an extended precision
> type (this is possible), all implicit conversions to/from the built-in
> types are supported.
I have no experience with Boot.Math, but I suspect that there are cases
where these implicit conversions are not desired, e.g when information
is lost.
> I believe it would be incorrect to treat interaction with built-in
> types behave one way in Boost.Math and a different way in a
> potential Boost.Multiprecision.
>
> This is my opinion. Others will have different opinions.
>
I suspect that I need to see how Boost.Math works :-)

Best,
Vicente


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk