Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2005-10-24 08:38:14


"Andy Little" <andy_at_[hidden]> 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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk