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 17:18:03

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 <roberts.noah_at_[hidden]>wrote:

> 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_at_[hidden]
> http://lists.boost.org/**mailman/listinfo.cgi/boost-**users
>

>