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

Subject: Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012
From: John Maddock (boost.regex_at_[hidden])
Date: 2012-06-05 12:54:02

>> * 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?

No, but from a purely practical point of view, I believe the free function 
approach is easier for both the lib developer and a backend developer - 
overloading free functions is easy to do and the overload resolution rules 
well understood I believe.  In addition if someone wants to experiment with 
modifying an existing backend, then extending it's functionality by 
providing additional function overloads is simple, and requires no 
modification to the original header.

John.