Boost logo

Boost :

Subject: Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012
From: John Maddock (boost.regex_at_[hidden])
Date: 2012-06-06 04:10:52


>> On Tue, Jun 5, 2012 at 10:26 AM, John Maddock
>> <boost.regex_at_[hidden]>wrote:
>>> Also just realized that while a simple adapter backend:
>>>
>>> template <class BigInteger>
>>> class exact_float;
>>>
>>> Would be more or less trivial as far as the arithmetic goes, other stuff
>>> like string conversion would be *much* more complex, exactly which
>>> conversions and/or string formatting should be supported would require
>>> some
>>> careful thought.
>>
>> Yes, agreed regarding the trickiness of string conversions :( I guess if
>> one doesn't want or need to implement such facilities, one could just
>> throw
>> on such overloads.
>
> Actually, one could see it as a weakness of the library that so many of
> the requirements are compulsory and not optional.

Actually, there isn't a huge list of compulsory requirements, and even then
the term "compulsory" might need revising - maybe more like
"non-synthesizable". So if you want all of mp_number's documented
operations to work, then you need to implement all of the
"non-synthesizable" requirements. However, for a type like a ring, you
wouldn't implement eval_divide even though it's one of the "compulsory"
requirements - the result would be that the divide operator for
mp_number<my_ring> wouldn't instantiate, but everything else you've
implemented would.

John.


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