Re: [Boost-users] [units] unit conversion on construction in relation to argument passing

Subject: Re: [Boost-users] [units] unit conversion on construction in relation to argument passing
From: alfC (alfredo.correa_at_[hidden])
Date: 2011-03-25 13:40:00

On Mar 25, 9:46 am, Matthias Schabel <bo..._at_[hidden]> wrote:
> >> nice! But for some reason I believe this would work for argument
> >> functions
>
> >> double f(quantity<si::length>  v){ return 1.;}
> >> ...
> >>  quantity<cgs::lengh>  A = 4.*cgs::centimeter
> >>  f(A);   // doesn't work! not matching function
>
> >> why is this? isn't the argument of the call a sort of construction
> >> argument for the function argument, or is more like a plain
> >> assignment. Is there a way to force the automatic conversion of the
> >> function call.
>
> >> Or I am forced to use this other long call?
>
> >>  f(quantity<si::length>(A));
>
> > Yes.  The constructor is explicit.
>
thanks for the clarification
>
> Or you can write it as a template function that takes any argument that is a quantity of length :
> [...code...]

Thank you for the suggestion, the problem is that a nice looking
function such as

void f(
 quantity<volume> v,
 quantity<temperature> t,
 quantity<length> l
){
 ... use v, l, t  in a given controlled set of units
}

transfroms into this mess,

template<
  class VolumeUnit,
  class TemperatureUnit,
  class LengthUnit
> void f(
 quantity<VolumeUnit> v_,
 quantity<TemperatureUnit> t_,
 quantity<LengthUnit> l_
){
 quantity<volume> v(v);
 quantity<temperature> t(t_);
 quantity<length> l(l_);
 ... use v, l, t  in a given controlled set of unit
}

just to obtain the same effect. and that without even static asserting
that XXXUnit is_unit.

For sometime I agreed that implicit construction was a bad idea
because of uncontrolled unit conversion but in the light of the
applications (i.e. real life code) I now think that it can be a good
idea instead. The uncontrolled conversion can still be tamed by the
(un)definition of conversion factors.