Re: [Boost-users] [units]

Subject: Re: [Boost-users] [units]
From: Thomas Taylor (thomas.taylor_at_[hidden])
Date: 2011-08-30 10:01:29

Michael Powell wrote:

> On Tue, Aug 30, 2011 at 6:29 AM, Michael Powell
> <mwpowellnm_at_[hidden]>wrote:
> 
>>
>>
>> On Tue, Aug 30, 2011 at 2:04 AM, Thomas Taylor
>> <thomas.taylor_at_[hidden]
>> > wrote:
>>
>>> Could you please review the following patch for inclusion in
>>> boost::units?
>>>
>>> *WHY*: Obviously this only defines a conversion for boost::units::one to
>>> a numerical 1. When trying to convert at runtime (aiming for a
>>> runtime/dynamic
>>> unit instead of the compiletime/static unit provided) I use the
>>> following function:
>>>
>>> template <typename U1, typename U2>
>>> double unit_dispatch2t(U1 const& u1, U2 const& u2) {
>>>    return bu::conversion_factor(u1,u2);
>>> }
>>>
>>> where U1 and U2 are boost::unit::unit derivatives.
>>>
>>> Without a conversion operator the compiler chickens out by claiming to
>>> not be able to convert boost::units::one to (in my case) double. The
>>> added conversion operator allows successfull compilation, thus allowing
>>> actual runtime units (my application needs to handle calculations where
>>> some units
>>> are known at compiletime and some only at runtime (e.g. the user wants
>>> the calculation to be done in meters or millimeters)).
>>>
>>
>> Oh, the runtime question. Here's how we've decided to approach this.
>>
>> I'll just tell you, I find the compile-time safety attractive. For
>> runtime, we've decided that calculations should be done in a base unit.
>>
>> For anything else, we *convert to* a view unit, for display or report or
>> what not.
>>
> 
> I should clarify too, in this type of use case, we still know what the
> compile-time units should necessarily be. The runtime I like to think of
> is the user selecting: system, and possibly also unit. Which is what your
> aiming for here?

No, I don't think so. If I read your answer correctly your appoach advocates 
to decide on a specific unit for calculation (which is specified at compile 
time). IO will be converted to/from a unit of the users choosing (at 
runtime).

However I explicitely want to decide at runtime which unit the *calculation* 
will be in and I believe I have a working approach (which would require the 
aforementioned patch as it is impossible to define such a conversion 
anywhere else unless I am mistaken).

Certainly my use case will not fit every problem (maybe even just my own), 
but is there a specific reason NOT to include a boost::unit::one to 
integer/POD conversion, i. e. will it break existing code?

If the proposed change is deemed unacceptable, do you think a modification 
that allows to choose either the default boost::unit::one or a costum home 
brew one will make it into the repository?

Thanks for pointing out the current philosophy on runtime unit support.

Cheers,
Thomas

> 
> Use case: calculations on volume, pressure, etc, done in base SI units.
> View
>> may be in SI, US (English), or what have you.
>>
>>  HTH,
>>> Thomas
>>>
>>>
>>>
>>> --- one.hpp     2011-08-30 09:50:13.000000000 +0200
>>> +++ one2.hpp    2011-08-30 09:50:07.000000000 +0200
>>> @@ -19,3 +19,3 @@
>>>
>>> -struct one { one() {} };
>>> +struct one { one() {} operator int() { return 1; } };
>>>
>>>
>>> _______________________________________________
>>> Boost-users mailing list
>>> Boost-users_at_[hidden]
>>> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>>>
>>
>>