From: Deane Yang (deane_yang_at_[hidden])
Date: 2006-08-21 18:27:32
Andy Little wrote:
>>>>> This brings up a good question. Say you have two objects:
>>>>>
>>>>> meters m = 1;
>>>>> feet f = 2;
>>>>>
>>>>> What is the type (or unit) of the following expression?
>>>>>
>>>> m + f;
>>>>
>>> I apologize for repeating myself, but I want this to fail to compile. I
>>> do not want implicit conversion of units. I believe I am not completely
>>> alone in this view.
>> Personally I love implicit unit conversions. :-)
>> I can add a function to prevent them, but you will have to apply that
>> explicitly:
>>
>> T b = no_cast(a);
>>
>> or some such.
>>
>> How's that?
>>
>> regards
>> Andy Little
>
> For addition you would need to do this:
>
> nocast(a) + nocast(b);
>
> for multiplication
>
> nocast(a) * nocast(b);
>
> You could make this a general purpose utility:
>
> template <typename T>
> struct no_caster{
> T t;
> /*...*/
> };
>
> template <typename T1, typename T2>
> typename boost:enable_if<
> boost::is_same<T1, T2>,T1
>> ::type
>
> operator Op (nocaster<T1> ,nocaster<T2>);
>
My main objection to this is that I am pretty sure that a quantity/units
library that does not do implicit unit conversion is a *lot* easier to
implement than one that does. And it's hard for me to believe that a
library that does automatic unit conversion doesn't have inside of it a
simpler non-automatic unit conversion library. So implementing explicit
unit conversion on top of an implicit conversion library seems, well,
backwards.
Deane