Thanks a lot for your help,
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.
I might have got something wrong, and missed probably something in the manual... So what is a better way of writing this line in the code? a += (dd*exp(i*k*r)/r).value(); The result of dd*exp(i*k*r)/r is dimensionless, but direct assignment (copy construction) isn't working here. And I would really admire if the code could look in a sane way, like this: a += dd*exp(i*k*r)/r; This would look, like I'm not really worrying about using boost::units, just benefit from all the unit checking, and no extra code to type. (and change k to use double, not complex ;) Also I am suspicious that currently my code has a bug here, exactly where the .value() is taken. Because `dd` and `r` are units of different scale.
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.
Perhaps we should flesh out the toy complex implementation we wrote and incorporate it in the units library? It is a fairly common thing to use together with units and, as I understand it, the standard only defines complex for a subset of built in types...
that would be great. Because there is no physical reason why wavenumber k would need to be complex. It seems like allowing to perform a conversion from double to complex is reasonable. Only opposite conversion has reasons to fail. Just like converting double to int has reasons to fail. But converting int to double should work flawlessly.
quantity<length> wavelength ( 632.8 *nano*meters); quantity<length> wavelength = 632.8 *nano*meters; Although, in Janek's defense, this seems overly restrictive. Can we allow copy construction between scaled units and the corresponding unscaled unit without introducing undesirable side effects?
I would really appreciate that :) It would simplify code. Also because I cannot put 632.8*nano*meters directly as arguments to function call. btw, how usually do you define those scaled units to be a little more convenient to use? I mean, just type: 632.8*nm Is there some header to include, to benefit from all standard SI system prefixes? It would be great, it's a standard after all :) And those short names are carefully designed to not have any unit name clashes. Of course while writing C++ code we might end up with variables names & units names clashing, like using single letter 'm' for 'meter', but this is why we have an si:: namespace after all. And if my code grows a little bigger I will definitely switch to: 632.8*si::nm If you will have some changes in library that will need testing I will gladly try it. If you tell me how to define si::km, si::m, si::kN, si::GJ I can generate for you a header file with all possible units. Though 'micro' is not in latin alphabet. So micro meter is not possible, aww.. best regards -- Janek Kozicki http://janek.kozicki.pl/ |