Yessir...

On Tue, Jul 26, 2011 at 2:29 PM, Noah Roberts <roberts.noah@gmail.com> wrote:
On 7/26/2011 8:30 AM, Michael Powell wrote:
Boost::units users,

How do I get at the unit symbol or name? I think this type thing would
be essential when receiving and parsing textual quantities from a client
side application. So say I am given "1.0 in" or "2.3 m/s^2" and so on,
and be able to translate that into the appropriate compile-time
dimensional quantity.

Units are streamable and thus also can be lexical_cast.

template < typename Unit >
std::string label(Unit u) { return lexical_cast<std::string>(u); }

Being able to read them in the other way would be as simple as matching the unit you expect to the one you've gotten.  I can't think of any way to match some generic unit and return it since every unit is a different type.  You simply have to know what to expect with this library.

True, true. This is true whether we're talking about boost::units or some other somewhat-off-the-shelf library, or a more roll-your-own approach.
 
What you might be looking for here is a runtime unit system.  I devised such a system around the boost quantity system that somewhat works. Unfortunately I can't share it.

This is basically where we're at. The claims of "zero overhead" are only partly true, as you and I are finding, because in order to use the library in any useful context, plumbing has to be built up around it to get at the calculations and conversions.
 
 Basically I have a unit that does conversions, a quantity that stores a value, and these types convert to/from the boost versions of the same dimension before going into math functions.  All forms of I/O and user interaction are done in this wrapped thing and all formulas are done in a particular boost::units system.  It wasn't too difficult (except for some unfortunate things I was forced into--such as treating 3 different kinds of flow as the same variable).
 
Also basically where we're at. I convinced my senior guy that we should focus on conversions at a later point and get the calculations working first, making the assumption we're communicating in the same base units.

After that, will focus on the run-time unit conversions, base units, and so forth. This allows me to focus on the models and the math apart from that plumbing.