Boost logo

Boost :

From: Andy Little (andy_at_[hidden])
Date: 2004-10-22 06:08:40


I have been continuing with my physical-quantities library over the last
and I am now seeking feedback as to whether it is worth putting this forward
as a boost library proposal....


The physical-quantity type-family provides methods for modeling
physical-quantities in C++ programs. The advantages and extra functionality
over inbuilt types used in the role include, compile time
dimensional-analysis checking, automatic conversion between units and an
increase in source code comprehensibility. The type family includes two
types, firstly a type where the units are fixed at compile-time referred to
in the text as a ct-quantity and secondly a type where the units can be
run-time modified, referred to in the text as an rt-quantity.

The ct-quantity has many similar features to an inbuilt-type:

- concrete type with simple,consistent semantics close to those of
- aims for speed and code size performance close to that of in-built types.
- requires no special framework to use.

*Application areas*

The application areas are very wide, including scientific-engineering, CAD,
3D games programming among many others.

*Future directions*

2D and 3D vector quantities, scene-graphs and scene-modelling, Graphics
interface (eg OpenGL), splines and curve analysis, successive approaximation
, piecewise differentiation and integration algorithms. finite element
analysis, etc etc.

Issues from the previous thread on the library and physical quantities in

issue: Angles.

current status: Angles are implemented.There are two types, irrational (ie
radians) and
rational fractions of revolution ie degrees minutes etc). radians are what
you might call a 'weak type'. (Though this behaviour can be modified by a
macro switch). They will implicitly decay to (say) double and can be
implicitly cast to double. However they also allow implicit conversions to
and from degrees etc. hence an implicit conversion from degrees to radians
can occur if a function has a radians argument, but not a double argument.
They are also useful for output of units.
issue: Differentiating different but dimensionally equivalent types.

current status: This is implemented.
issue: Implicit conversions between units.

current status: Implicit conversions are intrinsic. They are practical
instinctive and
issue: You should be using mpl.

current status: Hopefully I will be able to get hold of the metaprogramming
book soon, at
which point I can decide whether there are advantages.

Andy Little

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