Boost logo

Boost :

Subject: Re: [boost] [units] - learning to use
From: Matthias Schabel (boost_at_[hidden])
Date: 2011-11-28 00:20:20

>> OK. So I have to use .value().
>> The question here: should I expect here some scaling problems? For example:
>> a = 1nm
>> b = 1km
>> c = (a/b).value()
>> Will c become 1.0, with units scaling being lost, due to directly
>> taking .value() without taking care of unit scaling. Or would it be
>> correctly 1e-12 ?
> It will be 1.0. in this case. To be safe
> use static_cast, or boost::implicit_cast.

This is an object lesson in why using the value() method should be a last resort. I do think that we
should try to get sensible behavior, without too many contortions, with the various built in types.

A slight tangent : I'm thinking that we are going to need to revisit scaled units now that std::ratio exists
and takes over the prefixes. Steven, any sense of how difficult it will be to replace our static_rational
with std::ratio? I took a quick look and it doesn't look like a disaster - hoping there are no subtle
gotchas... I guess we will have to overload operator*(std::ratio<N,D>,unit<S>)? This problem arose when
I tried to compile Janek's code with Xcode 4.2 using C++11 mode... <ratio> must be pulled in by default,
though not sure why.

>> In my problem I am calculating exponent then multiply and
>> divide by length. In fact the exponent argument is supposed to be
>> dimensionless also! And as you see I multiply wavenumber by length.
>> I assume the conversions to ::one are good here :)
>> Another question:
>> complex<double> i(0,1);
>> quantity<wavenumber,complex<double> > k=2*pi/lambda;
>> // [....]
>> a += (dd*exp(i*k*r)/r).value();
>> do I really need to define wavenumber k as being complex? After all
>> it's multiplied by 'i' so it should get converted automatically?
> It's the same problem as above with int/double.
>>>> quantity<length> wavelength ( 632.8 *nano*meters);
>>>> quantity<length> wavelength = 632.8 *nano*meters;
>>> This isn't assignment. It's copy construction and
>>> requires an implicit conversion which is forbidden.
>> why it is forbidden?
>> I think it would be more convenient to allow this.
> In general, any conversion that causes the
> underlying value to change is explicit.
> In Christ,
> Steven Watanabe
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at