AMDG On 05/31/2017 01:09 PM, Pavel Kretov via Boost wrote:
<snip>
The code looks okay to me, but when I try to compile it, I get a scary error message:
main.cpp:20:19: error: no match for ‘operator/’ (operand types are ‘float’ and ‘<THE_TERROR_THAT_FLAPS_IN_THE_NIGHT>’)
dt = 0.5f / (v * bu::sqrt(1.0f/(dx*dx) + 1.0f/(dy*dy))); <snip> In the above expression [{}, {}, ...] is a pseudo-code for static head-tail list of boost::units::dim<Unit, Rat> pairs. Note the 'double' type materialized from barely nowhere: the code explicitly defines everything as 'float', it's the 'bu::sqrt' to blame for it to appear. Note that replacing 'bu::sqrt' with 'bu::pow<1, 2>()' does not help.
That's because bu::sqrt uses the same type deduction at bu::pow. The correct result type should use decltype(sqrt(x.value()))
As I didn't feel happy with the above error message, I mutated the code a bit and made it to work with:
bu::quantity<si::time, float> dt; dt = dimless(0.5f) / (v * bu::sqrt(1.0f/(dx*dx) + 1.0f/(dy*dy)));
I had to both (a) add 'dimless',
The reason for this is that the generic operator/ which we used originally was causing ambiguities for some user-defined value types.
and (b) separate variable declaration and definition. Doing only (a) didn't help.
You're using copy-initialization which requires an implicit conversion. Try: bu::quanity<...> dt{...};
The questions: 1. Is it possible to work around the problem without custom 'sqrt'? 2. Is the described behavior intentional, -or- Is there an error in Boost.Units' implementation of 'sqrt'?
Both sqrt and pow look wrong.
3. If the 'boost::unit::sqrt' is fine, is there something wrong with my implementation?
In Christ, Steven Watanabe