AMDG Simonson, Lucanus J wrote:
All code compiles and generally passes my unit tests in MSVC8.
It turns out that making the enable_if a default argument impacts regular overloading of functions and that adding a unique type into the enable_if logic to make all instantiations unique was a more reliable way to work around the compiler bugs.
I ran into a problem where boost::long_long_type isn't able to convert correctly to double. In the code below the return type of square_euclidean_distance is long long because I need twice as many bits to store the result of a multiply.
euclidean_distance(const rectangle_type& lvalue, const rectangle_type_2& rvalue) { double val = (double)square_euclidean_distance(lvalue, rvalue); return sqrt(val); }
It fails a runtime check stating that val is left unitialized and in the debugger I can see that the value is indeed uninitialized. My question for any experts is why is this code failing?
I looking into the dissasembly and it looks like long long is 64 bit emulated in software in my 32 bit windows environment compiling with MSVC8. I couldn't find anywhere the conversion from long long to double, and it seems that it is just silently failing to provide it, leaving me with uninitialized data.
In MSVC8 BOOST_HAS_LONG_LONG is defined and I'm using the boost::long_long_type the way it was suggested that I should.
I don't think this is related to the use of long long since the following program works okay. #include <iostream> int main() { long long x = 1.0; double d = x; std::cout << x << std::endl; } I seem to recall seeing a problem like this before when overload resolution doesn't quite work. Perhaps you remember this thread? http://lists.boost.org/Archives/boost/2009/01/146859.php I think I had similar runtime weirdness in some of the tests that I ran. In Christ, Steven Watanabe