Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012

Subject: Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-06-05 11:21:28

On Thu, May 31, 2012 at 11:17 AM, John Maddock <boost.regex_at_[hidden]>wrote:
[...]

>  * Why have you chosen the following requirements for the backend?
>> - negate instead of operator-()
>> - eval_op instead of operator op=()
>> - eval_convert_to instead of explicit operator T()
>> - eval_floor instead of floor
>>
>
> * non-member functions are required if defaults are to be provided for the
> optional requirements.
> * There are some non-members that can't be written as overloaded
> non-member operators but can named free functions (sorry I forget which
> ones, but I remember seeing one or two along the way).
> * explicit conversions aren't well supported at present.
> * Compiler bug workaround (older GCC versions), there's a note at the
> requirements section: "The non-member functions are all named with an
> "eval_" prefix to avoid conflicts with template classes of the same name -
> in point of fact this naming convention shouldn't be necessary, but rather
> works around some compiler bugs. "
>

One alternative to using a collection of free functions and metafunctions
to extend an interface for a given type is to first mediate this
customization via a traits class with static member functions and nested
typedefs and metafunctions. Indeed, the default implementation of the
traits class would just use the (perhaps overridden) free functions. John:
Have you considered this extra level of indirection, or do you have any
comments on this?

- Jeff