On Thu, May 31, 2012 at 11:17 AM, John Maddock <boost.regex@virgin.net>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