Subject: Re: [boost] [units] - learning to use
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2011-11-25 09:35:21
On 11/25/2011 05:11 AM, Janek Kozicki wrote:
>>> it seems strange that I need to take .value() here. The result is
>>> dimensionless, why can't it directly convert to complex<double> ?
>>> There is a risk that .value() would be expressed in millimeters or
>>> angstroms or whatever (maybe depending on dd), and then .value()
>>> would return a wrongly scaled number?
>> This is an idiosyncrasy of overload resolution.
>> std::complex::operator+= is a template, so an
>> implicit conversion doesn't work. The template
>> argument can't be deduced.
> 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.
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk