为什么`abs()`的实现方式有所不同?

Phi*_*ill 60 c++ gcc compilation clang

在过去的几周中,我的代码中出现了一个令人沮丧的错误。我的代码可以完全按照我的计算机上的预期运行,但是一旦将其移植到HPC服务器上,它就会产生奇怪的结果。

我将其归结为:在我的计算机(iMac)上,该函数abs()使用浮点数,但在服务器上将其abs()截断为整数。

例:

服务器

abs(-1.1341234) = 1
Run Code Online (Sandbox Code Playgroud)

我的Mac

abs(-1.1341234) = 1.1341234
Run Code Online (Sandbox Code Playgroud)

现在我知道我可以使用解决此fabs()问题,这不是问题。我看了gcc两台机器上的版本,这是输出:

服务器

g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/apps/software/GCCcore/5.4.0/libexec/gcc/x86_64-unknown-linux-gnu/5.4.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++,fortran --enable-lto --enable-checking=release --disable-multilib --enable-shared=yes --enable-static=yes --enable-threads=posix --enable-gold=default --enable-plugins --enable-ld --with-plugin-ld=ld.gold --prefix=/apps/software/GCCcore/5.4.0 --with-local-prefix=/apps/software/GCCcore/5.4.0 --enable-bootstrap --with-isl=/dev/shm/GCCcore/5.4.0/dummy-/gcc-5.4.0/stage2_stuff
Thread model: posix
gcc version 5.4.0 (GCC) 
Run Code Online (Sandbox Code Playgroud)

我的Mac

g++ -v
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
Apple LLVM version 10.0.1 (clang-1001.0.46.3)
Target: x86_64-apple-darwin18.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
Run Code Online (Sandbox Code Playgroud)

所以我的问题是,为什么abs()在gcc和clang之间会产生不同的结果?从字面上看,这个问题使我花了3个星期的时间,所以可以想像我刚才有点咸...

Bat*_*eba 89

必须使用std::abs,它对原始类型有重载。

一种情况是使用C ++版本,另一种情况是使用旧的C版本(将其参数转换为整数类型)。

要避免的事情:(1)using namespace std;这就是为什么)和(2)没有适当的#includes来引入所需的功能。不要依赖C ++标准库实现来隐式包含文件。

如果适当地设置警告级别,某些编译器会警告您“有损”转换。

  • @BenjaminBihler:这使罐头大步向前-例如,晶圆厂打破了“长双”。 (34认同)
  • *所有*编译器应警告您将浮点数转换为整数,或将整数转换为浮点数。如果您的编译器不这样做,并且您无法相应地调整其警告级别,请立即将其丢弃,以使自己成为一个更好的编译器。 (8认同)
  • @BenjaminBihler如果使用的是c ++,通常没有充分的理由不使用c ++版本的函数。将C保留为C,将C ++保留为C ++。 (6认同)
  • 更正:使用 `fabs` 而不是 `abs` 或 `std::abs` 这是一个模板函数。 (2认同)
  • @ Rakete1111:完全笼统地说是有损的。例如64位的“ int”和IEEE754的“ double”。 (2认同)