Re: [Boost-users] [units]

Michael Powell wrote:

On Tue, Aug 30, 2011 at 6:29 AM, Michael Powell wrote:

...

On Tue, Aug 30, 2011 at 2:04 AM, Thomas Taylor

...

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 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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users