--- Andy Little wrote:
Shouldn't the two parts be described as integer_part and fractional_part?
IMHO integer_part is not as descriptive as whole_part.
And also ... Why do they need to be macros?
The default implementations of whole_part and rational_part assume that the numeric constant is already a Mixed Number, with nested whole_part and rational_part typedefs. Any numeric constant that wants to be treated as a Mixed Number but can't provide these typedefs (e.g. double_c) must provide the necessary metafunction class specializations. However, for Rational Constants, whole_part and rational_part can be specialized in terms of the numerator and denominator metafunctions. If there are at least two such models of Rational Constants, the specialization code of whole_part and rational_part would have to be duplicated for each model. The macros are there to minimize this duplication. The same goes for the numerator and denominator of Mixed Numbers. [snip concepts discussion, started on new thread]
Also, Cromwell, do you think that rational numerator and denominator should be evaluated eagerly (as it currently is) or alternatively lazily, so that it would need some function to normalise the rational before or maybe during math?
I've exposed simplified_rational for use by those metafunctions that are guaranteed to return relatively prime numerators and denominators, e.g. rational_part_impl<double_tag>::apply. Those numeric metafunctions that cannot provide this guarantee must use either rational or rational_::simplify.
(FWIW my vote is to stay with current behaviour though using rational<numerator,denominator> for ::type member.)
Is the current definition sufficient? template <typename N, typename D> struct rational : rational_::simplify<N,D>::type { };
Meanwhile keep up the good work..
Thanks! Cromwell D. Enage __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com