'2011/09'에 해당되는 글 4건
- 2011.09.26 쳐진 달팽이 - 말하는대로 자세한 코드악보
- 2011.09.19 아스토리아 공원
- 2011.09.19 아스토리아
- 2011.09.14 우측 값 참조 해설(R-Value References Explained) 1
자료2011. 9. 26. 07:48
말하는대로.pdf사진2011. 9. 19. 08:33
사진2011. 9. 19. 04:55
자료2011. 9. 14. 04:56
역자주:
Thomas Becker의 R-value References Explained를 번역한 글입니다. 개인적으로 새로운 C++ 표준에 큰 기대를 하고 있고, 새로운 문법뿐만 아니라 그러한 설계를 하게 된 배경까지 이해하고 싶었는데 좋은 글을 찾게 되었습니다. 내용을 더 자세히 이해하고 영어에 익숙하지 않은 분들에게도 전하기 위해 번역을 해 보았는데 부족한 점이 많네요. 매끄럽지 못한 부분은 지적해 주시면 감사드리겠습니다.
Thomas Becker의 R-value References Explained를 번역한 글입니다. 개인적으로 새로운 C++ 표준에 큰 기대를 하고 있고, 새로운 문법뿐만 아니라 그러한 설계를 하게 된 배경까지 이해하고 싶었는데 좋은 글을 찾게 되었습니다. 내용을 더 자세히 이해하고 영어에 익숙하지 않은 분들에게도 전하기 위해 번역을 해 보았는데 부족한 점이 많네요. 매끄럽지 못한 부분은 지적해 주시면 감사드리겠습니다.
아직 한국어로 정착되지 않은 용어들은 제 임의로 번역했음을 양해부탁드립니다. 이들을 포함해서 사용한 용어의 영문/한글 표현은 다음과 같습니다.
r-value reference : r-value 레퍼런스 (우측값 참조)
move semantics : 이동 시맨틱
perfect forwarding : 완벽한 전달
inplace sort : 제자리 정렬
copy constructor : 복사 생성자
move constructor : 이동 생성자
copy assignment constructor : 복사 대입 연산자
move assignment constructor : 이동 대입 연산자
reference collapsing rules : 레퍼런스 합침 규칙
template argument deduction : 템플릿 인자 유추
이 글은 독자가 기존 C++ 문법(템플릿, 복사 생성자와 연산자 오버로드, 레퍼런스 등)에 익숙하다고 가정하고 시작합니다.
우측 값 참조(R-value reference)는 C++의 새로운 표준인 C++11에 추가된 기능입니다. R-value 레퍼런스는 조금 복잡한 개념이라 C++ 커뮤니티에서 아주 유명한 사람들조차도 이런 말을 하는 것을 듣곤 합니다.
"R-value 레퍼런스를 이해했다고 생각할 때마다 다시 개념이 도망가버려요"
"아 그 r-value 레퍼런스 ... 그거 때문에 머리를 싸매느라 고생 좀 하고 있죠"
"R-value 레퍼런스를 가르쳐야 한다니 겁부터 나네요"
R-value 레퍼런스가 구린 점은 처음 보면 이것의 목적이 뭔지, 이게 무슨 문제를 해결하는지 도통 알 수 없다는 것이죠. 그래서 저는 r-value 레퍼런스가 무엇인지부터 설명하지 않겠습니다. 우선 해결할 필요가 있는 문제를 제시한 다음에 r-value 레퍼런스를 이용하여 해결하는 것을 보여주는 게 더 좋은 방법일 것 같습니다. 그러면 r-value 레퍼런스가 좀더 이치에 맞고 자연스러워 보일 것입니다.
Rvalue 레퍼런스로 아래의 두 가지 문제를 해결할 수 있습니다.
1. 이동 시맨틱(move semantics)의 구현
2. 완전한 전달(perfect forwarding)
이 개념들에 대해서 익숙하지 않더라도 걱정하지 마세요. 이제부터 두 가지 모두에 대해 자세히 설명할 것입니다. 하지만 시작하기 전에 C++에서 좌측 값(l-value)과 우측 값(r-value)이 무엇인지부터 상기해 봅시다. 이들의 엄밀한 정의를 내리기는 어렵지만 현재 목적에는 아래의 예시 정도면 충분할 것 같습니다.
l-value와 r-value에 대해 C언어의 초창기에 내려진 정의는 다음과 같습니다.
L-value는 대입문에서 등호(=)의 왼쪽이나 오른쪽에 올 수 있는 표현이며 r-value는 등호의 오른쪽에만 올 수 있는 표현이다
예:
int a = 42;
int b = 43;
// a 와 b 는 모두 l-value이다.
a = b; // 가능
b = a; // 가능
a = a * b; // 가능
// a * b 는 r-value이다.
int c = a * b; // r-value가 등호의 오른쪽에 있으므로 가능
a * b = 42; // r-value가 등호의 왼쪽에 있으므로 에러
이 개념은 C++에도 적용될 수 있는 직관적인 정의입니다. 하지만 C++에서 사용할 수 있는 사용자 정의 타입들 때문에 문제가 약간 복잡해져서 위의 정의가 잘못되게 될 수 있습니다. 엄밀한 정의는 논외로 하고, r-value 레퍼런스를 이해하는 데에 도움이 될 수 있는 간단한 정의를 소개하겠습니다.
"l-value는 메모리상의 특정한 위치를 가리키고 & 연산자를 이용해서 그 메모리의 주소를 가져올 수 있는 표현이다. r-value는 l-value가 아닌 표현이다"
예:
// l-value:
//
int i = 42;
i = 43; // i가 l-value이므로 가능
int* p = &i; // i가 l-value이므로 가능
int& foo();
foo() = 42; // foo()가 l-value이므로 가능
int* p1 = &foo(); // foo()가 l-value이므로 가능
// r-value
//
int foobar();
int j = 0;
j = foobar(); // foobar()가 r-value이므로 가능
int* p2 = &foobar(); // r-value의 주소를 얻을 수 없으므로 에러
j = 42; // 42는 r-value이므로 가능
2. 이동 시맨틱(Move Semantics)
X가 어떤 리소스 m_pResource를 갖고 있는 클래스라고 가정합시다. 그 리소스는 생성, 복제, 파괴하는 데에 꽤 많은 노력이 필요한 것을 말하며, 여러 객체들을 배열에 저장하고 있는 std::vector가 좋은 예입니다. 그러면 복사 대입 연산자(copy assignment operator)는 논리적으로 아래와 같이 생겼을 것입니다.
X& X::operator=(X const & rhs)
{
// [...]
// m_pResource가 가리키는 리소스를 파괴한다
// rhs.m_pResourcerk 가리키는 리소스의 복제본을 만들고
// m_pResource가 그 복제본을 가리키도록 한다.
// [...]
}
복사 생성자(copy constructor)도 비슷하게 되겠죠. 이제 X를 아래와 같이 사용했다고 해 봅시다.
X foo();
X x;
// x를 사용함
x = foo();
위의 마지막 줄은 다음과 같은 일을 할 것입니다.
- x가 갖고 있는 리소스를 파괴한다
- foo가 반환한 임시 객체에 있는 리소스를 복제한다
- 임시 객체를 파괴한다. 이 때 그 안에 있는 리소스도 파괴된다.
하지만 당연하게도 훨씬 효율적인 방법이 있습니다. x와 임시 객체의 리소스 포인터를 바꿔치기하고 임시 객체가 파괴될 때 x가 들고 있던 리소스를 파괴하는 것이죠. 다시 말해, 대입문의 우변이 r-value인 경우엔 아래와 같은 일을 하는 것입니다.
// [...]
// m_pResource와 rhs.m_pResource를 바꿔치기(swap)한다
// [...]
이것을 이동 시맨틱(move semantics)라고 합니다. C++0x이전에는 이것을 간단하게 구현할 방법이 없었습니다. 이것을 템플릿 메타프로그래밍을 통해 구현했다는 이야기를 들은적이 있지만 아무도 어떻게 했는지 설명해주지 않더군요. 분명히 엄청나게 복잡했을 겁니다. C++11에선 이 기능을 다음과 같이 오버로드(overload)함으로써 구현할 수 있습니다.
X& X::operator=(<미스터리 타입> rhs)
{
// [...]
// this->m_pResource와 rhs.m_pResource를 바꿔치기한다.
// [...]
}
복사 대입 연산자의 오버로드를 정의하고 있기 때문에, 이 "미스터리 타입"은 레퍼런스여야 합니다. 즉 대입식의 우변이 레퍼런스로 전달되어야 하죠. 게다가 이 미스터리 타입이 다음과 같이 행동하기를 바랍니다: "만약 보통 레퍼런스와 이 미스터리 타입 중에 선택해야 하는 경우라면 r-value는 이 미스터리 타입을 선호하고 l-value는 보통 레퍼런스를 선호한다."
3. 우측 값 참조(R-value References)
X가 어떤 타입이라면 X&&를 r-value 레퍼런스라고 합니다. 명확하게 구분할 필요가 있을 때에는 보통 레퍼런스 X&를 l-value 레퍼런스라고 쓰기도 합니다.
R-value 레퍼런스는 보통 레퍼런스 X&와 아주 비슷하게 행동하지만 몇 가지 차이가 있습니다. 그 중 가장 중요한 차이점은 오버로드된 함수를 찾아갈 때 l-value는 l-value 레퍼런스를 사용한 함수를 선호하고 r-value는 r-value 레퍼런스를 사용한 함수를 선호한다는 점입니다.
void foo(X& x); // l-value 레퍼런스 오버로드
void foo(X&& x); // r-value 레퍼런스 오버로드
X x;
X foobar();
foo(x); // 인자가 l-value이므로 foo(X&)를 호출
foo(foobar()); // 인자가 r-value이므로 foo(X&&)를 호출
즉 문제의 핵심은 이것입니다.
R-value 레퍼런스는 오버로드를 통해 함수들이 "나는 l-value로 호출받고 있는가 아니면 r-value로 호출받고 있는가?"를 컴파일타임에 구분하여 분기할 수 있도록 해 준다.
위에서 본 것과 같이 어떤 함수라도 이렇게 오버로드 할 수 있습니다. 하지만 대부분의 경우 이러한 오버로드는 복사 생성자와 대입 연산자에서 이동 시맨틱을 구현하기 위해 사용합니다.
X& X::operator=(X const & rhs); // 전통적인 구현
X& X::operator=(X&& rhs)
{
// 이동 시맨틱: this와 rhs를 교환한다
return *this;
}
R-value 레퍼런스를 이용하는 복사 생성자도 비슷하게 구현할 수 있습니다.
주의:
C++에서 자주 그렇듯이 언뜻 보기에 완벽한 것 같은 것도 문제가 있을 수 있습니다. 가끔은 this와 rhs를 교환하는 것이 충분하지 않을 때도 있는데, 이 경우에 대해선 4장 "이동 시맨틱 강제하기"에서 살펴볼 것입니다.
참고:
foo(X&)를 구현하고 foo(X&&)를 구현하지 않는다면 foo는 l-value로만 호출할 수 있고 r-value로 호출할 수 없습니다.
foo(X const &)를 구현하고 foo(X&&)를 구현하지 않는다면 이 경우에는 l-value와 r-value에 상관없이 호출할 수 있지만 둘을 구분할 방법이 없습니다.foo(X&&)를 구현해야만 이 둘을 구분할 수 있습니다.
마지막으로 foo(X&&)는 구현하지만 foo(X&)와 foo(X const &)를 둘다 구현하지 않는 경우엔 C++11의 최신 표준에 따르면 r-value로 foo를 호출할 수 있지만 l-value로 호출하려는 경우에는 컴파일 에러가 발생합니다.
4. 이동 시맨틱 강제하기
아시겠지만 C++ 표준의 1차 수정안에는 이런 말이 있습니다. "위원회는 C++ 프로그래머가 자기 발에 총을 쏘는 것을 방지하는 규칙을 제정하지 않습니다". 좀더 진지하게 말하자면, 프로그래머에게 더 많은 권한을 주는 것과 스스로의 부주의함에서부터 보호하는 것 중에서 선택할 수 있다면 C++은 좀더 많은 것을 할 수 있게 하는 쪽을 선택한다는 뜻입니다. 그런 의미에서 C++11는 이동 시맨틱을 r-value 뿐만 아니라 l-value에도 재량껏 사용할 수 있도록 해 줍니다. 표준 라이브러리 함수 swap이 좋은 예입니다. 이번에도 X를 r-value를 위해 복사 생성자와 복사 대입 연산자를 오버로드한 클래스라고 가정합시다.
template<class T>
void swap(T& a, T& b)
{
T tmp(a);
a = b;
b = tmp;
}
X a, b;
swap(a, b);
이 예제에는 r-value가 없습니다. 따라서 swap 함수의 세 줄은 모두 이동 시맨틱으로 구현되지 않았습니다. 하지만 이동 시맨틱을 사용해도 괜찮다는 걸 우린 알고있죠. 즉 복사 생성자나 대입문에서 사용되는 원본이 복사 이후에 아예 사용되지 않거나 복사 대상과 교체되는 경우입니다.
C++11에는 표준 라이브러리 함수 std::move가 있어서 문제를 해결해 줍니다. 이 함수는 인자를 아무 것도 하지 않은 채 r-value로 만들어 줍니다. 따라서 C++11의 표준 라이브러리 함수 swap은 아래와 같은 식으로 구현되어 있습니다.
template<class T>
void swap(T& a, T& b)
{
T tmp(std::move(a));
a = std::move(b);
b = std::move(tmp);
}
X a, b;
swap(a, b);
이제 swap 함수의 세 줄 모두 이동 시맨틱을 사용합니다. 참고로, 이동 시맨틱을 구현하지 않은 타입들(즉 r-value 레퍼런스를 위해 복사 생성자와 대입 연산자를 오버로드하지 않은 타입들)의 경우엔 새 swap 함수가 이전과 똑같이 동작합니다.
std::move 는 아주 간단한 함수이지만 불행하게도 아직 그 구현을 보여줄 수 없습니다. 나중에 이 함수에 대해 다시 얘기하도록 하겠습니다.
std::move를 사용할 수 있는 곳마다 사용하면 위의 swap 함수에서 본 것처럼 다음과 같은 중요한 이득을 볼 수 있습니다.
- 이동 시맨틱을 구현한 타입들에 대해서는 많은 표준 알고리즘과 연산들이 이동 시맨틱을 사용하기 때문에 큰 성능 향상이 있을 것이다. 중요한 예는 제자리 정렬(inplace sorting)이다. 제자리 정렬은 요소들을 바꿔치기 하는 일만 하기 때문에 이동 시맨틱을 지원하는 모든 타입에 대해 swap 함수에서 성능 향상이 있을 것이다.
- STL은 종종 복사가능한 타입을 필요로 한다. 컨테이너의 요소로 사용할 수 있는 타입이 그 예인데, 잘 생각해보면 많은 경우에 이동할 수 있는 경우면 충분하다. 즉 이동할 수 있지만 복사할 순 없는 타입을 사용할 수 있는 것이다. (unique_pointer가 생각난다) 이제는 이러한 타입들도 STL의 요소로 사용할 수 있는 것이다.
이제 std::move를 알고 있으므로, r-value 레퍼런스를 사용해 복사 대입 연산자를 오버로드하는 것에 문제가 있는 이유를 생각해볼 수 있습니다. 다음과 같은 간단한 변수 대입을 생각해봅시다.
a = b;
여기서 무엇이 일어날까요? a가 들고 있던 객체가 b가 들고있는 객체의 사본으로 교체되고 그 과정에서 a가 원래 들고 있던 객체가 파괴될 것입니다. 이번엔 다음 코드를 봅시다.
a = std::move(b);
이동 시맨틱이 간단히 바꿔치기하는 것으로 구현되어 있다면 이 코드는 a와 b가 들고 있는 객체가 서로 교환되게 하는 효과가 있을 것입니다. 아직 아무것도 파괴되지 않았습니다. a가 원래 갖고 있던 객체는 나중에 b가 스코프를 벗어날 때 파괴되겠지만 b가 이동의 대상이 되어 그 객체가 다른 곳으로 다시 전달되지 않는 경우에는 또 원래 객체는 파괴되지 않겠죠. 즉 복사 대입 연산자를 구현하는 사람은 이 객체가 언제 파괴될 지 알 수 있는 방법이 없습니다.
그래서 우리는 이 불확실한 객체 파괴라는 수렁에 도달하고 말았습니다. 어떤 변수에 객체를 대입하긴 했지만 원래 그 변수가 갖고 있던 객체는 어딘가 나돌아다니고 있는 것입니다. 그 객체의 파괴가 외부에 아무런 부작용도 일으키지 않는다면 괜찮겠지만 파괴자들은 부작용들을 일으키곤 합니다. 예로 파괴자에서 락을 해제하는 경우를 들 수 있겠군요. 즉 객체 파괴가 부작용을 일으킬 수 있는 경우 r-value 레퍼런스로 오버로드한 복사 대입 연산자에서 아래와 같이 명시적으로 객체를 파괴해 주어야 합니다.
X& X::operator=(X&& rhs)
{
// 파괴자에서 부작용을 일으킬만한 부분을 해결하되,
// 객체가 파괴되거나 대입될 수 있는 상태로 남겨둔다.
// 이동 시맨틱 : this와 rhs의 내용을 교환한다
return *this;
}
5. R-value 레퍼런스는 R-value인가요?
이번에도 X를 이동 시맨틱을 구현하는 복사 생성자와 복사 대입 연산자를 오버로드한 클래스라고 가정합시다. 이제 다음 함수를 생각해 봅시다.
void foo(X&& x)
{
X anotherX = x;
// ...
}
여기서 생길 수 있는 재밌는 질문이 있습니다. foo의 내부에서 X의 복사 생성자 중 어떤 버전이 호출되게 될까요? 여기서 x는 r-value 레퍼런스로 선언된 변수이고, 그래서 대부분의 경우 (항상 그런건 아니지만!) r-value를 참조하고 있습니다. 그래서 x를 r-value라고 생각하는 것이 타당해 보이지요.
X(X&& rhs);
가 호출되어야 할 것 같습니다. 다시 말해 r-value 레퍼런스는 R-value로 처리되어야 할 것이라 예상할 수 있습니다. R-value 레퍼런스를 설계한 사람들은 조금 미묘한 방법으로 해결책을 내어놓았습니다.
R-value 레퍼런스로 정의된 것들은 l-value일 수도 있고 r-value일 수도 있는데, 이름이 있는 경우에는 l-value이고, 이름이 없는 경우에는 r-value이다.
위에서 본 예에서는 r-value 레퍼런스로 정의된 것에 이름이 있었고, 즉 이것은 l-value입니다.
void foo(X&& x)
{
X anotherX = x; // X(X const & rhs)를 호출함
}
이번엔 r-value 레퍼런스로 정의된 것이 이름을 갖고 있지 않으므로 r-value가 되는 예제입니다.
X&& goo();
X x = goo(); // 우변에 있는 항목의 이름이 없으므로 X(X&& rhs)를 호출함
이런 규칙을 정한 이유는 바로 이름이 있는 변수들에게는 자동적으로 이동 시맨틱을 허용하는 것은 상당히 위험할 수 있기 때문입니다.
X anotherX = x;
// x 가 아직 스코프에 있음!
그렇게 되면 방금 이동시킨, 즉 지워버린 것이 아래에서도 접근할 수 있게 되어 혼란스럽고 에러나기 쉽게 됩니다. 이동 시맨틱의 요점은 이동해준 후에 바로바로 없어지는 것들일 때, 그래서 적용하나 하지 않으나 "상관없는" 경우에 한해서만 적용하자는 것입니다. 그래서 이 규칙이 생겼습니다. "뭔가에 이름이 있으면 그건 l-value이다."
그러면 "이름이 없으면 r-value이다"라는 규칙은 어떻게 생겼을까요? 위 예제 둘째 줄의 goo()는 이동한 후에도 계속 접근할 수 있는 무언가를 참조하고 있을 수도 있지만, 앞 섹션의 내용을 상기해보면 바로 그런 것이 필요할 때도 있죠! 우리는 l-value에 대해 이동 시맨틱을 재량껏 사용하기를 원하고 그래서 이 규칙을 만들었습니다. "무언가에 이름이 없으면 그건 r-value이다." 이것을 통해 우리는 원할 때에만 이동 시맨틱을 사용할 수 있게 되었고, 이것이 바로 std::move 함수가 동작하는 방식입니다. 아직은 정확한 구현을 소개하기에 너무 이르지만, 우리는 std::move를 이해하는 것에 한 걸음 더 다가갔습니다. 이 함수는 인수로 레퍼런스를 받아서 아무것도 하지 않은 채 r-value 레퍼런스를 반환합니다. 그러므로 이 표현
std::move(x)
은 r-value 레퍼런스로 선언되고 이름을 갖고 있지 않습니다. 그러므로 r-value입니다. 즉 std::move는 "인수가 r-value가 아닌 경우 r-value로 변환"하며, 그 목적을 "이름을 가림"으로써 달성합니다.
이 예제는 그 "이름유무 규칙"을 알고 있는 것이 얼마나 중요한지를 보여줍니다. Base라는 클래스를 작성했고, 이 클래스의 복사 생성자와 대입 연산자를 오버로드해서 이동 시맨틱을 구현했다고 합시다.
Base(Base const & rhs); // 이동 시맨틱이 아님
Base(Base&& rhs); // 이동 시맨틱
이제 Base 클래스를 상속해서 Derived라는 클래스를 만들었다고 합시다. Derived 클래스의 일부분인 Base 클래스에 이동 시맨틱이 적용되게 하기 위해서Derived의 복사 생성자와 대입 연산자도 오버로드해야 합니다. 복사 생성자를 살펴봅시다. 대입 연산자도 비슷할 것입니다. L-value버전은 어렵지 않습니다.
Derived(Derived const & rhs)
: Base(rhs)
{
// Derived에만 관련된 일들
}
그런데 r-value 버전은 좀 골때립니다. "이름유무 법칙"을 모르는 사람이라면 이렇게 작성할 것입니다.
Derived(Derived&& rhs)
: Base(rhs) // 틀림: rhs는 l-value이다
{
// Derived에만 관련된 일들
}
이렇게 코딩하게 되면 rhs는 이름이 있는 l-value라서 Base의 복사 생성자 중 이동을 수행하지 않는 버전을 호출하게 됩니다. 우리는 Base의 복사 생성자 중 이동을 수행하는 버전을 호출하기를 원하므로, 아래와 같이 코딩해야 합니다.
Derived(Derived&& rhs)
: Base(std::move(rhs)) // Base(Base&& rhs)를 호출하므로 오케이
{
// Derived에만 관련된 일들
}
6. 이동 시맨틱과 컴파일러 최적화
다음과 같이 함수를 정의해 봅시다.
X foo()
{
X x;
// x에 뭔가를 한다
return x;
}
이번에도 X를 이동 시맨틱을 위한 복사 생성자와 대입 연산자를 갖고 있다고 가정합시다. 이 함수의 정의를 표면적으로만 본다면 '어? x에서 함수의 리턴값으로 복사가 일어나네?' 라고 생각할 수도 있습니다. 그럼 이동 시맨틱을 사용해 볼까요.
X foo()
{
X x;
// x에 뭔가를 한다
return std::move(x); // 더 안좋아짐!
}
불행히도 이렇게 하면 상황이 더 안좋아집니다. 요즘 컴파일러들은 함수들에 대해 반환값 최적화(return value optimization)를 수행합니다. 즉 X를 지역변수로 선언하고 복사하기보단 컴파일러가 foo의 반환값 자리에 객체 X를 생성하는 것이죠. 당연하게도 이것은 이동 시맨틱보다 더 좋습니다.
그러므로 r-value 레퍼런스와 이동 시맨틱을 이상적인 방법으로 사용하기 위해서는 반환값 최적화나 복사 생략(copy elision)과 같은 최신 컴파일러의 "특별한 노력"들을 이해할 필요가 있습니다. Dave Abraham은 이 주제에 대해 훌륭한 블로그 연재물을 작성했습니다. 자세한 내용은 꽤 골치아파질 수 있지만 C++을 선택한 건 이유가 있어서죠. 우리 선택이므로 감내하도록 합시다.
7. 완벽한 전달: 문제
이동 시맨틱과는 별개로 r-value 레퍼런스는 완벽한 전달(perfect forwarding) 문제를 해결하기 위해서 만들어졌습니다. 아래와 같은 간단한 팩토리 함수를 생각해 봅시다.
template<typename T, typename Arg>
shared_ptr<T> factory(Arg arg)
{
return shared_ptr<T>(new T(arg));
}
보시다시피 이 예제의 의도는 팩토리 함수의 인수로 주어진 arg를 T의 생성자로 전달하는 것입니다. arg의 입장에서 보면 마치 팩토리 함수가 존재하지 않았고 생성자를 상위에서 직접 호출한 것처럼 행동하는 것이 이상적이겠죠. 이것이 완벽한 전달입니다. 이 코드는 그것에 비참하게 실패합니다. 우선 값호출(call by value)을 하는데 이때 생성자가 인자를 레퍼런스로 받는다면 더욱 안좋겠죠.
boost::bind 등이 선택한 가장 일반적인 해결책은 함수가 인자를 레퍼런스로 받도록 하는 것입니다.
template<typename T, typename Arg>
shared_ptr<T> factory(Arg& arg)
{
return shared_ptr<T>(new T(arg));
}
전보다는 나아졌지만 완벽하진 않습니다. 이번에 생긴 문제는 이 팩토리 함수가 r-value로는 호출할 수 없다는 것입니다.
factory<X>(hoo()); // hoo가 값을 반환한다면 에러
factory<X>(41); // 에러
이것은 상수 레퍼런스를 인자로 받는 오버로드를 만드는 것으로 해결합니다.
template<typename T, typename Arg>
shared_ptr<T> factory(Arg const & arg)
{
return shared_ptr<T>(new T(arg));
shared_ptr<T> factory(Arg const & arg)
{
return shared_ptr<T>(new T(arg));
}
이 방식에는 두 가지 문제점이 있습니다. 우선 factory가 한 개가 아닌 여러 개의 인자를 받는 경우엔 각각이 상수일 때와 아닐 때의 모든 조합에 대해서 오버로드를 만들어야 합니다. 즉 인자가 많아지면 문제 해결이 엄청나게 힘들어지죠.
또한 이 방법은 이동 시맨틱을 구현할 수 없게 되므로 완벽하지 않습니다. factory함수의 내부에서 T의 복사 생성자로 전달되는 인자는 l-value이고, 따라서 래퍼 함수가 없었던 것처럼 이동 시맨틱이 일어날 수가 없습니다.
R-value 레퍼런스를 사용하면 이 두가지 문제를 모두 해결할 수 있습니다. R-value 레퍼런스로 오버로드 없이 완벽한 전달을 달성할 수 있습니다. 이 해결책을 이해하기 위해서 r-value 레퍼런스에 관한 두 가지 규칙을 더 살펴볼 필요가 있습니다.
8. 완벽한 전달: 해결
남은 두 가지 규칙 중 첫번째는 기존의 l-value 레퍼런스에도 적용됩니다. C++11 이전의 C++에서는 레퍼런스의 레퍼런스를 취하는 것이 허용되지 않았습니다. 즉 A& &같은 걸 쓰면 컴파일 에러가 났죠. C++11에서는 반면 다음과 같은 레퍼런스 합침 규칙(reference collapsing rule)이 존재합니다.
둘째로 템플릿 인자 유추 규칙(template argument deduction rule)이라는 템플릿 인자에 r-value 레퍼런스를 취하는 함수들을 위한 특별한 규칙이 있습니다.
- A& &는 A&이 된다
- A& &&는 A&이 된다
- A&& &는 A&이 된다
- A&& &&는 A&&이 된다
둘째로 템플릿 인자 유추 규칙(template argument deduction rule)이라는 템플릿 인자에 r-value 레퍼런스를 취하는 함수들을 위한 특별한 규칙이 있습니다.
template<typename T>
void foo(T&&);
여기서 두 가지 규칙이 적용됩니다.
- foo를 타입 A의 l-value로 호출한 경우 T는 A&로 처리되어 위의 레퍼런스 합침 규칙에 의해 결과적으로 함수 인자의 타입은 A&가 된다.
- foo를 타입 A의 r-value로 호출한 경우 T는 A로 처리되며 함수 인자의 타입은 A&&가 된다.
이 규칙이 있으므로 이제 앞 섹션에 소개된 완벽한 전달 문제를 해결하는 데에 r-value 레퍼런스를 사용할 수 있습니다. 해결책은 아래와 같습니다.
template<typename T, typename Arg>
shared_ptr<T> factory(Arg&& arg)
{
return shared_ptr<T>(new T(std::forward<Arg>(arg)));
}
여기서 std::forward함수는 다음과 같이 정의됩니다.
template<class S>
S&& forward(typename remove_reference<S>::type& a) noexcept
{
return static_cast<S&&>(a);
}
(우선 noexcept 키워드에 신경쓰지 않도록 합시다. 이 키워드는 컴파일러가 최적화를 할 동안 예외를 던지지 않도록 합니다. 여기에 대해서는 다음 섹션에서 다시 이야기합니다.) 위의 코드가 어떻게 완벽한 전달을 하게 되는지를 알아보기 위해 팩토리 함수가 l-value를 인자로 받는 경우와 r-value를 인자로 받는 경우를 나누어서 생각해 봅시다. A와 X라는 타입이 있고 factory<A>가 타입 X의 l-value로 호출되었다고 합시다.
X x;
factory<A>(x);
그러면 위에 소개된 템플릿 인자 유추 규칙에 의해 factory의 템플릿 인자 Arg는 X&가 됩니다. 따라서 컴파일러는 다음과 같은 factory와 std::forward의 인스턴스를 생성하게 됩니다.
shared_ptr<A> factory(X& && arg)
{
return shared_ptr<A>(new A(std::forward<X&>(arg)));
}
X& && forward(remove_reference<X&>::type& a) noexcept
{
return static_cast<X& &&>(a);
}
여기에 remove_reference와 레퍼런스 합침 규칙을 적용하면 다음과 같아집니다.
shared_ptr<A> factory(X& arg)
{
return shared_ptr<A>(new A(std::forward<X&>(arg)));
}
X& forward(X& a) noexcept
{
return static_cast<X&>(a);
}
이렇게 하면 확실히 l-value에 대해서 완벽한 전달을 수행할 수 있습니다. 팩토리 함수의 인자 arg는 두 단계로 호출되는 동안 기존의 l-value 레퍼런스를 통해 전달됩니다.
다음으로 factory<A>가 타입 X의 r-value로 호출되었다고 해 봅시다.
X foo();
factory<A>(foo());
그러면 템플릿 유추 규칙에 의해 factory의 템플릿 인자 Arg는 X가 되고, 컴파일러는 다음과 같은 템플릿 함수 인스턴스를 생성합니다.
shared_ptr<A> factory(X&& arg)
{
return shared_ptr<A>(new A(std::forward<X>(arg)));
}
X&& forward(X& a) noexcept
{
return static_cast<X&&>(a);
}
이것이 바로 r-value의 완벽한 전달입니다. 팩토리 함수의 인자는 두 단계로 호출되는 동안 레퍼런스로 전달되며, 또한 A의 생성자에 전달되는 인자는 이름이 없는 r-value레퍼런스이기 때문에 "이름유무 규칙"에 의해 r-value입니다. 그러므로 A의 생성자는 r-value로 호출되고 이것은 마치 팩토리 함수가 없었던 것처럼 이동 시맨틱을 처리할 수 있습니다.
사실상 std::forward를 사용하는 것의 유일한 목적이 이동 시맨틱을 보존하기 위함이라는 것에 주목할 필요가 있습니다. std::forward가 없어도 모든 것이A의 생성자의 인수가 l-value로 해석된다는 것을 빼면 모든 것이 제대로 동작할 것입니다. 다시 말하자면 std::forward의 목적은 함수를 호출하는 쪽에서 래퍼가 l-value를 보는지, r-value를 보는지를 전달하기 위함입니다.
좀더 깊이 파고들어가 보자면, 이렇게 질문을 해 봅시다. std::forward의 정의 내부에서 왜 remove_reference가 필요할까요? 답은 그럴 필요가 없다는 것입니다. std::forward의 정의에서 remove_reference<S>::type& 대신 그냥 S&를 사용하더라도 위에서 한 것처럼 각각의 경우에서 완벽한 전달이 일어난다는 것을 확인할 수 있습니다. 그러나 이것은 우리가 Arg를 명시적으로 std::forward의 템플릿 인자로 사용하고 있을 때에만 그렇습니다. std::forward의 정의에 remove_reference가 있는 이유는 강제로 그렇게 하도록 하기 위함입니다.
자, 이제 거의 다 왔습니다. 이제 std::move가 어떻게 구현되었는지를 확인하는 일만 남았습니다. std::move의 목적은 인자를 레퍼런스로 받아서 r-value처럼 행동하도록 만드는 것임을 상기합시다. 구현은 다음과 같습니다.
template<class T>
typename remove_reference<T>::type&&
std::move(T&& a) noexcept
{
typedef typename remove_reference<T>::type&& RvalRef;
return static_cast<RvalRef>(a);
}
다음과 같이 std::move를 타입 X의 l-value로 호출했다고 합시다.
X x;
std::move(x);
템플릿 인자 유추 규칙에 의해 템플릿 인자 T는 X&로 해석되고, 따라서 컴파일러가 만드는 인스턴스는 다음과 같습니다.
typename remove_reference<X&>::type&&
std::move(X& && a) noexcept
{
typedef typename remove_reference<X&>::type&& RvalRef;
return static_cast<RvalRef>(a);
}
remove_reference와 레퍼런스 합침 규칙을 적용하면 다음과 같아집니다.
X&& std::move(X& a) noexcept
{
return static_cast<X&&>(a);
}
이제 다 했습니다. l-value였던 x가 l-value 레퍼런스 인자로 주어져서 함수를 통과한 결과는 이름 없는 r-value 레퍼런스가 되었습니다.
r-value에 대해서도 std::move가 제대로 동작하는 걸 확인하는 건 여러분들에게 맡기도록 하겠습니다. 하지만 std::move의 목적이 인자를 r-value로 변환하는 것이니 굳이 r-value에 std::move를 사용할 필요는 없겠죠? 또
std::move(x);
를 호출하는 대신 그냥
static_cast<X&&>(x);
할 수 있다는 걸 눈치챘을지도 모르겠네요. 하지만 std::move를 사용하는 것이 더 표현력있기 때문에 강하게 권장됩니다.
9. R-value 레퍼런스와 예외처리
보통 C++로 소프트웨어를 개발하는 경우 예외 문법을 사용하고 예외처리에 신경을 쓰거나 하는 것은 여러분의 자유입니다. R-value 레퍼런스는 이것과 조금 다릅니다. 복사 생성자와 대입 연산자를 오버로드하는 경우에 다음 수칙을 지키는 것이 좋습니다.
- 오버로드한 함수들이 예외를 던지지 않도록 노력한다. 이동 시맨틱은 보통 두 객체의 포인터와 리소스 핸들을 교환하기 때문에 많은 경우 이것은 어렵지 않다.
- 오버로드들이 예외를 던지지 않도록 만드는 데에 성공했으면 noexcept 키워드를 사용해서 사용자에게 그 사실을 알린다.
이 작업을 거치지 않으면 기대와 달리 이동 시맨틱이 작동하지 않을 수 있습니다. 그 중 한가지 흔하게 발생하는 것이 std::vector가 리사이즈될 때인데, 요소들이 새 메모리 블록으로 이동될 때 위의 두가지 작업을 하지 않으면 이동 시맨틱은 일어나지 않습니다.
이렇게 되는 이유는 꽤 복잡한데, 자세한 이야기는 Dave Abraham의 블로그를 참고하세요. 이 블로그 글은 noexcept를 사용한 해결책이 생기기 전에 만들어졌지만 이 문제가 왜 생기는지를 잘 설명해 줍니다. noexcept가 어떻게 문제를 해결하는지에 대해서는 글 위쪽에 있는 update #2 링크를 확인하세요.
10. 암시적인 이동(Implicit Move)의 경우
R-value 레퍼런스에 대한 (복잡하고 논란이 많았던) 회의에서 표준 위원회는 이동 생성자(move constructor)와 이동 대입 연산자(move assignment operator), 즉 복사 생성자와 복사 대입 연산자의 r-value 레퍼런스 오버로드를 사용자가 제공하지 않은 경우 컴파일러가 자동으로 생성되어야 한다고 정한 적이 있습니다. 컴파일러가 보통 복사 생성자와 복사 대입 연산자에 대해 똑같은 작업을 해 주기 때문에, 이 요구사항은 언뜻 보기엔 자연스럽고 이치에 맞는 것처럼 보입니다. 2010년 8월, Scott Meyers는 comp.lang.c++에 올린 글에서 컴파일러가 생성한 이동 생성자가 지금까지 사용하던 코드를 심각하게 망가뜨리는 예시를 들었습니다. Dave Abrahams가 이 문제를 블로그에 요약했습니다.
위원회는 결국 이것이 잘못되었다고 결정했고, 컴파일러가 이동 생성자와 이동 대입 연산자를 자동으로 생성하지 못하도록 해서 항상은 아니지만 대부분의 경우 코드를 망가뜨리지 못하도록 했습니다. 위원회의 이러한 결정은 Herb Sutter의 블로그에 요약되어 있습니다.
암시적인 이동에 관한 이슈는 C++ 표준이 완성될때까지 계속 논란이 되었습니다. (예: Dave Abrahams의 블로그 글과 이어지는 논의) 한가지 아이러니한것은 위원회가 애초에 암시적인 이동을 생각했던 것은 앞 섹션에 소개된 r-value 레퍼런스와 예외처리 때문에 발생하는 문제를 해결하기 위해서였습니다. noexcept를 이용한 해결책이 몇 달 전에만 나왔더라도 암시적인 이동은 세상에 나오지 않았을 지도 모르죠. 어쨌든, 이렇게 해서 암시적인 이동은 없어졌습니다.
자 이제 끝입니다. R-value 레퍼런스에 대한 모든 이야기를 했습니다. 보시는 것처럼 이것으로 인한 이득은 상당합니다만 자세히 들여다보자면 골치아프죠. C++ 전문가인데도 이런 내용을 알지 못한다면 아주 중요한 것을 포기한 것이 됩니다. 하지만 그래도 위안이 되는 건 평소에 프로그래밍 할 때에는 r-value 레퍼런스에 대해서는 다음 내용만 기억하면 된다는 것입니다.
- 다음과 같이 생긴 함수를 오버로드함으로써
void foo(X& x); // l-value 레퍼런스 오버로드
void foo(X&& x); // r-value 레퍼런스 오버로드
컴파일타임에 foo가 l-value로 호출되고 있냐 r-value로 호출되고 있냐에 따라 분기할 수 있게 된다. 이것은 이동 시맨틱을 구현한 복사 생성자와 복사 대입 연산자를 오버로드할 때 주로 (현실적으로는 유일하게) 사용된다. 이것을 사용하는 경우엔 예외처리에 신경을 써야 하고, noexcept 키워드를 최대한으로 사용해야 한다.
- std::move는 인자를 r-value로 변환한다
- std::forward을 이용하면 섹션 8의 팩토리 함수 예제에서 본 것처럼 완벽한 전달을 할 수 있다.
이제 즐겨보아요!
11. 감사의 말과 참고문헌
R-value 레퍼런스에 대한 통찰력과 정보를 공유해준 Thomas Witt에게 감사합니다. 이 글을 주의깊게 읽고 귀중한 수정사항과 아이디어들을 알려 준 Valentin David에게도 감사드립니다. 더 많은 독자들이 이 글을 발전시키는데 도움을 주었습니다. 기여해주신 모든 분들께 감사드리고 계속 피드백을 보내주시길 부탁드립니다. 아직 남아있는 문제점들은 제 탓입니다.
Howard E. Hinnant, Bjarne Stroustrup, Bronek Kozicki의 글을 읽어보기를 강력하게 권장합니다. 이 글에는 제가 만든 것보다 더 좋은 예제들이 소개되어 있으며, 관련된 많은 제안서와 기술서들의 목록이 링크되어 있습니다. 대신 이 글은 저처럼 아주 자세한 내용까지 설명하지는 않습니다. 이를테면 이 글은 레퍼런스 합침 규칙이나 템플릿 인자 유추 규칙을 따로 설명하진 않습니다.
앞서 이야기한 것처럼 Dave Abraham의 블로그 글들에는 이동 시맨틱이 반환값 최적화나 복사 생략과 같은 최적화 기법들과 어우러질 때 생기는 자세한 일들이 잘 설명되어 있습니다. 그는 다른 글에서 r-value가 예외처리랑 어떻게 연관되는지와 noexcept 키워드가 어떻게 이것을 해결하는지를 설명합니다. 글 상단의 update #2 링크도 꼭 확인하세요. 마지막으로, Dave Abraham은 암시적인 이동에 대한 문제들도 소개합니다.
