
Boost Users : 
Subject: Re: [Boostusers] [units] Basic usage questions
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 20100729 15:57:26
AMDG
Bryce L Nordgren wrote:
> Q1
> =============================================================================
> What are the rules about what is allowed where? Or perhaps more
> appropriately, why are the rules so strange? I've been playing with units in
> boost 1.43.0 using gcc 4.4.3/mingw on win xp and I think I've deduced what
> is allowed.
>
> For instance, when declaring variables, you can do:
>
> quantity<si::length> l(1.0*si::meters) ;
> quantity<si::meter_base_unit::unit_type> l(1.0*si::meters) ;
> quantity<us::yard_base_unit::unit_type> l(1.0*si::meters) ;
>
> but not
>
> quantity<si::length> l(si::meters) ; (missing the scalar in front of the
> units) or
> quantity<si::meters> l(1.0*si::meters) ; (si::meters is not
> quantityvariabledeclaration material??!?)
>
si::length is a type. si::meters is an object of type si::length.
> Q2
> =============================================================================
> I spent a long time looking for a way to construct a variable with
> onthefly defined units, in order to store interim quantities which may
> have strange units when implementing the computation of a long expression.
> This would also be useful to precompute some terms which occur more than
> once, but which don't necessarily represent any kind of sensible value that
> you would return as a final result. I wanted to do something like this:
>
> quantity<si::length / si::mass> dummy_var_1 = (some_interim_expression
> reducing to si::length/si::mass)
>
> but I can't figure out how to do it. For the moment, I plan on just using
> the vast array of predefined units on the derived dimensions. However, it
> would be nice to be able to divide up the computation in whatever way seems
> natural given the equation, even if the interim variables don't represent
> rational physical quantities.
>
You can use divide_typeof_helper<si::length, si::mass>::type.
(This is necessary because si::length and si::mass are types,
not objects). However, it would probably be easier to
use Boost.Typeof:
BOOST_AUTO(dummy_var_1, some_interim_expression);
> Q3
> ===============================================================================
> And I suppose my last question is "What does a unit system buy you?",
> meaning that since "yards" is not part of a unit system and I can declare a
> variable of type quantity<us::yard_base_unit::unit_type>, what is the added
> benefit of constructing a unit system which contains yards?
>
There are several reasons:
* historical  we started with the system being just a tag.
the base unit concept was added later, and the systems
were reworked to match.
* trig functions  using a system allows asin(sin(1.0 * degrees))
to roundtrip. Without the extra infomration that systems
store, this would always return the angle in radians.
* conversions  systems are used internally by conversions.
> Don't misinterpret this as a string of complaints. :) I am very grateful to
> not have to write this myself. I'm just having some trouble understanding
> how to apply the library to my situation. ;)
>
In Christ,
Steven Watanabe
Boostusers list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net