我有在不同平台上运行的代码,似乎得到不同的结果.我正在寻找一个正确的解释.
Windows:
double dbl = -123.45;
int d_cast = (unsigned int)dbl;
// d_cast == -123
WinCE(ARM):
double dbl = -123.45;
int d_cast = (unsigned int)dbl;
// d_cast == 0
编辑:
谢谢你指出了正确的方向.
修复变通方法
double dbl = -123.45;
int d_cast = (unsigned)(int)dbl;
// d_cast == -123
// works on both.
在我的平台上打印9223372036854775808.
double x = 1e19;
std::cout << static_cast<unsigned __int64>(x) << '\n';
我尝试了Boost.NumericConversion,但得到了相同的结果.
将x分成2个相等的部分,然后将转换后的一半加在一起得到正确的结果.但我需要在模板代码中使用通用解决方案.
先感谢您.
编辑:此问题出现在Visual Studio 2008上,但不是MinGW.将4.0e9转换为unsigned long工作正常.
当 int64_t 被强制转换为 double 并且没有完全匹配时，据我所知，我得到了一种等效于 double 的尽力而为最近的值。例如， int64_t 中的 9223372036854775000 似乎在 double 中以 9223372036854774784.0 结尾：
#include <stdio.h>
int main(int argc, const char **argv) {
printf("Corresponding double: %f\n", (double)9223372036854775000LL);
// Outputs: 9223372036854774784.000000
return 0;
}
在我看来，似乎 int64_t 转换为 double 总是以干净的非小数结束，即使在 double 精度非常低的较高数字范围内也是如此。但是，我只是从随机尝试中观察到这一点。对于 int64_t 转换为 double 的任何值，是否保证会发生这种情况？
如果我将这个非小数双精度转换回 int64_t，我是否总是能得到精确对应的 64 位 int 并且 .0 被切掉？（假设它在转换回来期间没有溢出。）像这里：
#include <inttypes.h>
#include <stdio.h>
int main(int argc, const char **argv) {
printf("Corresponding double: %f\n", (double)9223372036854775000LL);
// Outputs: 9223372036854774784.000000
printf("Corresponding int to corresponding double: %" PRId64 …我正在尝试将 a 转换double为 an unsigned int。保证double>= 0。不过，不同的编译器会产生不同的结果。这是示例：
#include <stdio.h>
int main(int argc, char *argv[])
{
double x = 5140528219;
unsigned int y = (unsigned int) x;
printf("%x\n", y);
return 0;
}
Visual C 似乎只是简单地删除所有 >= 32 的位，因为它将 转换double为 0x32663c5b。然而，Gcc 似乎将整个数字剪裁为，UINT_MAX因为结果是 0xffffffff。
现在有一些线程double在转换为时提到了 Visual C 中的编译器错误unsigned int，所以我想知道我在这里看到的行为是否也是 Visual C 中的错误，或者doubleto的转换unsigned int是否只是依赖于实现，因此不明确的？
有任何想法吗？
我的 Visual C 版本相当旧（x64 为 15.00.30729.01）。