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. Thanks... Regards, Michael
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. 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. 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).
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.
On 7/26/2011 1:42 PM, Michael Powell wrote:
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.
The claim of zero overhead is only mostly true, but not because it doesn't do runtime unit conversions. It's only mostly true because: 1) There's actually a significant overhead at compile time. I believe this is a worthy sacrifice but it's something that needs to be considered. 2) It depends on compiler optimizations that don't always happen. It *should* be zero overhead because the function calls and such should be optimized away such that the machine code is the same as if the type were a double, but I've noticed this doesn't always happen. Of course it obviously does not when debug mode is on. Boost.Units never claims to be an answer for "userland units".
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.
This should be natural. Build the models to work in some fundamental set of unit types that is standardized across the entire architecture. Then use unit conversions between the models and their views.
Yep. It's been several years since I've been involved with any sort of UOM
framework. At the time, it was a roll-your-own Java experience, using its
very powerful enumerations to facilitate the units, systems, and so forth.
All *very* powerful. But this isn't Java. The concepts transfer, somewhat;
it's rusty for me, though getting easier.
Thanks for the feedback and I'm sure we'll be in touch.
On Tue, Jul 26, 2011 at 2:55 PM, Noah Roberts
On 7/26/2011 1:42 PM, Michael Powell wrote:
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.
The claim of zero overhead is only mostly true, but not because it doesn't do runtime unit conversions. It's only mostly true because:
1) There's actually a significant overhead at compile time.
I believe this is a worthy sacrifice but it's something that needs to be considered.
2) It depends on compiler optimizations that don't always happen.
It *should* be zero overhead because the function calls and such should be optimized away such that the machine code is the same as if the type were a double, but I've noticed this doesn't always happen. Of course it obviously does not when debug mode is on.
Boost.Units never claims to be an answer for "userland units".
Good point. 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.
This should be natural. Build the models to work in some fundamental set of unit types that is standardized across the entire architecture. Then use unit conversions between the models and their views.
Right-o.
______________________________**_________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/**mailman/listinfo.cgi/boost-**usershttp://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
Michael Powell -
Noah Roberts