"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" wrote
"Andy Little" writes:
"David Abrahams" wrote
"Andy Little" writes:
I don't see what the presence of numerator and denominator has to do with normalization.
They should be typedefs for the input parameters?
Hmm, is that meant to be a question?
What does that have to do with normalization?
Are you referring to my use of the word 'normalisation'
Yes.
to mean making my_rational<2,8>::type == my_rational<1,4>? Maybe the use of the word normalisation here is not correct. Is that the problem?
No. Please take me literally. I don't see any relationship between whether we provide numerator/denominator member typedefs and normalisation (or normalization).
[cut]
Who suggested a special case?
Whoever said , " Is it daft to want my_rational<x,1> to be a conforming MPL integral constant?" .
That doesn't require any special case code.
At least in terms of the value and value_type members it does:
http://www.boost.org/libs/mpl/doc/refmanual/integral-constant.html
I don't see why the type member is an issue, but yeah, you're right, the value member would be a problem.
Conversion is fine. Thats not what you said above.
No, it's not what I said above. Remember, the usual runtime logic doesn't necessarily apply. my_rational<x,1> can be an integral constant *at compile time*. I'm not sure it's useful, but it's not insane.
Its difficult to know what you mean. Do you mean something like:
template < typename Numerator, typename Denominator
where Denominator == One struct my_rational : Numerator {/*...*/};
Yes, something like that. Maybe a silly idea, but not insane. -- Dave Abrahams Boost Consulting www.boost-consulting.com