Re: [Boost-users] [units] Basic usage questions

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:

quantitysi::length l(1.0*si::meters) ; quantitysi::meter_base_unit::unit_type l(1.0*si::meters) ; quantityus::yard_base_unit::unit_type l(1.0*si::meters) ;

but not

quantitysi::length l(si::meters) ; (missing the scalar in front of the units) or quantitysi::meters l(1.0*si::meters) ; (si::meters is not quantity-variable-declaration 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 on-the-fly 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 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::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 quantityus::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 round-trip. 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