可以从临时创建复合对象吗？ [英] Can creation of composite objects from temporaries be optimised away?

问题描述

我已经提出了几个问题，这些问题已经涉及到这个问题，但我已经得到不同的回应，所以我最好直接问它。

让我们说我们有下面的代码：

  //傻瓜的A和B的例子，不要这么认真，
 //只是记住它们很大，而不是动态分配。 
 struct A {int x [1000]; A（）{for（int i = 0; i！= 1000; ++ i）{x [i] = i * 2; }}; 
 struct B {int y [1000]; B（）{for（int i = 0; i！= 1000; ++ i）{y [i] = i * 3; }}; 
 
 struct C 
 {
 A a; 
 B b; 
}; 
 
 create_a（）{return A（）; } 
 B create_b（）{return B（）; } 
 
 C create_c（A&& a，B&& b）
 {
 C c; 
 c.a = std :: move（a）; 
 c.b = std :: move（b）; 
 return C; 
}; 
 
 int main（）
 {
 C x = create_c（create_a（），create_b（））; 
} 
  

现在理想情况下 create_c（A&& ;&）应为无操作。代替调用约定是为了创建A和B，并且引用它们在堆栈上传递，A和B应该创建并通过值传递返回值 c 。使用NRVO，这意味着创建并直接传递到 x ，没有进一步的工作为 create_c 。

这样可以避免创建A和B的副本。

/从编译器/鼓励/强制这种行为，或者做优化编译器一般这样做吗？这将只有当编译器内联函数，或将工作在编译单元。工作。

（我认为这可以工作在编译单元...） / p>

如果 create_a（）和 create_b（）隐藏参数放置返回值的位置，它们可以将结果直接放入 x ，然后通过引用传递 create_c（）它不需要什么，立即返回。

解决方案

有不同的优化代码的方法，但是右值引用不是一个。问题是， A 或 B 都不会被移动 无法窃取该物件的内容。 考虑下面的例子：

  template< typename T> 
 class simple_vector {
 typedef T element_type; 
 typedef element_type * pointer_type; 
 pointer_type first，last，end_storage; 
 public：
 simple_vector（）：first（），last（），end_storage（）{} 
 simple_vector（simple_vector const& rhs）//生产准备就绪， ！ 
：first（new element_type [rhs.last  -  rhs.first]），
 last（first + rhs.last-rhs.first），
 end_storage（last）
 { 
 std :: copy（rhs.first，rhs.last，first）; 
} 
 simple_vector（simple_vector&& rhs）//我们可以移动！ 
：first（rhs.first），last（rhs.last），end_storage（rhs.end_storage）
 {
 rhs.first = rhs.last = rhs.end_storage = 0; 
} 
〜simple_vector（）{
 delete [] rhs.first; 
} 
 //操作的剩余
}; 
 

在这个例子中，由于资源通过指针保存，所以有一种简单的方法：移动对象（即窃取旧对象的内容到新对象中，并将旧对象保持在可销毁但无用的状态），只需复制指针并将旧对象重置为null即可析构函数不会释放内存。

A 和 code>是实际的内存通过数组保存在 对象中，并且该数组不能被移动到新的 C 对象。





当然，由于在代码中使用堆栈分配的对象，旧的由编译器使用，并且当你这样做： C c = {create_a（），create_b（）}; 编译器可以执行该优化（基本上设置属性<$ c在 create_a 中返回的对象的地址上的$ c> ca ，而当编译 create_a ，直接在同一个地址上创建返回的临时变量，因此 ca ，从 create_a 临时构造在 create_a （隐式到构造函数中）是相同的对象，避免两份。使用 c.b 也可以做到这一点，从而避免复制成本。如果编译器内联你的代码，它将删除 create_c 并替换为类似于： C c = {create_a（），create_b ）}; ，因此可以潜在优化所有副本。

另一方面，请注意，此优化不能完全使用动态分配的 C 对象，如 C * p = new C; p> a = create_a（）; ，因为在堆栈中目的地不是，编译器只能优化 create_a 和它的返回值，但它不能使它与 p> a 一致，因此需要完成一个副本。这是 rvalue-references over（N）RVO的优点，但如前所述，您不能在您的代码示例中直接有效地使用 rvalue-references 。

I've asked a few questions which have touched around this issue, but I've been getting differing responses, so I thought best to ask it directly.

Lets say we have the following code:

// Silly examples of A and B, don't take so seriously, 
// just keep in mind they're big and not dynamically allocated.
struct A { int x[1000]; A() { for (int i = 0; i != 1000; ++i) { x[i] = i * 2; } };
struct B { int y[1000]; B() { for (int i = 0; i != 1000; ++i) { y[i] = i * 3; } };

struct C
{
  A a;
  B b;
};

A create_a() { return A(); }
B create_b() { return B(); }

C create_c(A&& a, B&& b)
{
  C c;
  c.a = std::move(a);
  c.b = std::move(b);
  return C; 
};

int main()
{
  C x = create_c(create_a(), create_b());
}

Now ideally create_c(A&&, B&&) should be a no-op. Instead of the calling convention being for A and B to be created and references to them passed on stack, A and B should created and passed in by value in the place of the return value, c. With NRVO, this will mean creating and passing them directly into x, with no further work for the function create_c to do.

This would avoid the need to create copies of A and B.

Is there any way to allow/encourage/force this behavior from a compiler, or do optimizing compilers generally do this anyway? And will this only work when the compiler inline the functions, or will it work across compilation units.

(How I think this could work across compilation units...)

If create_a() and create_b() took a hidden parameter of where to place the return value, they could place the results into x directly, which is then passed by reference to create_c() which needs to do nothing and immediately returns.

解决方案

There are different ways of optimizing the code that you have, but rvalue references are not one. The problem is that neither A nor B can be moved at no cost, since you cannot steal the contents of the object. Consider the following example:

template <typename T>
class simple_vector {
   typedef T element_type;
   typedef element_type* pointer_type;
   pointer_type first, last, end_storage;
public:
   simple_vector() : first(), last(), end_storage() {}
   simple_vector( simple_vector const & rhs )              // not production ready, memory can leak from here!
      : first( new element_type[ rhs.last - rhs.first ] ),
        last( first + rhs.last-rhs.first ),
        end_storage( last )
   {
       std::copy( rhs.first, rhs.last, first );
   }
   simple_vector( simple_vector && rhs ) // we can move!
      : first( rhs.first ), last( rhs.last ), end_storage( rhs.end_storage )
   {
      rhs.first = rhs.last = rhs.end_storage = 0;
   }
   ~simple_vector() {
      delete [] rhs.first;
   }
   // rest of operations
};

In this example, as the resources are held through pointers, there is a simple way of moving the object (i.e. stealing the contents of the old object into the new one and leaving the old object in a destroyable but useless state. Simply copy the pointers and reset them in the old object to null so that the original object destructor will not free the memory.

The problem with both A and B is that the actual memory is held in the object through an array, and that array cannot be moved to a different memory location for the new C object.

Of course, since you are using stack allocated objects in the code, the old (N)RVO can be used by the compiler, and when you do: C c = { create_a(), create_b() }; the compiler can perform that optimization (basically set the attribute c.a on the address of the returned object from create_a, while when compiling create_a, create the returned temporary directly over that same address, so effectively, c.a, the returned object from create_a and the temporary constructed inside create_a (implicit this to the constructor) are the same object, avoiding two copies. The same can be done with c.b, avoiding the copying cost. If the compiler does inline your code, it will remove create_c and replace it with a construct similar to: C c = {create_a(), create_b()}; so it can potentially optimize all copies away.

Note on the other hand, that this optimization cannot be completely used in the case of a C object allocated dynamically as in C* p = new C; p->a = create_a();, since the destination is not in the stack, the compiler can only optimize the temporary inside create_a and its return value, but it cannot make that coincide with p->a, so a copy will need to be done. This is the advantage of rvalue-references over (N)RVO, but as mentioned before you cannot do use effectively rvalue-references in your code example directly.

这篇关于可以从临时创建复合对象吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！