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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk