Re: [boost] mcs::units informal review request

From: Noah Roberts (roberts.noah_at_[hidden])
Date: 2007-02-16 18:02:32

Steven Watanabe wrote:
> AMDG
> 
> Noah Roberts <roberts.noah <at> gmail.com> writes:
> 
>>> My question was: Why should x and y store the
>>> unit, when that information is just going to
>>> be thrown away and replaced by user_selected_unit?
>> Well, presumably it is used elsewhere.
>>
>>> Is this converted value going to be used for
>>> any other purpose than to output it or convert
>>> it back to the base system for more calculation?
>> No.
> 
> Then why go to the trouble of providing
> all the arithmetic functions?

Because they are occasionally useful.

dp = inlet - outlet;

vs.

dp = (inlet.quantity() - outlet.quantity()) * dp.unit();

>> quantity f() { static quantity const C = 9.43 * psi; ... equation 
>> written with psi constant ... }
> 
> I don't understand what is wrong with
> 
> quantity<psi_type> f() {
>     static quantity<psi_type> const C = 9.43 * psi;
>     ... equation written with psi constant ...
> }

Well, if we are talking about in terms of the current proposal I believe 
that would result in a lot of conversions from psi to pascals (assuming 
si base).  Because now C is in some psi system whereas the rest of the 
function uses the SI system.  Incredibly inefficient.

> 
>>> quantity<pressure> p1(psi);
>>> quantity<pressure> p2(pascals);
>>> p1 = whatever;
>>> p2 = p1;
>>>
>>> Now, what should the unit of p2 be?
>> pascals.  The rule is conversion on assignment.  This does cause some 
>> need to be careful with such things as std containers that work through 
>> assignment.
>>
> 
> Right.  I can't see a way to make a std container
> that holds quantities of different units safe at all.

Most commonly you would not want them to convert to a different unit on 
assignment.  You would want the elements in your container to stay a 
certain unit while converting whatever value is being assigned to that 
unit.  When that is not what is wanted a wrapper is needed.