Daryle Walker wrote:
Wouldn't that be giving away an implementation detail? I wonder if we could use the gcd & lcm functions I defined in boost::math? (They were written after boost::rational was.)
1) The argumentation should be vice versa: The **current** interface of the gcd and lcm function templates **is** implementation-driven! The reason is that these functions would otherwise need to make a copy of their arguments - all but not the second argument of the lcm function. This is also documented in the code of gcd function template. This might sound nitty-picky on the first view, but please consider that the rational class template is explicitely designed to handle arbitrary integer-like underlying types, thus including a possible unlimited-precision integer type (which is currently under proposal for standard C++) - this is explicitely expressed in http://www.boost.org/libs/rational/rational.html Therefore any **unnecessary** argument copies should be prevented. I proposed boost::call_traits because it was already used in this header (in the definition of the rational class template itself). 2) It seems as if the functions of common_factor_rt are prepared for that, although I only skimmed over the code. Honestly from the current boost docs in http://www.boost.org/libs/math/doc/common_factor.html I could not extract the exact requirements on the template parameter for common_factor_rt. It just says "This type should be a numeric type that represents integers". What does that mean under the language restrictions of C++? (Note that the boost::rational docs describe specific requirements on this type, see corresponding section "Integer Type Requirements") Greetings, Daniel