c++ - valarray 就地操作给出不同的结果作为临时分配

Question

以下程序:

#include<iostream>
#include<valarray>

using namespace std;

int main() {
  int init[] = {1, 1};

  // Example 1
  valarray<int> a(init, 2);
  // In-place assignment
  a[slice(0, 2, 1)] = a[slice(0, 2, 1)] + valarray<int>(a[slice(0, 2, 1)]) * a[0];

  for (int k = 0; k < 2; ++ k) {
    cout << a[k] << ' ';  // Outputs 2 3
  }
  cout << endl;

  // Example 2
  valarray<int> b(init, 2);
  // Temporary assignment
  valarray<int> r = b[slice(0, 2, 1)] + valarray<int>(b[slice(0, 2, 1)]) * b[0];
  b[slice(0, 2, 1)] = r;

  for (int k = 0; k < 2; ++ k) {
    cout << b[k] << ' '; // Outputs 2 2
  }
  cout << endl;
  return 0;
}

输出:

2 3
2 2

正确答案是2 2 ( <1 1> + <1 1> * 1 = <2 2> 。为什么内联版本输出不同的东西？

以防万一，我是这样编译的:

g++ myprogram.cpp -o myprogram

g++ -v的输出是:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.5' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5) 

Answer 1

首先，a[slice(0, 2, 1)]类型为 slice_array<T> ，并且没有重载 operator+服用slice_array<T>对象或引用作为参数。

注意可能的工作重载 operator+(const valarray<T>&, const valarray<T>&)是一个函数模板，虽然 slice_array<T>可以隐式转换为 valarray<T> , 模板参数 T不能从 slice_array<T> 推导出来争论。

所以严格来说，你的代码会导致编译错误。事实上，Clang does .

---

其次，你应该知道valarray的操作有一些优化技巧。 .一种众所周知的技术是 expression templates ，这会导致您意想不到的结果。为了了解它是如何工作的，让我们考虑一个重现此问题的更简单的示例:

valarray<int> a{1, 1};
a = a + a[0];
// now a is {2, 3} while {2, 2} is expected

表达式模板的关键思想是将表达式的计算推迟到真正需要它的值时，这样就避免了额外的临时。

在上面的例子中，优化器可能会选择优化 a + a[0] 的结果。成为代理对象而不是 valarray<int>暂时的。代理对象只存储“将a[0]添加到a”的 Action (不是结果值)。

当代理对象被分配给a时，实际评估发生。从存储的操作中，优化器将选择分配 a[i] + a[0]至 a[i]对于每个 i .现在，此作业中的不同评估顺序将导致不同的结果。例如，如果编译器分配 a[0] + a[0]至 a[0] , 然后分配 a[1] + a[0] (此处a[0]改为2)改为a[1] ，意想不到的结果{2, 3}产生了。

标准允许存在这样的代理对象，但似乎没有明确规定代理对象应该如何工作。我个人认为这是一个编译器错误，因为简单地评估 a[0]并在分配之前存储它的值将解决这个问题，而性能损失很小。