Boost logo

Boost :

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

Steven Watanabe wrote:
> Noah Roberts <roberts.noah <at>> 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;


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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at