Re: [Boost-users] boost::units units symbols/names

Subject: Re: [Boost-users] boost::units units symbols/names
From: Michael Powell (mwpowellnm_at_[hidden])
Date: 2011-07-26 16:42:10

Yessir...

On Tue, Jul 26, 2011 at 2:29 PM, Noah Roberts <roberts.noah_at_[hidden]>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.