Last year I wrote a library to handle units in C++. After using it for a year, I found it useful enought that I thought I'd post it. The last project I posted was to sourceforge. But this time, I thought I'd enter the "big time" and post it to boost. (Boost.org is where the next modifications to the standards for C++ are being written today.) I'll see how harsh they are over there.

Here is my post to the boost news group:

Thanks for the kind introduction to boost. I posted my library on yahoo with the name of units.zip. As an academic, I'm used to receiving nasty referee's reports, so hopefully I'll be thick skinned about comments. I thought I'd say a few things that I learned about a quantities library from using one for the past year.

In reading over the postings over the summer I think there are two different goals a quantities library could aspire to. The first is the SI goal: avoiding crashing into Mars and all that. The second is catching programming errors by making signatures of functions more useful. I built my library assuming that the primary goal was the first one. So I built in the ability to have inches, yards, rods, miles, meters, etc. But when it came time to actually use it, I almost never gave explicit values. So the first goal seemed to be less important than I originally thought.

What turned out to be very important to me was the ability to have signatures of functions that were meaningful. To achieve this goal it is very important for the quantities to be user defined. Let me explain via example.

A physicist has nice concepts like length, weight, etc. Obviously they need funding (lots of it in fact) so they also would want to have a unit to represent money. For them, they would be happy with a single type called "dollars." But now consider a trader on wall street. They need not only dollar, but also yen, pounds, etc. From their perspective all the fancy units of physics could be lumped together as a single unit called "physical unit". So they would measure corn in dollars/physical unit, where physical unit would be a bushel, and gold in yen/physical unit, where physical unit in this case would be a Troy ounce. This mixing up bushels (a measure of volume) and ounces (a measure of mass/weight) would case them almost no confusion.

But units can get even more divided than that. A trader might want to have different sorts of dollars. Not only is it important to differentiate current_dollars, from future_dollars, but bids might want to be separated from asks. So there could be many different sorts of dollars.

In fact, the system that I use my units classes in has two sorts of time. Both CPU time and wall clock time are different units. Both of them are naturally measured in something called seconds, BUT these two different times measure different things.

My point is that as far as making programs easy to read, the crucial goal of a quantities class is to make the signature of a function say what the function expects when it is called. Thus you want as few different types as possible subject to the constraint that there sufficient types so that functions rarely have a useless signature. So my goal is to switch useless signatures like:

• f(double a, double b, double c);

to:

• f(Dollars a, Bytes b, Time c);