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.