Yessir...
On Tue, Jul 26, 2011 at 2:29 PM, Noah Roberts
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_caststd::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.