c ++ 11 반환 값 최적화 또는 이동?

c ++ 11 반환 값 최적화 또는 이동? [복제]

---

이 질문에는 이미 답변이 있습니다.

• C ++ 11 rvalue 및 이동 의미 론적 혼란 (반환 진술) 6 답변

언제 사용해야 std::move하고 언제 컴파일러를 최적화 해야하는지 이해하지 못합니다 ... 예 :

using SerialBuffer = vector< unsigned char >;

// let compiler optimize it
SerialBuffer read( size_t size ) const
{
    SerialBuffer buffer( size );
    read( begin( buffer ), end( buffer ) );
    // Return Value Optimization
    return buffer;
}

// explicit move
SerialBuffer read( size_t size ) const
{
    SerialBuffer buffer( size );
    read( begin( buffer ), end( buffer ) );
    return move( buffer );
}

어느 것을 사용해야합니까?

---

첫 번째 방법을 독점적으로 사용하십시오.

Foo f()
{
  Foo result;
  mangle(result);
  return result;
}

이 것 이미 사용 가능한 경우, 이동 생성자의 사용을 허용한다. 실제로, 로컬 변수는 return복사 제거가 허용 될 때 명령문 의 rvalue 참조에 정확하게 바인딩 될 수 있습니다.

두 번째 버전은 복사 제거를 적극적으로 금지합니다. 첫 번째 버전이 보편적으로 좋습니다.

---

모든 반환 값이 이미 moved최적화되었거나 반환 값과 함께 명시 적으로 이동할 필요가 없습니다.

컴파일러는 반환 값을 자동으로 이동하고 (복사 최적화) 이동도 최적화 할 수 있습니다!

n3337 표준 초안 (C ++ 11) 의 섹션 12.8 :

특정 기준이 충족되면 객체의 복사 / 이동 생성자 및 / 또는 소멸자가 부작용이 있더라도 구현시 클래스 객체의 복사 / 이동 구성을 생략 할 수 있습니다. 이러한 경우, 구현에서는 생략 된 복사 / 이동 조작의 소스 및 대상을 동일한 오브젝트를 참조하는 두 가지 다른 방법으로 취급하며, 해당 오브젝트의 파괴는 두 오브젝트가 있었을 때 후기에 발생합니다. 라는 복사 / 이동 작업의 optimization.This 생략없이 파괴 복사 생략 (여러 복사본을 제거하기 위해 결합 될 수있다) 다음과 같은 경우에 허용된다 :

[...]

예 :

class Thing {
public:
Thing();
   ~Thing();
   Thing(const Thing&);
};

Thing f() {
   Thing t;
   return t;
}

Thing t2 = f();

Here the criteria for elision can be combined to eliminate two calls to the copy constructor of class Thing: the copying of the local automatic object t into the temporary object for the return value of function f() and the copying of that temporary object into object t2. Effectively, the construction of the local object t can be viewed as directly initializing the global object t2, and that object’s destruction will occur at program exit. Adding a move constructor to Thing has the same effect, but it is the move construction from the temporary object to t2 that is elided. — end example ]

When the criteria for elision of a copy operation are met or would be met save for the fact that the source object is a function parameter, and the object to be copied is designated by an lvalue, overload resolution to select the constructor for the copy is first performed as if the object were designated by an rvalue. If overload resolution fails, or if the type of the first parameter of the selected constructor is not an rvalue reference to the object’s type (possibly cv-qualified), overload resolution is performed again, considering the object as an lvalue.

---

It's quite simple.

return buffer;

If you do this, then either NRVO will happen or it won't. If it doesn't happen then buffer will be moved from.

return std::move( buffer );

If you do this, then NVRO will not happen, and buffer will be moved from.

So there is nothing to gain by using std::move here, and much to lose.

There is one exception to this rule:

Buffer read(Buffer&& buffer) {
    //...
    return std::move( buffer );
}

If buffer is an rvalue reference, then you should use std::move. This is because references are not eligible for NRVO, so without std::move it would result in a copy from an lvalue.

This is just an instance of the rule "always move rvalue references and forward universal references", which takes precedence over the rule "never move a return value".

---

If you're returning a local variable, don't use move(). This will allow the compiler to use NRVO, and failing that, the compiler will still be allowed to perform a move (local variables become R-values within a return statement). Using move() in that context would simply inhibit NRVO and force the compiler to use a move (or a copy if move is unavailable). If you're returning something other than a local variable, NRVO isn't an option anyway and you should use move() if (and only if) you intend to pilfer the object.

참고URL : https://stackoverflow.com/questions/17473753/c11-return-value-optimization-or-move