The next version of my physical quantities libary pqs-1-01-04 is available on my site at: http://www.servocomm.freeserve.co.uk/Cpp/pqs-1-01-04/download.html The original type has now been augmented by another. The original type has now been renamed as a 'ct-quantity' representing a physical quantity whose units cannot be modified at run-time. The other type is the 'rt-quantity', whose units can be modified at run-time. The two types are of course compatible and the rt-quantity in particular is useful for further derivation, for instance into a physical quantity whose units can be set and interrogated via strings ie "mm, kgf" etc of which there is an example in the examples directory. The first question many will ask about such a library is : "How does the run-time speed/memory performance compare with using inbuilt types?." That is an important question, but to me not the most important one. (The answer is that this is implementation dependent and the current implementation is not optimal) Having used the library for some time its power seems to lie in the fact that it models a concept quite accurately from a programmers point of view. IOW what you can do with the type is restricted (by the compiler) to (some subset of) the entity that it models. The reason that this is powerful is difficult to define, but can be summed up in the saying: " a picture is worth a thousand words" I now see more clearly what those who wanted to see currency conversion and number of apples per kumquat or whatever where driving at. However these are not physical-quantities. C++ does have the ability to express those concepts, but they lie outside the remit of the concept that this library models. Nontheless such concepts would be useful. So in a network model a byte, packet etc would be a concept which would be modelled by a C++ type. Strongly enforcing the rules by which entities interact is satisfying , I guess, because it clarifies the mental picture of a program. Modelling everything by a double or an int (should number_of_bytes_received be convertible to double ... probably not etc) means everything is mush. So on a personal note designing the library has been very rewarding. As I spend much time GUI programming, it strikes me that the next useful concepts are those of model-space, view-space, paper-space etc. Here a point in space would be represented by different types which could only exist in the relevent space, but have the intelligence to perform transforms from one space to another. Similarly where one is modelling (say) magnetic flux density at a point x, y, z , the role of the view-space would be to convert form the entity in model-space to 'some representation ' in the view-space or the paper-space. The obvious candidates for the types in model-space being the ct-quantity of course. regards Andy Little