Effective Modern C++(번역서) 정리

• Chapter 1   타입 추론

  1. 템플릿 타입 추론 규칙을 숙지하라 / 10

     • 템플릿 타입 추론 도중에 참조 타입의 인수들은 비참조로 취급된다. 즉, 참조성이 무시된다.

       함수 템플릿의 선언은 대체로 이런 모습이다.
       
       template<typename T>
       void f(ParamType param);
       
       그리고 이를 호출하는 코드는 대체로 이런 모습이다.
       
       f(expr);
       // 어떤 표현식으로 f를 호출
       
       컴파일 도중 컴파일러는 expr을 이용해서 두 가지 타입을 추론하는데, 하나는 T에 대한 타입 추론이고 또 하나는 ParamType에 대한 타입 추론이다.
       
       이 두 타입이 다른 경우가 많은데, 이는 ParamType에 흔히 const나 참조 한정사(&나 &&를 말한다) 같은 수식어들이 붙기 때문이다. 예를 들어 템플릿의 선언이 다음과 같다고 하자.
       
       template<typename T>
       void f(const T& param);
       
       그리고 이를 다음과 같이 호출한다고 하자.
       
       int x = 0;
       f(x);
       
       이 경우 T는 int로 추론되나 ParamType은 const int&로 추론된다.
       
       T에 대해 추론된 타입은 expr의 타입 뿐만 아니라 ParamType의 형태에도 의존한다. 그 형태에 따라 총 세 가지 경우로 나뉜다.
       
       
       • ParamType이 포인터 또는 참조 타입이지만 보편 참조(universal reference)는 아닌 경우(보편 참조(universal reference)는 항목 24에서 설명한다. 지금은 보편 참조(universal reference)라는 것이 있고 그것이 좌측값 참조나 우측값 참조와는 다른 것이라고 알아두자!).
       • ParamType이 보편 참조(universal reference)인 경우.
       • ParamType이 포인터도 아니고 참조도 아닌 경우.
       
       
       
       경우 1: ParamType이 포인터 또는 참조 타입이지만 보편 참조(universal reference)는 아님
       1. 만일 expr이 참조 타입이면 참조 부분을 무시한다.
       2. 그런 다음 expr의 타입을 ParamType에 대해 패턴 부합(pattern-matching) 방식으로 대응시켜서 T의 타입을 결정한다.
       
       
       예제 코드 보기
       
       
       

       1. //-----------------------------------------------------------------------------
       2. // 함수 템플릿이 다음과 같다고 하자.
       3.  
       4. template <typename T>
       5. void f(T& param); // param은 참조 타입
       6.  
       7. // 그리고 이런 변수 선언들이 있다고 하자.
       8.  
       9. int x = 27; // x는 int
       10. const int cx = x; // cx는 const int
       11. const int& rx = x; // rx는 const int인 x에 대한 참조
       12.  
       13. // 다음은 여러 가지 호출에서 param과
       14. // T에 대한 추론된 타입들이다.
       15.  
       16. f(x); // T는 int, param의 타입은 int&
       17.  
       18. f(cx); // T는 const int,
       19. // param의 타입은 const int&
       20.  
       21. f(rx); // T는 const int,
       22. // param의 타입은 const int&
       23.  
       24. // 둘째, 셋째 호출에서 cx와 rx에
       25. // const 값이 대입되었기 때문에
       26. // T는 const int로 추론된다.
       27.  
       28. // 셋째 호출에서, 비록 rx의 타입이
       29. // 참조이지만 T는 비참조로 추론되었음을
       30. // 주목하자.
       31.  
       32.  
       33. //-----------------------------------------------------------------------------
       34. // f의 매개변수의 타입을 T&에서
       35. // const T&로 바꾸면 상황이
       36. // 조금 달라진다.
       37.  
       38. template <typename T>
       39. void f(const T& param); // 이제는 param이 const에 대한 참조
       40.  
       41. int x = 27; // 이전과 동일
       42. const int cx = x; // 이전과 동일
       43. const int& rx = x; // 이전과 동일
       44.  
       45. f(x); // T는 int, param의 타입은 const int&
       46.  
       47. f(cx); // T는 int, param의 타입은 const int&
       48.  
       49. f(rx); // T는 int, param의 타입은 const int&
       50.  
       51. // 이전처럼, 타입 추론 과정에서 rx의
       52. // 참조성은 무시된다.
       53.  
       54.  
       55. //-----------------------------------------------------------------------------
       56. // param이 참조가 아니라 포인터
       57. // (또는 const를 가리키는 포인터)
       58. // 라도 타입 추론은 본질적으로 같은
       59. // 방식으로 진행된다.
       60.  
       61. template <typename T>
       62. void f(T* param); // 이번에는 param이 포인터
       63.  
       64. int x = 27; // 이전과 동일
       65. const int *px = &x; // px는 const int로서의 x를 가리키는 포인터
       66.  
       67. f(&x); // T는 int, param의 타입은 int*
       68.  
       69. f(px); // T는 const int,
       70. // param의 타입은 const int*
       71.  

       
       
       예제 코드 접기
       
       
       

     • 보편 참조(universal reference) 매개변수에 대한 타입 추론 과정에서 좌측값 인수들은 특별하게 취급된다.

       경우 2: ParamType이 보편 참조(universal reference)임
       1. 만일 expr이 좌측값이면, T와 ParamType 둘 다 좌측값 참조로 추론된다. 이는 이중으로 비정상적인 상황이다. 첫째로, 템플릿 타입 추론에서 T가 참조 타입으로 추론되는 경우는 이것이 유일하다. 둘째로, ParamType의 선언 구문은 우측값 참조와 같은 모습이지만, 추론된 타입은 좌측값 참조이다.
       2. 만일 expr이 우측값이면, '정상적인'(즉, 경우 1의) 규칙들이 적용된다.
       
       
       예제 코드 보기
       
       
       

       1. template<typename T>
       2. void f(T&& param); // 이번에는 param이 보편 참조(universal reference)
       3.  
       4. int x = 27; // 이전과 동일
       5. const int cx = x; // 이전과 동일
       6. const int& rx = x; // 이전과 동일
       7.  
       8. f(x); // x는 좌측값, 따라서 T는 int&,
       9. // param의 타입 역시 int&
       10.  
       11. f(cx); // cx는 좌측값, 따라서 T는 const int&,
       12. // param의 타입 역시 const int&
       13.  
       14. f(rx); // rx는 좌측값, 따라서 T는 const int&,
       15. // param의 타입 역시 const int&
       16.  
       17. f(27); // 27은 우측값, 따라서 T는 int,
       18. // 그러므로 param의 타입은 int&&
       19.  
       20. // 보편 참조(universal reference)가 관여하는 경우에는
       21. // 좌측값 인수와 우측값 인수에 대해
       22. // 서로 다른 추론 규칙들이 적용
       23. // 된다.
       24.  
       25. // 보편 참조(universal reference)가 아닌 매개변수들에
       26. // 대해서는 그런 일이 절대 발생하지
       27. // 않는다.

       
       
       예제 코드 접기
       
       
       

     • 값 전달 방식의 매개변수에 대한 타입 추론 과정에서 const 또는 volatile(또는 그 둘 다인) 인수는 비 const, 비 volatile 인수로 취급된다.

       경우 3: ParamType이 포인터도 아니고 참조도 아님
       ParamType이 포인터도 아니고 참조도 아니라면, 인수가 함수에 값으로 전달(pass-by-value)되는 상황인 것이다. 따라서 param은 주어진 인수의 복사본, 즉 완전히 새로운 객체이다.
       
       param이 새로운 객체라는 사실 때문에, expr에서 T가 추론되는 과정에서 다음과 같은 규칙들이 적용된다.
       
       
       1. 이전처럼, 만일 expr의 타입이 참조이면, 참조 부분은 무시된다.
       2. expr의 참조성을 무시한 후, 만일 expr이 const이면 그 const 역시 무시한다. 만일 volatile이면 그것도 무시한다.
       
       
       예제 코드 보기
       
       
       

       1. template <typename T>
       2. void f(T param); // 이번에는 param이 값으로 전달된다.
       3.  
       4. int x = 27; // 이전과 동일
       5. const int cx = x; // 이전과 동일
       6. const int& rx = x; // 이전과 동일
       7.  
       8. f(x); // T와 param의 타입은 둘 다 int
       9.  
       10. f(cx); // 여전히 T와 param의 타입은 둘 다 int
       11.  
       12. f(rx); // 이번에도 T와 param의 타입은 둘 다 int
       13.  
       14. // cx와 rx가 const 값을 지정하지만,
       15. // 그래도 param은 const가 아님을
       16. // 주목하자.
       17.  
       18. // param은 cx나 rx의 복사본이므로,
       19. // 다시 말해 param은 cx나 rx와는
       20. // 완전히 독립적인 객체이므로,
       21. // 이는 당연한 결과이다.
       22.  
       23. // 여기서 명심할 것은, const가(그리고
       24. // volatile이) 값 전달 매개변수에
       25. // 대해서만 무시된다는 점이다.
       26.  
       27. // expr이 const 객체를 가리키는
       28. // const 포인터이고 param에 값으로
       29. // 전달되는 경우는 어떨까?
       30.  
       31. // 이런 예를 보자.
       32.  
       33. template <typename T>
       34. void (T param); // 인수는 param에 여전히 값으로 전달된다.
       35.  
       36. const char* const ptr = // ptr는 const 객체를 가리키는 const 포인터
       37. "Fun with pointers";
       38.  
       39. f(ptr); // const char * const 타입의 인수를 전달
       40.  
       41. // 이 경우 포인터 자체(ptr)는 값으로
       42. // 전달된다. 따라서 ptr의 상수성은
       43. // 무시된다.
       44.  
       45. // 하지만, ptr이 가리키는 객체
       46. // (여기서는 문자열)의 상수성은
       47. // 여전히 보존된다.
       48.  
       49. // 그 결과 T와 param의 타입은
       50. // 둘 다 const char*로
       51. // 추론된다.

       
       
       예제 코드 접기
       
       
       

     • 템플릿 타입 추론 과정에서 배열이나 함수 이름에 해당하는 인수는 포인터로 붕괴(decay)한다. 단, 그런 인수가 참조를 초기화하는 데 쓰이는 경우에는 포인터로 붕괴(decay)하지 않는다.

       배열 인수
       배열 타입의 함수 매개변수라는 것은 없다. 물론 다음과 같은 구문 자체는 적법하다.
       
       void myFunc(int param[]);
       
       그러나 이 경우 배열 선언은 하나의 포인터 선언으로 취급된다. 즉 myFunc의 선언은 사실상 다음과 같은 의미이다.
       
       void myFunc(int* param);
       
       이처럼 배열 매개변수 선언이 포인터 매개변수처럼 취급되므로, 템플릿 함수에 값으로 전달되는 배열의 타입은 포인터 타입으로 추론된다.
       
       즉, 템플릿 f의 호출에서 타입 매개변수 T는 const char*로 추론된다.
       
       template<typename T>
       void f(T param);
       
       const char name[] =
       "J. P. Briggs";
       
       f(name);
       // name은 배열이지만 T와
       // param은 const char*로
       // 추론된다.
       
       그런데 한 가지 교묘한 요령이 있다. 비록 함수의 매개변수를 진짜 배열로 선언할 수는 없지만, 배열에 대한 참조로 선언할 수는 있다.
       
       template<typename T>
       void f(T& param);
       
       f(name);
       // 배열을 f에 전달
       
       이렇게 하면 T에 대해 추론된 타입은 배열의 실제 타입이 된다! 그 타입은 배열의 크기를 포함하므로, 이 예에서 T는 const char [13]으로 추론되고 f의 매개변수(그 배열에 대한 참조)의 타입은 const char (&)[13]으로 추론된다.
       
       흥미롭게도, 배열에 대한 참조를 선언하는 능력을 이용하면 배열에 담긴 원소들의 개수를 추론하는 템플릿을 만들 수 있다.
       
       예제 코드 보기
       
       
       

       1. // 배열의 크기를 컴파일 시점 상수로서 돌려주는 템플릿 함수
       2. // (배열 매개변수에 이름을 붙이지 않은 것은, 이 템플릿에
       3. // 필요한 것은 배열에 담긴 원소의 개수뿐이기 때문이다)
       4. template <typename T, std::size_t N> // constexpr과
       5. constexpr std::size_t arraySize(T (&)[N]) noexcept // noexcept에
       6. { // 관해서는 다음을
       7. return N; // 보세요.
       8. }
       9.  
       10. // 항목 15에서 설명하겠지만, 이 함수를
       11. // constexpr로 선언하면 함수 호출의 결과를
       12. // 컴파일 도중에 사용할 수 있게 된다.
       13.  
       14. // 그러면 다음 예처럼 중괄호 초기화
       15. // 구문으로 정의된, 기존 배열과 같은
       16. // 크기(원소 개수)의 새 배열을 선언하는
       17. // 것이 가능해진다.
       18.  
       19. int keyVals[] = { 1, 3, 7, 9, 11, 22, 35 }; // keyVals의 원소
       20. // 개수는 7
       21.  
       22. int mappedVals[arraySize(keyVals)]; // mappedVals의 원소
       23. // 개수 역시 7
       24.  
       25. // 물론 현대적인 C++ 개발자라면 당연히
       26. // 내장 배열보다 std::array를 선호할 것이다.
       27.  
       28. std::array<int, arraySize(keyVals)> mappedVals; // mappedVals의
       29. // 크기는 7
       30.  
       31. // arraySize를 noexcept로 선언한 것은
       32. // 컴파일러가 더 나은 코드를 산출하는 데
       33. // 도움을 주려는 것인데, 자세한 사항은
       34. // 항목 14를 보기 바란다.

       
       
       예제 코드 접기
       
       
       
       함수 인수
       C++에서 포인터로 붕괴(decay)하는 것이 배열만은 아니다. 함수 타입도 함수 포인터로 붕괴(decay)할 수 있으며, 지금까지 배열에 대한 타입 추론과 관련해서 논의한 모든 것은 함수에 대한 타입 추론에, 그리고 함수 포인터로의 붕괴(decay)에 적용된다.
       
       예제 코드 보기
       
       
       

       1. void someFunc(int, double); // someFunc는 하나의 함수;
       2. // 타입은 void(int, double)
       3.  
       4. template <typename T>
       5. void f1(T param); // f1의 param은 값 전달 방식
       6.  
       7. template <typename T>
       8. void f2(T& param); // f2의 param은 참조 전달 방식
       9.  
       10. f1(someFunc); // param은 함수 포인터로 추론됨;
       11. // 타입은 void (*)(int, double)
       12.  
       13. f2(someFunc); // param은 함수 참조로 추론됨;
       14. // 타입은 void (&)(int, double)
       15.  
       16. // 실제 응용에서 이 점 때문에 뭔가 달라지는
       17. // 경우는 드물지만, 배열에서 포인터로의
       18. // 붕괴(decay)를 알고 있다면 함수에서 포인터로의
       19. // 붕괴(decay)도 알아 두는 것이 좋을 것이다.

       
       
       예제 코드 접기
       
       
       

  2. auto의 타입 추론 규칙을 숙지하라 / 19

     • auto 타입 추론은 대체로 템플릿 타입 추론과 같지만, auto 타입 추론은 중괄호 초기치가 std::initializer_list를 나타낸다고 가정하는 반면 템플릿 타입 추론은 그렇지 않다는 차이가 있다.

       예제 코드 보기
       
       
       

       1. //-----------------------------------------------------------------------------
       2. // auto를 이용해서 변수를 선언할 때
       3. // auto는 템플릿의 T와 동일한 역할을
       4. // 하며, 변수의 타입 지정자(type specifier)는
       5. // ParamType과 동일한 역할을 한다.
       6.  
       7. auto x = 27;
       8.  
       9. // 여기서 x의 타입 지정자는 그냥 auto
       10. // 자체이다. 반면, 다음 선언에서
       11.  
       12. const auto cx = x;
       13.  
       14. // 타입 지정자는 const auto이다.
       15. // 그리고 다음 선언에서는
       16.  
       17. const auto& rx = x;
       18.  
       19. // 타입 지정자가 const auto&이다.
       20.  
       21. // 이 예들에서 x와 cx, rx의 타입들을
       22. // 추론할 때, 컴파일러는 마치 선언마다
       23. // 템플릿 함수 하나와 해당 초기화
       24. // 표현식으로 그 템플릿 함수를 호출하는
       25. // 구문이 존재하는 것처럼 행동한다. 즉:
       26.  
       27. template <typename T> // x의 타입을 추론하기 위한
       28. void func_for_x(T param); // 개념적인 템플릿
       29.  
       30. func_for_x(27); // 개념적인 호출: param에 대해
       31. // 추론된 타입이 바로 x의 타입이다.
       32.  
       33. template <typename T> // cx의 타입을 추론하기 위한
       34. void func_for_cx(const T param); // 개념적인 템플릿
       35.  
       36. func_for_cx(x); // 개념적인 호출: param에 대해
       37. // 추론된 타입이 곧 cx의 타입이다.
       38.  
       39. template <typename T> // rx의 타입을 추론하기 위한
       40. void func_for_rx(const T& param); // 개념적인 템플릿
       41.  
       42. func_for_rx(x); // 개념적인 호출: param에 대해
       43. // 추론된 타입이 바로 rx의 타입이다.
       44.  
       45.  
       46. //-----------------------------------------------------------------------------
       47. // 경우 1: 타입 지정자가 포인터나 참조 타입이지만 보편 참조(universal reference)는 아닌 경우.
       48. // 경우 2: 타입 지정자가 보편 참조(universal reference)인 경우.
       49. // 경우 3: 타입 지정자가 포인터도 아니고 참조도 아닌 경우.
       50.  
       51. // 경우 1과 3의 예는 앞에서 이미 보았다.
       52.  
       53. auto x = 27; // 경우 3(x는 포인터도 아니고 참조도 아님)
       54.  
       55. const auto cx = x; // 경우 3(cx 역시 둘 다 아님)
       56.  
       57. const auto& rx = x; // 경우 1(rx는 보편 참조(universal reference)가 아닌 참조)
       58.  
       59. // 경우 2도 기대한 대로 작동한다.
       60.  
       61. auto&& uref1 = x; // x는 int이자 좌측값이므로
       62. // uref1의 타입은 int&
       63.  
       64. auto&& uref2 = cx; // cx는 const int이자 좌측값이므로
       65. // uref2의 타입은 const int&
       66.  
       67. auto&& uref3 = 27; // 27은 int이자 우측값이므로
       68. // uref3의 타입은 int&&
       69.  
       70. // 마지막으로, 항목 1에서는 비참조 타입
       71. // 지정자의 경우 배열과 함수 이름이
       72. // 포인터로 붕괴(decay)하는 방식을 논의했다.
       73.  
       74. // auto 타입 추론에 대해서도 그러한
       75. // 붕괴(decay)가 일어난다.
       76.  
       77. const char name[] = // name의 타입은 const char [13]
       78. "R. N. Briggs";
       79.  
       80. auto arr1 = name; // arr1의 타입은 const char*
       81.  
       82. auto& arr2 = name; // arr2의 타입은 const char (&)[13]
       83.  
       84.  
       85. void someFunc(int, double); // someFunc는 함수;
       86. // 그 타입은 void(int, double)
       87.  
       88. auto func1 = someFunc; // func1의 타입은
       89. // void (*)(int, double)
       90.  
       91. auto& func2 = someFunc; // func2의 타입은
       92. // void (&)(int, double)
       93.  
       94. // 이상의 예들에서 보듯이, auto의 타입 추론은
       95. // 템플릿 타입 추론과 똑같이 작동한다.
       96.  
       97.  
       98. //-----------------------------------------------------------------------------
       99. // 그러나 다른 점이 하나 있다.
       100.  
       101. // 우선, 27을 초기 값으로 해서
       102. // int 변수를 선언하는 예를 살펴보자.
       103.  
       104. // C++98에서는 다음 두 가지 구문이
       105. // 가능했다.
       106.  
       107. int x1 = 27;
       108. int x2(27);
       109.  
       110. // 균일 초기화(uniform initialization)를
       111. // 지원하는 C++11에서는 위의 두 구문과
       112. // 더불어 다음과 같은 구문들을 사용할
       113. // 수도 있다.
       114.  
       115. int x3 = { 27 };
       116. int x4{ 27 };
       117.  
       118. // 총 네 가지 구문이 존재한다. 결과적으로
       119. // 값이 27인 int가 생긴다는 점은 모두
       120. // 동일하다.
       121.  
       122. // 하지만 int 대신 auto를 사용하면
       123. // 의미가 좀 달라진다.
       124.  
       125. auto x1 = 27;
       126. auto x2(27);
       127. auto x3 = { 27 };
       128. auto x4{ 27 };
       129.  
       130. // 처음 두 선언문은 실제로 타입이
       131. // int이고 값이 27인 변수를 선언한다.
       132.  
       133. // 그러나 나머지 둘은 값이 27인 원소 하나를 담은
       134. // std::initializer_list<int> 타입의 변수를 선언한다!
       135.  
       136. auto x1 = 27; // 타입은 int, 값은 27
       137.  
       138. auto x2(27); // 마찬가지
       139.  
       140. auto x3 = { 27 }; // 타입은 std::initializer_list<int>,
       141. // 값은 { 27 }
       142.  
       143. auto x4{ 27 }; // 마찬가지
       144.  
       145. // 이는 auto에 대한 특별한
       146. // 타입 추론 규칙 때문이다.
       147.  
       148. // auto로 선언된 변수의 초기치(initializer)가
       149. // 중괄호 쌍으로 감싸인 형태이면, 추론된
       150. // 타입은 std::initializer_list이다.
       151.  
       152. // 만일 그런 타입을 추론할 수 없으면
       153. // (이를테면 중괄호 초기치의 값들의
       154. // 타입이 서로 달라서) 컴파일이 거부된다.
       155.  
       156. auto x5 = { 1, 2, 3.0 }; // 오류! std::initializer_list<T>의
       157. // T를 추론할 수 없음
       158.  
       159. // 이 예에서 사실은 두 종류의 타입 추론이
       160. // 진행된다.
       161.  
       162. // 첫 번째는 변수 선언에 auto를 사용했다는,
       163. // 따라서 x5의 타입을 추론해야 한다는
       164. // 사실에서 비롯된 타입 추론이다.
       165.  
       166. // x5의 초기치가 중괄호 형태이므로 x5의
       167. // 타입은 반드시 std::initializer_list로
       168. // 추론된다.
       169.  
       170. // 그런데 std::initializer_list는 템플릿이다.
       171.  
       172. // 이 템플릿의 인스턴스는 이떤 타입 T에 대한
       173. // std::initializer_list<T>이며,
       174. // 선언을 완성하기 위해 컴파일러는 T의 타입도
       175. // 추론해야 한다.
       176.  
       177. // 해당 템플릿 함수에 동일한 중괄호 초기치를
       178. // 전달하면 타입 추론이 실패해서 컴파일이
       179. // 거부된다.
       180.  
       181. auto x = { 11, 23, 9 }; // x의 타입은
       182. // std::initializer_list<int>
       183.  
       184. template <typename T> // x의 선언에 해당하는 매개변수
       185. void f(T param); // 선언을 가진 템플릿
       186.  
       187. f({ 11, 23, 9 }); // 오류! T에 대한 타입을 추론할 수 없음
       188.  
       189. // 하지만 param의 타입이 어떤 알려지지 않은 T에 대한
       190. // std::initializer_list<T>인 템플릿에 그 중괄호 초기치를
       191. // 전달하면 템플릿 타입 추론 규칙들에 의해 T의 타입이
       192. // 제대로 추론된다.
       193.  
       194. template <typename T>
       195. void f(std::initializer_list<T> initList);
       196.  
       197. f({ 11, 23, 9 }); // T는 int로 추론되며, initList의 타입은
       198. // std::initializer_list<int>로 추론된다.
       199.  

       
       
       예제 코드 접기
       
       
       

     • 함수의 반환 타입이나 람다 매개변수에 쓰인 auto에 대해서는 auto 타입 추론이 아니라 템플릿 타입 추론이 적용된다.

       C++14에서는 함수의 반환 타입을 auto로 지정해서 컴파일러가 추론하게 만들 수 있으며(항목 3 참고), 람다의 매개변수 선언에 auto를 사용하는 것도 가능하다.
       
       그러나 auto의 그러한 용법들에는 auto 타입 추론이 아니라 템플릿 타입 추론의 규칙들이 적용된다.
       
       그래서 중괄호 초기치를 돌려주는 함수의 반환 타입을 auto로 지정하면 컴파일이 실패한다. C++14 람다의 매개변수 타입 명세에 auto를 사용하는 경우에도 마찬가지 이유로 컴파일이 실패한다.
       
       예제 코드 보기
       
       
       

       1. //-----------------------------------------------------------------------------
       2. // 반환 타입이 auto인 경우
       3.  
       4. auto createInitList(void)
       5. {
       6. return { 1, 2, 3 }; // 오류! { 1, 2, 3 }의
       7. } // 타입을 추론할 수 없음
       8.  
       9.  
       10. //-----------------------------------------------------------------------------
       11. // 람다의 매개변수 타입 명세에 auto를
       12. // 사용하는 경우
       13.  
       14. std::vector<int> v;
       15. ...
       16.  
       17. auto resetV =
       18. [&v](const auto& newValue) { v = newValue; }; // C++14
       19.  
       20. ...
       21.  
       22. reserV({ 1, 2, 3 }); // 오류! { 1, 2, 3 }의
       23. // 타입을 추론할 수 없음
       24.  

       
       
       예제 코드 접기
       
       
       

  3. decltype의 작동 방식을 숙지하라 / 25

     • decltype은 항상 변수나 표현식의 타입을 아무 수정 없이 보고한다.

       C++11에서는 decltype은 함수의 반환 타입이 그 매개변수 타입들에 의존하는 함수 템플릿을 선언할 때 주로 쓰인다.
       
       예를 들어 컨테이너 하나와 색인 하나를 받고, 우선 사용자를 인증한 후 operator[]를 통해서 컨테이너의 한 요소를 돌려주는 함수를 작성한다고 하자.
       
       그러면 함수의 반환 타입은 반드시 그러한 operator[]의 반환 타입과 동일해야 한다. 즉 컨테이너의 operator[]의 반환 타입이 컨테이너에 따라 다를 수 있다.
       
       decltype을 이용하면 그런 함수의 반환 타입을 손쉽게 표현할 수 있다.
       
       decltype 예제 코드 보기
       
       
       

       1. template <typename Container, typename Index> // 작동하지만,
       2. auto authAndAccess(Container& c, Index i) // 좀 더 다듬을
       3. -> decltype(c[i]) // 필요가 있다.
       4. {
       5. authenticateUser();
       6. return c[i];
       7. }
       8.  
       9. // 이름 앞에 auto를 지정하는 것은 타입
       10. // 추론과는 아무런 관련이 없다.
       11.  
       12. // 이 auto는 C++11의 후행 반환 타입
       13. // (trailing return type) 구문이
       14. // 쓰인다는 것을 나타낼 뿐이다.
       15.  
       16. // 후행 반환 타입 구문은, 함수의 반환 타입을
       17. // 매개변수 목록 다음에("->" 다음 위치에)
       18. // 선언하는 구문을 말한다.
       19.  
       20. // 만일 통상적인 방식으로 함수 이름 앞에서
       21. // 반환 타입을 지정한다면, c와 i는
       22. // 사용할 수 없다(아직 선언되지 않았으므로).

       
       
       decltype 예제 코드 접기
       
       
       

     • C++14는 decltype(auto)를 지원한다. decltype(auto)는 auto처럼 초기치로부터 타입을 추론하지만, 그 타입 추론 과정에서 decltype의 규칙들을 적용한다.

       C++11은 람다 함수가 한 문장으로 이루어져 있다면 그 반환 타입의 추론을 허용하며, C++14는 허용 범위를 더욱 확장해서 모든 람다와 모든 함수의 반환 타입 추론을 허용한다(심지어 return 문이 여러개인 함수도[단, 모든 return 문의 타입 추론 결과가 일치해야 한다]).
       
       따라서, authAndAccess(위의 예제에 등장한 함수)의 경우 C++14에서는 후행 반환 타입을 생략하고 그냥 함수 이름 앞의 auto만 남겨 두어도 된다.
       
       그런 형태의 선언에서는 실제로 auto가 타입 추론이 일어남을 뜻하는 용도로 쓰인다(컴파일러가 함수의 구현으로부터 함수의 반환 타입을 추론함).
       
       항목 2에서 설명했듯이, 함수의 반환 타입에 auto가 지정되어 있으면 컴파일러는 템플릿 타입 추론을 적용한다. 지금 예에서는 그것이 문제가 된다.
       
       이러한 문제를 해결하기 위해 C++14에는 decltype(auto) 지정자가 도입되었다. 언뜻 보면 모순처럼 보이지만, 좀 더 생각해 보면 합당하다.
       
       auto는 해당 타입이 추론되어야 함을 뜻하고, decltype은 그 추론 과정에서 decltype 타입 추론 규칙들이 적용되어야 함을 뜻한다.
       
       decltype(auto) 예제 코드 보기
       
       
       

       1. //-----------------------------------------------------------------------------
       2. template <typename Container, typename Index> // C++14;
       3. auto authAndAccess(Container& c, Index i) // 아주 정확한
       4. { // 것은 아님
       5. authenticateUser();
       6. return c[i]; // 반환 타입은 c[i]로부터 추론된다.
       7. }
       8.  
       9. // T객체들을 담은 컨테이너에 대한 operator[]
       10. // 연산은 대부분의 경우에는 T&를 돌려준다.
       11.  
       12. // 문제는, 항목 1에서 설명했듯이 템플릿 타입
       13. // 추론 과정에서 초기화 표현식의 참조성이
       14. // 무시된다는 점이다.
       15.  
       16. std::deque<int> d;
       17. ...
       18. authAndAccess(d, 5) = 10; // 사용자를 인증하고, d[5]를 돌려주고,
       19. // 그런 다음 10을 d[5]에 대입한다.
       20. // 이 코드는 컴파일되지 않는다!
       21.  
       22. // 여기서 d[5]는 int&를 돌려주나,
       23. // authAndAccess에 대한 auto 반환
       24. // 타입 추론 과정에서 참조가 제거되기
       25. // 때문에 결국 반환 타입은 int가 된다.
       26.  
       27. // 이런 문제를 해결하기 위해 decltype(auto)
       28. // 지정자를 사용할 수 있다.
       29.  
       30. template <typename Container, typename Index> // C++14;
       31. decltype(auto) // 작동하지만
       32. authAndAccess(Container& c, Index i) // 좀 더 다듬을
       33. { // 필요가 있음.
       34. authenticateUser();
       35. return c[i];
       36. }
       37.  
       38. // 이제 authAndAccess의 반환 타입은
       39. // 실제로 c[i]의 반환 타입과 일치한다.
       40.  
       41.  
       42. //-----------------------------------------------------------------------------
       43. // decltype(auto)를 함수 반환
       44. // 타입에만 사용할 수 있는 것은 아니다.
       45.  
       46. // 변수를 선언할 때에도, 초기화 표현식에
       47. // decltype타입 추론 규칙들을 적용하고
       48. // 싶은 경우라면 이 지정자가 유용하다.
       49.  
       50. Widget w;
       51.  
       52. const Widget& cw = w;
       53.  
       54. auto myWidget1 = cw; // auto 타입 추론:
       55. // myWidget1의 타입은 Widget
       56.  
       57. decltype(auto) myWidget2 = cw; // decltype 타입 추론:
       58. // myWidget2의 타입은
       59. // const Widget&
       60.  
       61.  
       62. //-----------------------------------------------------------------------------
       63. // 앞에서 언급하고 설명하지 않은
       64. // authAndAccess을 다듬는 방법에
       65. // 대해서 알아보자.
       66.  
       67. // authAndAccess 함수의 C++14 버전의 선언을
       68. // 다시 보면,
       69.  
       70. template <typename Container, typename Index>
       71. decltype(auto) authAndAccess(Container& c, Index i);
       72.  
       73. // 컨테이너 c는 비 const 객체에 대한 좌측값 참조로서
       74. // 함수에 전달된다.
       75.  
       76. // 이는 함수가 돌려준 컨테이너 요소를 클라이언트(함수를
       77. // 호출한 쪽)가 수정할 수 있게 하기 위한 것이다.
       78.  
       79. // 문제는, 이 때문에 함수에 우측값 컨테이너는
       80. // 전달할 수 없다는 것이다.
       81.  
       82. // 우측값을 좌측값 참조에 묶을 수는 없다
       83. // (const에 대한 좌측값 참조에는 묶을 수
       84. // 있지만, 지금은 그런 경우가 아니다).
       85.  
       86. // 우측값도 넘길 수 있게 하려면, 항목 24에서
       87. // 설명하겠지만 보편 참조(universal reference)를 사용해야 한다.
       88.  
       89. template <typename Container, typename Index> // 이번에는 c가
       90. decltype(auto) authAndAccess(Container&& c, // 보편 참조(universal reference)
       91. Index i);
       92.  
       93. // 선언에 맞게 구현도 고칠 필요가 있다.
       94.  
       95. // 구체적으로, 항목 25의 조언에 따라
       96. // 다음과 같이 보편 참조(universal reference)에 std::forward를
       97. // 적용하기로 한다.
       98.  
       99. template <typename Container, typename Index> // 최종
       100. decltype(auto) // C++14
       101. authAndAccess(Container&& c, Index i) // 버전
       102. {
       103. authenticateUser();
       104. return std::forward<Container>(c)[i];
       105. }
       106.  
       107.  
       108. //-----------------------------------------------------------------------------
       109. // 만일 C++14를 지원하는 컴파일러가 없다면
       110. // 템플릿의 C++11 버전을 사용할 수밖에 없다.
       111.  
       112. // 반환 타입을 명시적으로 지정해야 한다는 점만
       113. // 빼고는 C++14 버전과 동일하다.
       114.  
       115. template <typename Container, typename Index> // 최종
       116. auto // C++11
       117. authAndAccess(Container&& c, Index i) // 버전
       118. -> decltype(std::forward<Container>(c)[i])
       119. {
       120. authenticateUser();
       121. return std::forward<Container>(c)[i];
       122. }
       123.  

       
       
       decltype(auto) 예제 코드 접기
       
       
       

     • decltype은 타입이 T이고 이름이 아닌 좌측값 표현식에 대해서는 항상 T& 타입을 보고한다.

       decltype을 이름에 적용하면 그 이름에 대해 선언된 타입이 산출된다. 대체로 이름은 좌측값 표현식이나, 그 점이 decltype의 행동에 영향을 주지는 않는다.
       
       그런데 이름보다 복잡한 좌측값 표현식에 대해서는 일반적으로 decltype이 항상 좌측값 참조를 보고한다. 즉, 이름이 아닌, 그리고 타입이 T인 어떤 좌측값 표현식에 대해 decltype은 T&를 보고한다.
       
       어차피 대부분의 좌측값 표현식에는 태생적으로 좌측값 참조가 포함되어 있으므로, 이 점 때문에 뭔가가 달라지는 경우는 드물다. 그러나 이러한 작동 방식이 뭔가 차이를 만드는 경우가 있기는 있다.
       
       다음 코드에서,
       
       int x = 0;
       
       x는 변수의 이름이므로 decltype(x)는 int이다. 그러나 x를 괄호로 감싸서 "(x)"를 만들면 이름보다 복잡한 표현식이 된다. 이름으로서의 x는 하나의 좌측값이며, C++은 (x)라는 표현식도 좌측값으로 정의한다.
       
       따라서 decltype((x))는 int&이다. 이름을 괄호로 감싸면 decltype이 보고하는 타입이 달라지는 것이다!
       
       C++11에서는 이것이 그냥 드물게 만나는 신기한 현상 정도이다. 그렇지만 decltype(auto)를 지원하는 C++14에서는 return문 작성 습관의 사소한 차이 때문에 함수의 반환 타입 추론 결과가 달라지는 사태가 벌어질 수 있다.
       
       예제 코드 보기
       
       
       

       1. decltype(auto) f1(void)
       2. {
       3. int x = 0;
       4. ...
       5. return x; // decltype(x)는 int이므로 f1은 int를 반환
       6. }
       7.  
       8. decltype(auto) f2(void)
       9. {
       10. int x = 0;
       11. ...
       12. return (x); // decltype((x))는 int&이므로 f2는 int&를 반환
       13. }
       14.  
       15. // f2가 f1과는 다른 타입을 돌려준다는
       16. // 점뿐만 아니라, 자신의 지역 변수에
       17. // 대한 참조를 돌려준다는 점도 주목하기
       18. // 바란다.
       19.  
       20. // 이런 종류의 코드를 작성하는 것은
       21. // 미정의 행동으로 직행하는 특급 열차에
       22. // 올라타는 것과 같다.

       
       
       예제 코드 접기
       
       
       이 예의 주된 교훈은, decltype(auto)는 아주 조심해서 사용해야 한다는 것이다. 애초에 예상했던 타입이 실제로 추론되었는지 확인하고 싶다면 항목 4에서 설명하는 기법들을 사용하면 된다.
       
       그렇지만, 보통의 경우 decltype은 기대한 바로 그 타입을 산출한다. 특히 decltype을 이름에 적용할 때에는 반드시 그렇다. 이 경우 decltype은 주어진 이름의 선언된 타입(declared type)을 돌려준다.

  4. 추론된 타입을 파악하는 방법을 알아두라 / 32

     • 컴파일러가 추론하는 타입을 IDE 편집기나 컴파일러 오류 메시지, Boost TypeIndex 라이브러리를 이용해서 파악할 수 있는 경우가 많다.

       IDE 편집기
       IDE(통합 개발 환경)의 코드 편집기 중에는 프로그램 개체(변수, 매개변수, 함수 등) 위에 마우스 커서를 올리면 그 개채의 타입을 표시해 주는 것이 많다.
       
       이런 일이 가능하려면 편집기의 코드가 어느 정도는 컴파일 가능한 상태이어야 한다. 컴파일러가 코드를 파싱해서 타입 추론을 수행할 수 있을 정도로 편집기의 코드가 완성되어 있지 않으면 편집기는 요청된 개채의 타입을 표시할 수 없다.
       
       일반적으로 int 같은 간단한 타입의 경우에는 IDE가 알려준 정보가 쓸만하지만, 좀 더 복잡한 타입이 관여할 때에는 IDE가 표시한 정보가 그리 도움이 되지 않을 수도 있다.
       
       
       컴파일러의 진단 메시지
       일반적으로 컴파일러가 추론한 타입을 파악하는 데 효과적인 방법 중 하나는, 원하는 타입 때문에 컴파일에 문제가 발생하게 만드는 것이다. 거의 항상, 문제를 보고하는 오류 메시지에는 문제를 일으킨 타입이 언급되어 있다.
       
       우선, 클래스 템플릿 하나를 정의 없이 선언만 해둔다. 이 템플릿을 인스턴스화하려 하면, 인스턴스화할 템플릿 정의가 없어서 컴파일 오류가 발생한다. 해당 오류 메시지에 우리가 원하는 정보가 들어 있다.
       
       결론적으로 x의 타입을 알고 싶다면 해당 타입들로 TD(정의 없는 클래스 템플릿)를 인스턴스화해보면 된다.
       
       예제 코드 보기
       
       
       

       1. template <typename T> // TD를 선언만 해 둔다; TD는
       2. class TD; // "Type Displayer(타입 표시기)"를
       3. // 뜻한다.
       4.  
       5. // 다음과 같은 변수 x, y가 있을 때,
       6.  
       7. const int theAnswer = 42;
       8.  
       9. auto x = theAnswer;
       10. auto y = &theAnswer;
       11.  
       12. // x와 y의 타입을 알고 싶다면 해당
       13. // 타입들로 TD를 인스턴스화해보면
       14. // 된다.
       15.  
       16. TD<decltype(x)> xType; // x와 y의 타입들이 담긴
       17. TD<decltype(y)> yType; // 오류 메시지들이 나온다.
       18.  
       19. // 이 예제 코드에는 "변수이름Type" 형태의
       20. // 변수 이름들이 쓰였는데, 이렇게 하면
       21. // 오류 메시지에서 원하는 변수의 타입을
       22. // 좀 더 쉽게 찾아낼 수 있다.
       23.  
       24. // 다음은 위의 코드에 대해 어떤 컴파일러가
       25. // 토해 낸 오류 메시지의 일부분이다.
       26.  
       27. error: aggregate 'TD<int> xType' has incomplete type and
       28. cannot be defined
       29. error: aggregate 'TD<const int *> yType' has incomplete type
       30. and cannot be defined
       31.  
       32. // 다른 한 컴파일러도 형태는 다르지만
       33. // 본질적으로 동일한 정보를 제공한다.
       34.  
       35. error: 'xType'은(는) 정의되지 않은 class 'TD<int>'을(를) 사용합니다.
       36. error: 'yType'은(는) 정의되지 않은 class 'TD<const int *>'을(를) 사용합니다.
       37.  
       38. // 서식의 차이는 있지만, 이 기법으로
       39. // 시험해 본 거의 모든 컴파일러는
       40. // 유용한 타입 정보를 제공했다.

       
       
       예제 코드 접기
       
       
       
       실행시점 출력
       "별 문제 있겠어? typeid와 std::type_info::name을 사용하면 그만이지." 라고 생각할 수도 있지만, 안타깝게도 std::type_info::name의 정보는 믿을 만하지 않다.
       
       표준을 준수하려면 std::type_info::name은 틀리게 보고할 필요가 있다. 표준에 따르면, std::type_info::name은 반드시 주어진 타입을 마치 템플릿 함수에 값 전달 매개변수로서 전달된 것처럼 취급해야 한다.
       
       항목 1에서 설명하듯이, 값 전달의 경우 만일 타입이 참조이면 참조성이 무시되며, 참조를 제거한 후의 타입이 const(또는 volatile)이면 해당 const성(또는 volatile성) 역시 무시된다.
       
       그래서 실제로는 const Widget * const&인 param의 타입이 그냥 const Widget*로 보고된다.
       
       마찬가지로 안타까운 일은 IDE 편집기가 표시하는 타입 정보 역시 믿을 만하지 않다는, 또는 적어도 믿을 만하게 유용하지는 않다는 것이다.
       
       예제 코드 보기
       
       
       

       1. // 다음의 코드가 있을 때,
       2.  
       3. template <typename T>
       4. void f(const T& param);
       5.  
       6. std::vector<Widget> createVec(void);
       7.  
       8. const auto vw = createVec();
       9.  
       10. if (!vw.empty()) {
       11. f(&vw[0]);
       12. ...
       13. }
       14.  
       15. // 어떤 IDE 편집기는 T의 타입을
       16. // 다음과 같이 보고한다.
       17.  
       18. const
       19. std::_Simple_types<std::_Wrap_alloc<std::_Vec_base_types<Widget,
       20. std::allocator<Widget> >::_Alloc>::value_type>::value_type *
       21.  
       22. // 그리고 param의 타입은 다음과
       23. // 같이 보고한다.
       24.  
       25. const std::_Simple_types<...>::value_type *const &
       26.  
       27. // T에 대한 타입보다는 덜 흉악하지만,
       28. // 중간의 "..."가 좀 혼동될 것이다.
       29.  
       30. // 해당 IDE는 "T의 타입의 일부에 해당하는
       31. // 모든 것을 생략했음"이라는 뜻을 "..."로
       32. // 표현했다.
       33.  
       34. // 행운이 따른다면, 여러분이 사용하는
       35. // IDE는 이보다는 나은 결과를 보여줄
       36. // 것이다.

       
       
       예제 코드 접기
       
       
       행운보다는 라이브러리를 더 믿는 독자라면, std::type_info::name과 IDE가 실패하는 경우에서도 Boost TypeIndex 라이브러리(흔히 Boost.TypeIndex라고 표기한다)는 성공하도록 설계되어 있다는 점을 반길 것이다.
       
       다음은 정확한 타입 정보를 Boost.TypeIndex를 이용해서 얻는 방법을 보여주는 예제 코드이다.
       
       Boost.TypeIndex 예제 코드 보기
       
       
       

       1. #include <boost/type_index.hpp>
       2.  
       3. template <typename T>
       4. void f(const T& param)
       5. {
       6. using std::cout;
       7. using boost::typeindex::type_id_with_cvr;
       9. // T를 표시
       10. cout << "T = "
       11. << type_id_with_cvr<T>().pretty_name()
       12. << '\n';
       14. // param의 타입을 표시
       15. cout << "param = "
       16. << type_id_with_cvr<param>().pretty_name()
       17. << '\n';
       18. ...
       19. }
       20.  
       21. // 이 코드가 우리가 원했던 정보를 출력하는 이유는,
       22. // 함수 템플릿 boost::typeindex::type_id_with_cvr이
       23. // 자신에게 전달된 타입 인수(우리가 알고자 하는
       24. // 타입)의 const나 volatile, 참조 한정사들을
       25. // 그대로 보존하기 때문이다(이름에 "with_cvr"이
       26. // 붙은 이유가 바로 그것이다).
       27.  
       28. // type_id_with_cvr은 하나의
       29. // boost::typeindex::type_index
       30. // 객체를 산출하며, 그 객체의 pretty_name
       31. // 멤버 함수는 타입을 사람이 보기에 좋게
       32. // 표현한 문자열을 담은 std::string
       33. // 객체를 돌려준다.
       34.  
       35. // 이제 이전에 보았던 예제를 다시 보자.
       36.  
       37. std::vector<Widget> createVec(void); // 팩터리 함수
       38.  
       39. const auto vw = createVec(); // vw를 팩터리 함수의
       40. // 반환값으로 초기화한다.
       41. if (!vw.empty()) {
       42. f(&vw[0]); // 여기서 f를 호출한다.
       43. ...
       44. }
       45.  
       46. // GNU 컴파일러와 Clang 컴파일러에서,
       47. // Boost.TypeIndex를 사용하는 예제는
       48. // 다음과 같은 (정확한)출력을 낸다.
       49.  
       50. T = Widget const*
       51. param = Widget const* const&
       52.  
       53. // Microsoft 컴파일러의 결과도 본질적으로
       54. // 동일하다.
       55.  
       56. T = class Widget const *
       57. param = class Widget const * const &
       58.  

       
       
       Boost.TypeIndex 예제 코드 접기
       
       
       

     • 일부 도구의 결과는 유용하지도 않고 정확하지도 않을 수 있으므로, C++의 타입 추론 규칙들을 제대로 이해하는 것은 여전히 필요한 일이다.

• Chapter 2   auto

  5. 명시적 타입 선언보다는 auto를 선호하라 / 39

     • auto 변수는 반드시 초기화해야 하며, 이식성 또는 효율성 문제를 유발할 수 있는 타입 불일치가 발생하는 경우가 거의 없으며, 대체로 변수의 타입을 명시적으로 지정할 때보다 타자량도 더 적다.

       예제 코드 보기
       
       
       

       1. //-----------------------------------------------------------------------------
       2. // auto는 반드시 초기화 해야 한다.
       3.  
       4. int x1; // 문맥에 따라서는 초기화되지 않을 수 있음
       5.  
       6. auto x2; // 오류! 초기치가 꼭 필요함
       7.  
       8. auto x3 = 0; // 양호함: x3의 값이 잘 정의됨
       9.  
       10.  
       11. //-----------------------------------------------------------------------------
       12. // 반복자의 역참조를 통해 초기화되는
       13. // 지역 변수 하나를 간단하게 선언해보자.
       14.  
       15. template <typename It> // b에서 e까지의 구간에 있는 모든
       16. void dwim(It b, It e) // 요소에 대해 dwim("do what I mean")
       17. { // 알고리즘을 수행한다.
       18. for (; b != e; ++b) {
       19. typename std::iterator_traits<It>::value_type
       20. currValue = *b;
       21. ...
       22. }
       23. }
       24.  
       25. // auto를 사용하면 훨씬 간단하게(적은
       26. // 타이핑으로) 선언할 수 있다.
       27.  
       28. template <typename It>
       29. void dwim(It b, It e)
       30. {
       31. for (; b != e; ++b) {
       32. auto currValue = *b;
       33. ...
       34. }
       35. }
       36.  
       37.  
       38. //-----------------------------------------------------------------------------
       39. // auto는 타입 추론을 사용하므로(항목 2참고),
       40. // 예전에는 컴파일러만 알던 타입을 지정할 수 있다.
       41. // 아주 후련한 용법이다.
       42.  
       43. auto derefUPLess = // std::unique_ptr들이
       44. [](const std::unique_ptr<Widget>& p1, // 가리키는 Widget
       45. const std::unique_ptr<Widget>& p2) // 객체들을 비교하는
       46. { return *p1 < *p2; } // 함수
       47.  
       48.  
       49. //-----------------------------------------------------------------------------
       50. // C++14에서는 람다 표현식의 매개변수에도 auto를
       51. // 적용할 수 있어서 더욱 후련해진다.
       52.  
       53. auto derefUPLess = // C++14 버전:
       54. [](const auto& p1, // 그 어떤 것이든
       55. const auto& p2) // 포인터처럼 작동하는
       56. { return *p1 < *p2; } // 것들이 가리키는 값들을
       57. // 비교하는 함수
       58.  
       59.  
       60. //-----------------------------------------------------------------------------
       61. // 후련하긴 하지만, 클로저를 담는 변수를
       62. // 선언할 때 굳이 auto를 사용할 필요는
       63. // 없다는 생각이 들지도 모르겠다.
       64.  
       65. // 그냥 std::function 객체를 사용하면 되지
       66. // 않을까?
       67.  
       68. // 그럴 수도 있지만, 여러분이 정말로 원한
       69. // 것과는 다른 결과가 날 수도 있다.
       70.  
       71. // std::function은 C++ 표준 라이브러리의
       72. // 한 템플릿으로, 함수 포인터 개념을 일반화
       73. // 한 것이다.
       74.  
       75. // std::function은 함수 뿐만이 아니라,
       76. // 호출 가능한 객체이면 그 어떤 것도
       77. // 가리킬 수 있다.
       78.  
       79. // std::function 객체를 생성할 때에는 그것이
       80. // 지칭할 함수의 타입을 반드시 지정해야 한다.
       81.  
       82. // 예를 들어 다음과 같은 함수 시그니처에 해당하는
       83. // 임의의 호출 가능 객체를 지정하는 std::function을
       84. // 생성한다고 하자.
       85.  
       86. bool(const std::unique_ptr<Widget>&, // C++ 버전
       87. const std::unique_ptr<Widget>&) // std::unique_ptr<Widget>
       88. // 비교 함수의 시그니처
       89.  
       90. // 그러면 다음과 같은 코드가 필요하다.
       91.  
       92. std::function<bool(const std::unique_ptr<Widget>&,
       93. const std::unique_ptr<Widget>&)> func;
       94.  
       95. // 람다 표현식이 산출하는 클로저는
       96. // 호출 가능 객체이므로, std::function
       97. // 객체에 저장할 수 있다.
       98.  
       99. // 따라서 C++11 버전의 derefUPLess를
       100. // 다음처럼 auto를 사용하지 않고
       101. // 선언할 수 있다.
       102.  
       103. std::function<bool(const std::unique_ptr<Widget>&,
       104. const std::unique_ptr<Widget>&)>
       105. derefUPLess = [](const std::unique_ptr<Widget>& p1,
       106. const std::unique_ptr<Widget>& p2)
       107. { return *p1 < *p2; }
       108.  
       109. // auto를 사용하는 것보다, std::function을
       110. // 사용하는 것이 훨씬 장황하고 매개변수
       111. // 타입들을 반복해서 지정해야 한다는
       112. // 외견상의 차이보다 더 중요한 차이가
       113. // 있다.
       114.  
       115. // auto로 선언된, 그리고 클로저를 담는
       116. // 변수는 그 클로저와 같은 타입이며, 따라서
       117. // 그 클로저에 요구되는 만큼의 메모리만
       118. // 사용한다.
       119.  
       120. // 그러나 클로저를 담는 std::function으로
       121. // 선언된 변수의 타입은 std::function
       122. // 템플릿의 한 인스턴스이며, 그 크기는
       123. // 임의의 주어진 시그니처에 대해 고정되어
       124. // 있다.
       125.  
       126. // 그런데 그 크기가 요구된 클로저를
       127. // 저장하기에 부족할 수도 있으며, 그런
       128. // 경우 std::function은 힙 메모리를
       129. // 할당해서 클로저를 저장한다.
       130.  
       131. // 결과적으로, 대체로 std::function 객체는
       132. // auto로 선언된 객체보다 메모리를 더
       133. // 많이 소비한다.
       134.  
       135. // 그리고 인라인화(inlining)를 제한하고 간접
       136. // 함수 호출을 산출하는 구현 세부사항 때문에,
       137. // std::function 객체를 통해서 클로저를
       138. // 호출하는 것은 거의 항상 auto로 선언된
       139. // 객체를 통해 호출하는 것보다 느리다.
       140.  
       141. // std::bind 호출의 결과를 담기 위한
       142. // auto와 std::function의 경쟁 역시
       143. // auto가 승리한다.
       144.  
       145.  
       146. //-----------------------------------------------------------------------------
       147. // auto를 사용하는 것의 또 다른 장점은,
       148. // "타입 단축(type shortcut)"이라고 부르는
       149. // 것과 관련된 문제를 피할 수 있다는 것이다.
       150.  
       151. // 다음은 흔히 볼 수 있는 예이다.
       152.  
       153. std::vector<int> v;
       154. ...
       155. unsigned sz = v.size();
       156.  
       157. // v.size()의 공식적인 반환 타입은
       158. // std::vector<int>::size_type인데,
       159. // 그 점을 아는 개발자는 별로 없다.
       160.  
       161. // 이 타입은 부호 없는 정수타입으로 지정되므로,
       162. // 많은 프로그래머는 그냥 unsigned로 충분하다고
       163. // 생각하고 위와 같은 코드를 작성한다.
       164.  
       165. // 그런데, 32비트 Windows에서 unsigned와
       166. // std::vector<int>::size_type은
       167. // 같은 크기이지만, 64비트 Windows에서는 unsigned는
       168. // 32비트인 반면 std::vector<int>::size_type은
       169. // 64비트이다.
       170.  
       171. // 이는 32비트 Windows 환경에서는 잘
       172. // 작동하는 코드가 64비트 Windows 환경에서는
       173. // 잘 작동하지 않을 수도 있음을 의미한다.
       174.  
       175. // auto를 사용하면 이런 문제를 피할 수 있다.
       176.  
       177. auto sz = v.size(); // sz의 타입은 std::vector<int>::size_type
       178.  
       179.  
       180. //-----------------------------------------------------------------------------
       181. // 아직도 auto를 선호해야 한다는 점을 확신하지
       182. // 못하겠다면 다음 코드를 보기 바란다.
       183.  
       184. std::unordered_map<std::string, int> m;
       185. ...
       186. for (const std::pair<std::string, int>& p : m)
       187. {
       188. ... // p로 뭔가를 수행
       189. }
       190.  
       191. // 완벽해 보이지만, std::unordered_map(해시 테이블)의
       192. // 키 부분이 const라는 점을 기억한다면 무엇이 문제인지
       193. // 감이 올 것이다.
       194.  
       195. // 해시 테이블에 담긴 std::pair의 타입은
       196. // std::pair<std::string, int>가 아니라
       197. // std::pair<const std::string, int>이다.
       198.  
       199. // 그런데 이는 루프 위의 변수 p에 대해 선언된
       200. // 타입과는 다르다.
       201.  
       202. // 그래서 컴파일러는 std::pair<const std::string, int>
       203. // 객체들을 std::pair<std::string, int> 객체로
       204. // 변환하려 든다.
       205.  
       206. // 루프의 각 반복에서, 컴파일러는 p를 묶고자
       207. // 하는 타입의 임시 객체를 생성하고, m의 각
       208. // 객체를 복사하고, 참조 p를 그 임시 객체에
       209. // 묶음으로써 그러한 변환을 실제로 수행한다.
       210.  
       211. // 임시 객체가 생성되고 복사가 일어나므로
       212. // 효율이 떨어지는 것은 물론이고, p의 주소를
       213. // 구하면 임시 객체의 주소를 얻을 수 있을 뿐이다.
       214.  
       215. // 반면 다음과 같이 auto를 사용하면,
       216.  
       217. for (const auto& p : m)
       218. {
       219. ... // 이전과 동일
       220. }
       221.  
       222. // 타자도 더 쉽고, 더 효율적이며, p의 주소를
       223. // 구하면 실제로 m 안의 한 요소를 가리키는
       224. // 포인터를 얻게 된다.

       
       
       예제 코드 접기
       
       
       

     • auto로 타입을 지정한 변수는 항목 2와 항목 6에서 설명한 문제점들을 겪을 수 있다.

       auto는 필수가 아니라 선택이다. 여러분의 전문가다운 판단에 의해, 명시적 타입 선언을 사용하는 것이 더 깔끔하거나 유지보수하기 쉬운, 또는 다른 어떤 방식으로 더 나은 코드로 이어진다는 결론을 내렸다면, 명시적 타입 선언을 계속 사용하면 그만이다.
       
       예전에는 소스 코드를 흘깃 보기만 해도 객체의 타입을 파악할 수 있었지만, auto를 사용하면 더는 그럴 수 없다는 점을 걱정하는 개발자들도 있다. 그러나 이 문제는 객체의 타입을 보여주는 IDE의 기능으로 완화되는 경우가 많다.
       
       게다가, 많은 경우 객체의 타입을 다소 추상적으로만 파악해도 객체의 정확한 타입을 아는 것만큼이나 도움이 된다. 변수 이름을 잘 지어 두었다고 가정한다면, auto를 사용한다고 해도 그러한 추상적인 타입 정보는 거의 항상 바로 파악할 수 있다.
       
       더 나아가서, auto 타입들은 초기화 표현식의 타입이 변하면 자동으로 변한다. 이는 리펙터링(refactoring)이 어느 정도 수월해짐을 의미한다.

  6. auto가 원치 않은 타입으로 추론될 때에는 명시적 타입의 초기치를 사용하라 / 46

     • "보이지 않는" 프록시 타입 때문에 auto가 초기화 표현식의 타입을 "잘못" 추론할 수 있다.

       예를 들어 std::vector<bool>::operator[]의 반환 타입은 bool&이 아니라 어떤 프록시 클래스(proxy class) 타입이다(Effective STL의 항목 18을 보자).
       
       이러한 프록시(Proxy) 설계 패턴은 소프트웨어 설계 패턴 중 만신전(萬神殿 - Pantheon)을 아주 오래전부터 차지하고 있는 패턴 중 하나이다.
       
       프록시 클래스 중에는 클라이언트에게 명백히 드러나도록 설계된 것들이 있다. std::shared_ptr와 std::unique_ptr가 좋은 예이다. 반면, 그 외의 프록시 클래스들은 다소 은밀하게 작동하도록(보이지 않도록) 숨겨져 있다.
       
       대체로, "보이지 않는" 프록시 클래스는 auto와 잘 맞지 않는다. 그런 클래스는 해당 객체의 수명이 한 문장 이상으로 연장되지는 않는다는 가정하에서 설계되는 경우가 많으며, 따라서 그런 타입의 변수를 생성하는 것은 라이브러리 설계의 근본적인 가정들을 위반하는 경향이 있다.
       
       이 때문에 다음과 같은 코드는 미정의 동작을 유발한다.
       
       예제 코드 보기
       
       
       

       1. // 예를 들어 Widget을 하나 받고 std::vector<bool>을
       2. // 돌려주는 다음과 같은 함수가 하나 있다고 하자.
       3.  
       4. std::vector<bool> features(const Widget& w);
       5.  
       6. // 해당 bool 값들은 그 Widget이 특정 기능(feature)을
       7. // 지원하는지를 뜻한다고 가정한다.
       8.  
       9. // 더 나아가서, 5번 비트는 주어진 Widget의 우선순위가
       10. // 높은지를 나타낸다고 가정하자.
       11.  
       12. // 이 함수를 이용해서 다음과 같은 코드를
       13. // 작성할 수 있을 것이다.
       14.  
       15. Widget w;
       16. ...
       17.  
       18. bool highPriority = features(w)[5]; // w의 우선순위가 높은가?
       19. ...
       20.  
       21. processWidget(w, highPriority); // w를 그 우선순위에 맞게
       22. // 처리한다.
       23.  
       24. // 이 코드는 딱히 문제될 것이 없다.
       25.  
       26. // 하지만 bool 대신 auto로 highPriority를
       27. // 선언하면 어떻게 될까?
       28.  
       29. auto highPriority = features(w)[5]; // w의 우선순위가 높은가?
       30.  
       31. // 여전히 컴파일되지만, 이제는
       32. // 그 행동을 예측할 수 없다.
       33.  
       34. processWidget(w, highPriority); // 미정의 행동!
       35.  
       36. // 그 이유는 std::vector<bool>::operator[]가
       37. // bool&을 반환하는 것이 아니라,
       38. // std::vector<bool>::reference라는
       39. // 프록시 객체를 반환하고, 이러한 객체의
       40. // 수명이 한 문장 이상으로 연장되지 않도록
       41. // 만들어지는 것이 보통이기 때문이다.
       42.  
       43. // 즉, processWidget이 호출될 시점에는
       44. // 이미 highPriority 객체
       45. // (std::vector<bool>::reference 객체)
       46. // 내부의 포인터는 이미 소멸된 대상을
       47. // 가리키고 있게 된다.
       48.  
       49. // 정리하자면, 다음과 같은 형태의 코드는 피해야 한다.
       50.  
       51. auto someVar = "보이지 않는" 프록시 클래스 타입의 표현식;
       52.  

       
       
       예제 코드 접기
       
       
       (숨겨진)프록시 객체의 존재를 확인하는 방법을 살펴보자.
       
       '보이지 않는' 프록시 클래스는 일상적인 용법에서는 그 존재가 드러나지 않도록 설계된 것이지만, 그래도 라이브러리의 문서에는 프록시 클래스의 존재가 명시되어 있는 경우가 많다.
       
       문서화의 결함을 헤더 파일이 채워주기도 한다. 소스 코드에서 프록시 객체의 존재를 완전히 숨길 수 있는 경우는 거의 없다.
       
       일반적으로 프록시 객체는 클라이언트가 호출하도록 만들어진 어떤 함수가 돌려주며, 그런 함수의 시그니처를 보면 프록시 객체의 존재를 확인할 수 있는 경우가 많다.
       
       예제 코드 보기
       
       
       

       1. // 예를 들어 다음은, std::vector<bool>::operator[]의
       2. // 명세이다.
       3.  
       4. namespace std {
       5. template <class Allocator>
       6. class vector<bool, Allocator> {
       7. public:
       8. ...
       9. class reference { ... };
       11. reference operator[](size_type n);
       12. ...
       13. };
       14. }
       15.  
       16. // 보통의 경우 std::vector<T>의 operator[]가
       17. // T&를 돌려준다는 사실을 알고 있다면
       18. // 이 operator[]의 반환 타입을 생소하게 느낄
       19. // 것이며, 그러한 생소함은 곧 이 부분에서
       20. // 프록시 클래스가 쓰이고 있음을 암시해주는
       21. // 힌트라 할 수 있다.

       
       
       예제 코드 접기
       
       
       

     • 타입 명시 초기치 관용구는 auto가 원하는 타입을 추론하도록 강제한다.

       어떤 경로로 발견했든, auto가 프록시 클래스의 타입을 추론함을 알게 되었다고 하자. 이때 해결책은 auto를 버리는 것이 아니다. auto가 우리가 원했던 타입을 추론하도록 강제하면 된다.
       
       타입 명시 초기치 관용구는 초기화에 쓰이는 표현식이 산출하는 타입과는 다른 타입으로 변수를 생성 하고자 하는 의도를 명확하게 나타내는 데에도 유용하다.
       
       타입 명시 초기치 관용구(explicitly typed initializer idiom) 예제 코드 보기
       
       
       

       1. //-----------------------------------------------------------------------------
       2. // 아까 문제가 되었던 다음 코드를 다시 보자.
       3.  
       4. std::vector<bool> features(const Widget& w);
       5.  
       6. Widget w;
       7. ...
       8.  
       9. auto highPriority = features(w)[5];
       10.  
       11. // features의 반환 타입은 std::vector<bool>
       12. // 이고 std::vector<bool>::operator[]의
       13. // 반환 타입은 std::vector<bool>::reference
       14. // 인데, 우리가 필요한 것은 bool 타입이다.
       15.  
       16. // 다음은 highPriority가 bool로 추론되도록
       17. // 강제하는 예이다.
       18.  
       19. auto highPriority = static_cast<bool>(features(w)[5]);
       20.  
       21.  
       22. //-----------------------------------------------------------------------------
       23. // 타입 명시 초기치 관용구는 초기화에
       24. // 쓰이는 표현식이 산출하는 타입과는
       25. // 다른 타입으로 변수를 생성 하고자
       26. // 하는 의도를 명확하게 나타내는
       27. // 데에도 유용하다.
       28.  
       29. // 예를 들어 어떤 허용 한계치를 계산하는
       30. // 다음과 같은 함수가 있다고 하자.
       31.  
       32. double calcEpsilon(void); // 허용 한계치를 돌려준다.
       33.  
       34. // 그런데 여러분의 프로그램에는 float의
       35. // 정밀도로 충분하며, double이 float에
       36. // 비해 크다는 점이 걱정이라고 하자.
       37.  
       38. // 그럼 calcEpsilon의 결과를 float에
       39. // 담으면 된다.
       40.  
       41. float ep = calcEpsilon(); // double에서 float로의
       42. // 암묵적 변환이 일어남
       43.  
       44. // 그런데 이 코드는 "함수가 돌려준
       45. // 값의 정밀도를 일부러 줄이고자 한다"는
       46. // 의도를 명확하게 표현하지 않는다.
       47.  
       48. // 타입 명시 초기치 관용구를 이용하면
       49. // 그런 의도가 표현된다.
       50.  
       51. auto ep = static_cast<float>(calcEpsilon());
       52.  

       
       
       타입 명시 초기치 관용구(explicitly typed initializer idiom) 예제 코드 접기
       
       
       

• Chapter 3   현대적 C++에 적응히기

  7. 객체 생성시 괄호(())와 중괄호({})를 구분하라 / 53

     • 중괄호 초기화는 가장 광범위하게 적용할 수 있는 초기화 구문이며, 축소 변환(narrowing conversion)을 방지하며, C++의 가장 성가신 구문 해석에서 자유롭다.

       여러 가지 초기화 구문이 주는 혼동을 완화하기 위해, 그리고 그 구문들이 모든 가능한 초기화 시나리오를 포괄하지 않는다는 사실을 해결하기 위해, C++11은 균일 초기화(uniform initialization)를 도입했다.
       
       균일 초기화 구문은 중괄호를 사용하며, 그래서 여기서는 균일화 초기화보다 중괄호 초기화라는 표현을 선호한다.
       
       예제 코드 보기
       
       
       

       1. //-----------------------------------------------------------------------------
       2. // 기존의 변수 초기화 방법에, 중괄호 초기화 방법을
       3. // 더해 총 4가지의 방법으로 변수를 초기화할 수 있다.
       4.  
       5. int a(0); // 초기치를 괄호로 감산 예
       6.  
       7. int b = 0; // 초기치를 "=" 다음에 지정한 예
       8.  
       9. int c{ 0 }; // 초기치를 중괄호로 감싼 예
       10.  
       11. int d = { 0 }; // "="와 중괄호로 초기치를 지정한 예
       12.  
       13. // 이번 항목의 나머지 부분에서는 이러한
       14. // '등호와 중괄호' 구문은 무시한다.
       15.  
       16. // 대체로 C++은 이를 중괄호만 사용한
       17. // 구문과 동일하게 취급하기 때문이다.
       18.  
       19.  
       20. //-----------------------------------------------------------------------------
       21. // 중괄호 초기화를 이용하면 이전에는 표현할 수
       22. // 없었던 방식의 객체 생성을 표현할 수 있다.
       23.  
       24. std::vector<int> v{ 1, 3, 5 }; // v의 초기 내용은 1, 3, 5
       25.  
       26.  
       27. //-----------------------------------------------------------------------------
       28. // 중괄호 구문은 비정적(non-static) 데이터 멤버의
       29. // 기본 초기화 값을 지정하는 데에도 사용할 수 있다.
       30.  
       31. // C++에서 새로 생긴 이러한 능력은 괄호 없이
       32. // "="만 있는 초기화 구문으로도 사용할 수 있다.
       33.  
       34. class Widget {
       35. ...
       36.  
       37. private:
       38. int x{ 0 }; // OK, x의 기본값은 0
       39. int y = 0; // 역시 OK
       40. int z(0); // 오류!
       41. };
       42.  
       43.  
       44. //-----------------------------------------------------------------------------
       45. // 반면, 복사할 수 없는 객체(이를테면 std::atomic
       46. // - 항목 40을 볼 것)는 중괄호나 괄호로는
       47. // 초기화할 수 있지만, "="로는 초기화할 수 없다.
       48.  
       49. std::atomic<int> ai1{ 0 }; // OK
       50.  
       51. std::atomic<int> ai2(0); // OK
       52.  
       53. std::atomic<int> ai3 = 0; // 오류!
       54.  
       55.  
       56. //-----------------------------------------------------------------------------
       57. // 중괄호 초기화의 혁신적인 기능 하나는,
       58. // 내장 기능들 사이의 암묵적 축소 변환
       59. // (narrowing conversion)을 방지해 준다는
       60. // 것이다.
       61.  
       62. double x, y, z;
       63. ...
       64. int sum1{ x + y + z }; // 오류! double들의 합을 int로
       65. // 표현하지 못할 수 있음.
       66.  
       67. // 괄호나 "="를 이용한 초기화는 이러한
       68. // 축소 변환을 점검하지 않는다.
       69.  
       70. // 그런 점검을 강제하면 기존의 코드가
       71. // 더 이상 컴파일되지 않는 경우가
       72. // 너무 많아지기 때문이다.
       73.  
       74. int sum2(x + y + z); // OK(표현식의 값이 int에
       75. // 맞게 잘려나감)
       76.  
       77. int sum3 = x + y + z; // 마찬가지
       78.  
       79.  
       80. //-----------------------------------------------------------------------------
       81. // 중괄호 초기화의 또 다른 주목할 만한
       82. // 특징은, C++에서 가장 성가신 구문 해석
       83. // (most vexing parse)에 자유롭다는 점이다.
       84.  
       85. // 가장 성가신 구문 해석은 "선언으로 해석할
       86. // 수 있는 것은 항상 선언으로 해석해야 한다"는
       87. // C++의 규칙에서 비롯된 부작용이다.
       88.  
       89. Widget w1(10); // 인수 10으로 Widget의 생성자를 호출
       90.  
       91. Widget w2(); // 가장 성가신 구문 해석! Widget의 기본
       92. // 생성자를 호출하는 것이 아니라, Widget을
       93. // 돌려주는, w2라는 이름의 함수를 선언한다
       94.  
       95. Widget w3{} // 인수 없이 Widget의 생성자를 호출
       96.  

       
       
       예제 코드 접기
       
       
       

     • 생성자 오버로딩 해소 과정에서 중괄호 초기화는 가능한 한 std::initializer_list 매개변수가 있는 생성자와 부합한다(심지어 겉으로 보기에 그보다 인수들에 더 잘 부합하는 생성자가 있어도).

       예제 코드 보기
       
       
       

       1. //-----------------------------------------------------------------------------
       2. // 생성자 호출에서 std::initializer_list 매개변수가
       3. // 관여하지 않는 한 괄호와 중괄호의 의미는 같다.
       4.  
       5. class Widget {
       6. public:
       7. Widget(int i, bool b); // std::initializer_list
       8. Widget(int i, double d); // 매개변수를 선언하지 않는
       9. ... // 생성자
       10. };
       11.  
       12. Widget w1(10, true); // 첫 생성자를 호출
       13.  
       14. Widget w2{ 10, true }; // 역시 첫 생성자를 호출
       15.  
       16. Widget w3(10, 5.0); // 둘째 생성자를 호출
       17.  
       18. Widget w4{ 10, 5.0 }; // 역시 둘째 생성자를 호출
       19.  
       20.  
       21. //-----------------------------------------------------------------------------
       22. // 그러나 생성자 중 하나 이상이 std::initializer_list
       23. // 타입의 매개 변수를 선언한다면, 중괄호 초기화
       24. // 구문은 이상하게도 std::initializer_list를 받는
       25. // 오버로딩 버전을 "강하게" 선호한다.
       26.  
       27. // 예를 들어 위의 Widget 클래스에
       28. // std::initializer_list<long double>을
       29. // 받는 생성자를 하나 추가해보자.
       30.  
       31. class Widget {
       32. public:
       33. Widget(int i, bool b); // 이전과 동일
       34. Widget(int i, double d); // 이전과 동일
       35. Widget(std::initializer_list<long double> il); // 추가됨
       36. ...
       37. };
       38.  
       39. // 이렇게 하면, 다음 코드의 주석에서 보듯이
       40. // Widget의 인스턴스 w2와 w4는 새 생성자를
       41. // 통해서 생성된다(더 나쁜 부합임에도).
       42.  
       43. Widget w1(10, true); // 괄호를 사용한 경우; 이전처럼
       44. // 첫 생성자를 호출
       45.  
       46. Widget w2{ 10, true }; // 중괄호를 사용한 경우; 이번에는
       47. // std::initializer_list 생성자 호출
       48. // (10과 true가 long double로 변환됨)
       49.  
       50. Widget w3(10, 5.0); // 괄호를 사용한 경우; 이전처럼 둘째
       51. // 생성자를 호출한다.
       52.  
       53. Widget w4{ 10, 5.0 }; // 중괄호를 사용한 경우; 이번에는
       54. // std::initializer_list 생성자 호출
       55. // (10과 5.0이 long double로 변환됨)
       56.  
       57.  
       58. //-----------------------------------------------------------------------------
       59. // 보통은 복사 생성이나 이동 생성이 일어났을
       60. // 상황에서도 std::initializer_list 생성자가
       61. // 끼어들어서 기회를 가로챈다.
       62.  
       63. class Widget {
       64. public:
       65. Widget(int i, bool b); // 이전과 동일
       66. Widget(int i, double d); // 이전과 동일
       67. Widget(std::initializer_list<long double> il); // 이전과 동일
       69. operator float(void) const; // float 로
       70. ... // 변환
       71. };
       72.  
       73. Widget w5(w4); // 괄호 사용, 복사 생성자 호출
       74.  
       75. Widget w6{ w4 }; // 중괄호 사용, std::initializer
       76. // _list 생성자 호출
       77. // (w4가 float으로 변환되고 그
       78. // float이 long double로 변환됨)
       79.  
       80. Widget w7(std::move(w4)); // 괄호 사용, 이동 생성자 호출
       81.  
       82. Widget w8{ std::move(w4) }; // 중괄호 사용, std::initializer
       83. // _list 생성자 호출(w6에서와
       84. // 마찬가지의 변환들이 일어남)
       85.  
       86.  
       87. //-----------------------------------------------------------------------------
       88. // 중괄호 초기치를 std::initializer_list를 받는 생성자에
       89. // 대응시키고자 하는 컴파일러의 결심은 너무나
       90. // 강해서, 심지어는 가장 부합한 std::initializer_list
       91. // 생성자를 호출할 수 없는 경우에도 std::initializer_list
       92. // 생성자를 우선합니다.
       93.  
       94. class Widget {
       95. public:
       96. Widget(int i, bool b); // 이전과 동일
       97. Widget(int i, double d); // 이전과 동일
       99. Widget(std::initializer_list<bool> il); // 이제는 요소의
       100. // 타입이 bool
       101.  
       102. ... // 암묵적 변환
       103. }; // 함수는 없음
       104.  
       105. Widget w{ 10, 5.0 }; // 오류! 축소 변환이 필요함
       106.  
       107.  
       108. //-----------------------------------------------------------------------------
       109. // 컴파일러가 자신의 결심을 포기하고 보통의
       110. // 오버로딩 해소로 물러나는 경우는 중괄호
       111. // 초기치의 인수 타입들을 std::initializer_list
       112. // 안의 타입으로 변환하는 방법이 아예 없을
       113. // 때뿐이다.
       114.  
       115. class Widget {
       116. public:
       117. Widget(int i, bool b); // 이전과 동일
       118. Widget(int i, double d); // 이전과 동일
       120. // 이제는 std::initializer_list의 원소 타입이 std::string
       121. Widget(std::initializer_list<std::string> il);
       122. ... // 암묵적 변환
       123. }; // 함수 없음
       124.  
       125. Widget w1(10, true); // 괄호 사용, 여전히 첫 생성자를 호출
       126.  
       127. Widget w2{ 10, true }; // 중괄호 사용, 이제는 첫 생성자 호출
       128.  
       129. Widget w3(10, 5.0); // 괄호 사용, 여전히 둘째 생성자를 호출
       130.  
       131. Widget w4{ 10, 5.0 }; // 중괄호 사용, 이제는 둘째 생성자 호출
       132.  
       133. // int, bool, double을 std::string으로
       134. // 암묵적으로 변환할 방법이 없기 때문이다.
       135.  
       136.  
       137. //-----------------------------------------------------------------------------
       138. // 빈 중괄호 쌍을 사용하면 어떻게 받아들일까?
       139.  
       140. // 표준에 따르면 빈 중괄호 쌍을 사용하면
       141. // 기본 생성자가 호출된다.
       142.  
       143. // 즉 빈 중괄호 쌍은 빈 std::initializer_list가
       144. // 아니라 인수 없음을 뜻한다.
       145.  
       146. class Widget {
       147. public:
       148. Widget(void); // 기본 생성자
       150. Widget(std::initializer_list<int> il); // std::initializer
       151. // _list 생성자
       152.  
       153. ... // 암묵적 변환
       154. }; // 함수 없음
       155.  
       156. Widget w1; // 기본 생성자를 호출
       157.  
       158. Widget w2{}; // 역시 기본 생성자를 호출
       159.  
       160. Widget w3(); // 가장 성가신 구문 해석! 함수 선언임!
       161.  
       162. // 빈 std::initializer_list로 std::initializer_list 생성자를
       163. // 호출하고 싶다면, 다음처럼 빈 중괄호 쌍을
       164. // 괄호로 감싸거나 빈 중괄호 쌍을 또 다른
       165. // 중괄호 쌍으로 감싸면 된다.
       166.  
       167. Widget w4({}) // std::initializer_list 생성자를
       168. // 빈 초기치 리스트로 호출
       169.  
       170. Widget w5{{}} // 마찬가지
       171.  

       
       
       예제 코드 접기
       
       
       이 문제 외에도 항목 2에서 auto로 선언된 변수를 중괄호 초기치로 초기화 하면 std::initializer_list 타입으로 추론되는 문제를 살펴본 바 있다.
       
       이러한 문제들 때문에 대부분의 개발자들은 둘 중 하나를 기본으로 삼아서 항상 사용하고, 다른 하나는 꼭 필요할 때에만 사용한다.
       
       두 접근방식 중 하느 것이 나은지에 대한 공감대는 형성되어 있지 않으므로, 할 수 있는 조언은 둘 중 하나를 선택해서 일관되게 적용하라는 것이다.

     • 괄호와 중괄호의 선택이 의미 있는 차이를 만드는 예는 인수 두 개로 std::vector<수치 타입>을 생성하는 것이다.

       예제 코드 보기
       
       
       

       1. // std::vector에는 컨테이너의 초기 크기와
       2. // 컨테이너의 모든 초기 요소의 값을
       3. // 지정할 수 있는 비std::initializer_list
       4. // 생성자가 있다.
       5.  
       6. // 그런데, 컨테이너의 초기 값들을
       7. // 지정할 수 있는, std::initializer_list를
       8. // 받는 생성자도 있다.
       9.  
       10. // 이 때문에 수치 타입의 값들을 담는
       11. // std::vector를 생성할 때 생성자에 인수
       12. // 두 개를 지정한다면, 그 인수들을
       13. // 괄호로 감싸느냐 중괄호로 감싸느냐에
       14. // 따라 아주 다른 결과가 나온다.
       15.  
       16. std::vector<int> v1(10, 20); // 비std::initializer_list
       17. // 생성자를 사용: 모든 요소의
       18. // 값이 20인, 요소 10개짜리
       19. // std::vector가 생성됨
       20.  
       21. std::vector<int> v2{ 10, 20 }; // std::initializer_list
       22. // 생성자를 사용: 값이 각각 10과
       23. // 20인 두 요소를 담은
       24. // std::vector가 생성됨
       25.  

       
       
       예제 코드 접기
       
       
       

     • 템플릿 안에서 객체를 생성할 때 괄호를 사용할 것인지 중괄호를 사용할 것인지 선택하기가 어려울 수 있다.

       예제 코드 보기
       
       
       

       1. // 예를 들어 임의의 개수의 인수들을 지정해서
       2. // 임의의 타입의 객체를 생성한다고 하자.
       3.  
       4. // 개념적으로는, 가변 인수 템플릿
       5. // (variadic template)을 이용하면
       6. // 그런 템플릿을 만드는 것이 전혀
       7. // 복잡하지 않다.
       8.  
       9. template <typename T, // 생성할 객체의 타입
       10. typename... Ts> // 사용할 인수들의 타입들
       11. void doSomeWork(Ts&&... params)
       12. {
       13. params...으로부터 지역 T 객체를 생성한다;
       15. ...
       16. }
       17.  
       18. // 의사코드로 표시된 줄을 실제 코드로
       19. // 바꾸는 방법은 다음 두 가지이다.
       20.  
       21. T localObject(std::forward<T>(params)...); // 괄호를 사용
       22.  
       23. T localObject{ std::forward<T>(params)... }; // 중괄호를 사용
       24.  
       25. // 이제 다음과 같은 호출 코드를
       26. // 생각해 보자.
       27.  
       28. std::vector<int> v;
       29. ...
       30. doSomeWork<std::vector<int> >(10, 20);
       31.  
       32. // 만일 doSomeWork가 괄호를 이용해서
       33. // localObject를 생성한다면, 그 결과는
       34. // 요소가 10개인 std::vector이다.
       35.  
       36. // doSomeWork가 중괄호를 이용한다면
       37. // 결과는 요소가 2개인 std::vector이다.
       38.  
       39. // 어느 쪽이 옳은지는 doSomeWork 작성자가
       40. // 알 수 없다. 오직 호출자만이 알 수
       41. // 있을 뿐이다.

       
       
       예제 코드 접기
       
       
       이는 표준 라이브러리 함수 std::make_unique와 std::make_shared(항목 21 참고)가 해결해야 했던 문제와 정확히 동일하다.
       
       두 함수는 내부적으로 괄호를 사용하고, 그러한 결정을 인터페이스의 일부에 문서화함으로써 이 문제를 해결한다.
       
       템플릿으로부터 만들어진 함수가 괄호를 사용할 것인지 아니면 중괄호를 사용할 것인지를 호출자가 결정할 수 있는 좀 더 유연한 설계도 가능하다. 자세한 사항은 Andrzej's C++ blog의 2013년 6월 5일 자 글 "Intuitive interface - Part Ⅰ"을 보기 바란다.

  8. 0과 NULL보다 nullptr를 선호하라 / 63

     • 0과 NULL보다 nullptr를 선호하라.

       요점부터 말하자면, 리터럴 0은 int이지 포인터가 아니다. 실용적인 관점에서는 NULL도 마찬가지이다. 그러나 NULL의 경우에는 다소 불확실한 세부사항이 존재한다. 구현이 NULL에 int 이외의 정수 타입을 부여할 수도 있기 때문이다.
       
       C++98에서 이 점이 이야기하는 주된 문제는 포인터와 정수 타입에 대한 오버로딩이 의외의 방식으로 해소된다는 점이었다. 0이나 NULL로 그런 오버로딩된 함수를 호출했을 때, 포인터를 받는 오버로딩된 함수가 호출되는 일은 없다.
       
       반면 nullptr를 사용하면 오버로딩이 예상과 다르게 해소되는 일이 없다. 그 뿐만 아니라, nullptr는 코드의 명확성도 높여준다.
       
       템플릿의 타입 추론시에도, 0과 NULL은 정수 타입으로 추론하는 반면, nullptr은 포인터 타입으로 추론한다.
       
       예제 코드 보기
       
       
       

       1. //-----------------------------------------------------------------------------
       2. // 포인터와 정수 타입에 대한 오버로딩이
       3. // 의외의 방식으로 해소되는 예제
       4.  
       5. void f(int); // f의 세 가지 오버로딩
       6. void f(bool);
       7. void f(void*);
       8.  
       9. f(0); // f(void*)가 아니라 f(int)를 호출
       10.  
       11. f(NULL); // 컴파일되지 않을 수도 있지만, 보통은
       12. // f(int)를 호출한다. f(void*)를 호출
       13. // 하는 경우는 없다.
       14.  
       15. f(nullptr); // f(void*)를 호출한다.
       16.  
       17.  
       18. //-----------------------------------------------------------------------------
       19. // nullptr이 코드의 명확성을
       20. // 높여주는 예제
       21.  
       22. auto result = findRecord( /* 인수들 */ );
       23.  
       24. if (result == 0) {
       25. ...
       26. }
       27.  
       28. // findRecord의 반환 타입을 모르거나
       29. // 쉽게 파악할 수 없다면, result가
       30. // 포인터 타입인지 아니면 정수 타입인지를
       31. // 명확히 말할 수 없게 된다.
       32.  
       33. // 반면 다음 코드에는 모호성(ambiguity)이
       34. // 없다.
       35.  
       36. auto result = findRecord( /* 인수들 */ );
       37.  
       38. if (result == nullptr) {
       39. ...
       40. }
       41.  
       42. // 이 경우에는 result가 포인터
       43. // 타입임이 분명하다.
       44.  
       45.  
       46. //-----------------------------------------------------------------------------
       47. // nullptr는 템플릿이 관여할 때
       48. // 특히나 빛난다.
       49.  
       50. // 적절한 뮤텍스를 잠근 상태에서만
       51. // 호출해야 하는 함수들이 있는데,
       52. // 그 함수들이 다음처럼 각자 다른
       53. // 종류의 포인터를 받는다고 하자.
       54.  
       55. int f1(std::shared_ptr<Widget> spw); // 이 함수들은 적절한
       56. double f2(std::unique_ptr<Widget> upw); // 뮤텍스를 잠그고
       57. bool f3(Widget* pw); // 호출해야 한다.
       58.  
       59. // 다음은 널 포인터로 이들을 호출하는 예이다.
       60.  
       61. std::mutex f1m, f2m, f3m; // f1, f2, f3용 뮤텍스들
       62.  
       63. using MuxGuard = // C++11 typedef; 항목 9 참고
       64. std::lock_guard<std::mutex>;
       65. ...
       66.  
       67. {
       68. MuxGuard g(f1m); // f1용 뮤텍스를 잠근다.
       69. auto result = f1(0); // 0을 널 포인터로서 f1에 전달
       70. } // 여기서 뮤텍스가 풀린다.
       71.  
       72. ...
       73.  
       74. {
       75. MuxGuard g(f2m); // f2용 뮤텍스를 잠근다.
       76. auto result = f2(NULL); // NULL을 널 포인터로서 f2에 전달
       77. } // 여기서 뮤텍스가 풀린다.
       78.  
       79. ...
       80.  
       81. {
       82. MuxGuard g(f3m); // f3용 뮤텍스를 잠근다.
       83. auto result = f3(nullptr); // nullptr을 널 포인터로서 f3에 전달
       84. } // 여기서 뮤텍스가 풀린다.
       85.  
       86. // 호출 코드의 반복 패턴이 보인다.
       87.  
       88. // 세 경우 모두 뮤텍스를 잠그고,
       89. // 함수를 호출하고, 뮤텍스를 푸는
       90. // 패턴을 따른다는 점이 신경에
       91. // 거슬린다.
       92.  
       93. // 이런 종류의 소스 코드 중복을
       94. // 피하는 것이 템플릿의 목적
       95. // 중 하나이다.
       96.  
       97. // 템플릿화 해 보자.
       98.  
       99. template <typename FuncType,
       100. typename MuxType,
       101. typename PtrType>
       102. auto lockAndCall(FuncType func,
       103. MuxType& mutex,
       104. PtrType ptr) -> decltype(func(ptr))
       105. {
       106. using MuxGuard = std::lock_guard<MuxType>;
       108. MuxGuard g(mutex);
       109. return func(ptr);
       110. }
       111.  
       112. // 이 함수 템플릿은 C++14에서는 다음처럼
       113. // 만들 수도 있다(이에 관해서는 항목 3에서
       114. // 자세히 나온다).
       115.  
       116. template <typename FuncType,
       117. typename MuxType,
       118. typename PtrType>
       119. decltype(auto) lockAndCall(FuncType func, // C++14
       120. MuxType& mutex,
       121. PtrType ptr)
       122. {
       123. using MuxGuard = std::lock_guard<MuxType>;
       125. MuxGuard g(mutex);
       126. return func(ptr);
       127. }
       128.  
       129. // C++11 버전이든 C++14 버전이든 lockAndCall을
       130. // 이용하면 다음과 같은 코드를 작성할 수 있다.
       131.  
       132. auto result1 = lockAndCall(f1, f1m, 0); // 오류!
       133.  
       134. ...
       135.  
       136. auto result2 = lockAndCall(f2, f2m, NULL); // 오류!
       137.  
       138. ...
       139.  
       140. auto result3 = lockAndCall(f3, f3m, nullptr); // OK
       141.  
       142. // 0과 NULL의 경우, lockAndCall의 매개변수
       143. // ptr의 타입이 정수 타입으로 추론된다.
       144.  
       145. // 하지만 정수 타입은 스마트 포인터나
       146. // Widget* 포인터 타입으로 변환할 수
       147. // 없다.
       148.  
       149. // 반면 nullptr의 경우, ptr의 타입은
       150. // std::nullptr_t로 추론된다.
       151.  
       152. // std::nullptr_t는 암묵적으로
       153. // 모든 포인터 타입으로 변환될 수 있으므로
       154. // 아무런 문제가 발생하지 않는다.
       155.  

       
       
       예제 코드 접기
       
       
       

     • 정수 타입과 포인터 타입에 대한 오버로딩을 피하라.

       이 항목에서 말하듯이 nullptr가 더 나은 선택임에도 0과 NULL을 사용하는 개발자들이 여전히 있을 것이기 때문이다.

  9. typedef보다 별칭 선언을 선호하라 / 67

     • typedef는 템플릿화를 지원하지 않지만, 별칭 선언은 지원한다.

       예제 코드 보기
       
       
       

       1. //-----------------------------------------------------------------------------
       2. // STL 컨테이너들을 사용하다 보면
       3. // 다음과 같은 타입을 흔히 만난다.
       4.  
       5. std::unique_ptr<std::unordered_map<std::string, std::string> >
       6.  
       7. // 이런 타입을 여러 번 입력하고 싶지는
       8. // 않을 것이다. 그냥 생각만 해도 손목
       9. // 터널 증후군에 걸릴 것 같다.
       10.  
       11. // 이럴 때 사용할 수 있는 것이 typedef
       12. // 이다.
       13.  
       14. typedef
       15. std::unique_ptr<std::unordered_map<std::string, std::string> >
       16. UPtrMapSS;
       17.  
       18. // 그런데 typedef는 너무 C++98스러운 유물이다.
       19. // C++11에서도 typedef가 작동하지만,
       20. // C++11은 별칭 선언(alias declaration)
       21. // 이라는 것도 제공한다.
       22.  
       23. using UPtrMapSS =
       24. std::unique_ptr<std::unordered_map<std::string, std::string> >;
       25.  
       26. // typedef와 하는 일은 정확히 동일하다.
       27.  
       28. // 하지만 typedef보다 우월한 점이
       29. // 몇 가지 있다.
       30.  
       31.  
       32. //-----------------------------------------------------------------------------
       33. // 소소한 장점으로 함수 포인터가 관여하는
       34. // 타입을 다룰 때 별칭 선언 쪽을 더
       35. // 쉽게 이해하는 사람들이 많다는 점을
       36. // 들 수 있다.
       37.  
       38. // FP는 int 하나와 const std::string& 하나를 받고
       39. // 아무것도 돌려주지 않는 함수와 동의어이다.
       40. typedef void (*FP)(int, const std::string&); // typedef
       41.  
       42. // 위와 같은 의미
       43. using FP = void (*)(int, const std::string&); // 별칭 선언
       44.  
       45. // 하지만 이것만으로는 typedef 대신
       46. // 별칭 선언을 선택해야 할 강력한
       47. // 이유가 되지 못한다.
       48.  
       49.  
       50. //-----------------------------------------------------------------------------
       51. // 강력한 이유는 따로 있다. 바로
       52. // 템플릿이다.
       53.  
       54. // typedef는 템플릿화를 할 수 없지만
       55. // 별칭 선언은 템플릿화할 수 있다.
       56.  
       57. // 이런 별칭 선언을 별칭 템플릿(alias
       58. // templates)이라고 부른다.
       59.  
       60. // typedef로 템플릿화를 흉내내려면,
       61. // 불편하게 struct 안에 내포된
       62. // typedef들을 활용하는 편법을
       63. // 써야 한다.
       64.  
       65. template <typename T> // MyAllocList<T>::type은
       66. struct MyAllocList { // std::list<T,
       67. typedef std::list<T, MyAlloc<T> > type; // MyAlloc<T> >와
       68. }; // 동의어이다.
       69.  
       70. MyAllocList<Widget>::type lw; // 클라이언트 코드
       71.  
       72. // 반면 별칭 템플릿은 훨씬 더 간단하고,
       73. // 직접적으로 표현할 수 있다.
       74.  
       75. template <typename T> // MyAllocList<T>는
       76. using MyAllocList = std::list<T, MyAlloc<T> >; // std::list<T,
       77. // MyAlloc<T> >와
       78. // 동의어이다.
       79.  
       80. MyAllocList<Widget> lw; // 클라이언트 코드
       81.  

       
       
       예제 코드 접기
       
       
       

     • 별칭 템플릿에서는 "::type" 접미어를 붙일 필요가 없다. 템플릿 안에서 typedef를 지정할 때에는 "typename" 접두사를 붙어야 하는 경우가 많다.

       예제 코드 보기
       
       
       

       1. // typedef를 사용하면 상황이 더
       2. // 나빠질 수도 있다.
       3.  
       4. template <typename T>
       5. class Widget { // Widget<T>에는
       6. private: // MyAllocList<T> 타입의
       7. typename MyAllocList<T>::type list; // 데이터 멤버가 있다.
       8. ...
       9. };
       10.  
       11. // 방금 예에서 MyAllocList<T>::type은
       12. // 템플릿 타입 매개변수(T)에 의존적인
       13. // 타입을 지칭한다.
       14.  
       15. // 즉, MyAllocList<T>::type은 소위
       16. // 의존적 타입(dependent type)이며,
       17. // C++에서는 의존적 타입의 이름 앞에 반드시
       18. // typename을 붙여야 한다
       19. // (Effective C++ 의 항목 42 참고).
       20.  
       21. // 반면 MyAllocList를 별칭 템플릿으로
       22. // 정의하면 typename을 붙일 필요가 없다
       23. // (또한 번거로운 "::type" 접미어도
       24. // 붙일 필요가 없다).
       25.  
       26. template <typename T>
       27. using MyAllocList = std::list<T, MyAlloc<T> >; // 이전과 동일
       28.  
       29. template <typename T>
       30. class Widget {
       31. private:
       32. MyAllocList<T> list; // "typename" 없음
       33. ... // "::type" 없음
       34. };

       
       
       예제 코드 접기
       
       
       

     • C++14는 C++11의 모든 타입 특성 변환에 대한 별칭 템플릿들을 제공한다.

       템플릿 메타 프로그래밍(TMP)을 하다 보면 어떤 타입 T가 주어졌을 때, T에 담긴 임의의 const 한정사나 기타 참조 한정사들을 제거하거나 붙여야 할 경우가 있다. C++은 이런 종류의 변환을 타입 특성(type trait)의 형태로 수행할 수 있는 도구들을 제공한다.
       
       여기서 타입 특성은 <type_traits> 헤더 안에 있는 일단의 템플릿들을 말한다. 그 헤더에는 수십 가지 타입 특성들이 있는데, 그것들이 모두 타입 변환을 수행하지는 않지만, 하나의 예측 가능한 인터페이스를 제공하는 것은 사실이다.
       
       적용하고자 하는 타입 T가 주어졌을 때, 변환을 적용한 결과로 나온 타입은 항상 std::변환<T>::type이다.
       
       이런 변환들을 적용할 때 "::type"라는 접미어를 붙여야 한다는 점에 주목하자. 템플릿 안의 타입 매개변수에 그 접미어를 붙인다면, 그 앞에 typename도 반드시 붙여야 한다.
       
       이것은, C++11의 타입 특성들이 모두 템플릿화된 struct 안에 내포된 typedef들로 구현되었다는 사실 때문에 필요한 것이다.
       
       다행히 표준 위원회는 C++11의 모든 타입 변환에 대한 별칭 템플릿 버전들을 C++14에 포함시켰다.
       
       예제 코드 보기
       
       
       

       1. //-----------------------------------------------------------------------------
       2. std::remove_const<T>::type // const T를 T로 변환
       3.  
       4. std::remove_reference<T>::type // T&나 T&&를 T로 변환
       5.  
       6. std::add_lvalue_reference<T>::type // T를 T&로 변환
       7.  
       8. // 주석들은 단지 해당 변환이 하는 일을
       9. // 요약한 것일 뿐이므로, 너무 문자 그대로
       10. // 받아들이지는 말기 바란다.
       11.  
       12. // 이들을 여러분의 프로젝트에 사용하기 전에,
       13. // 먼저 정확한 명세를 찾아보리라고 믿는다.
       14.  
       15. // C++14에는 이러한 모든 타입 변환에 대한
       16. // 별칭 템플릿 버전들이 포함되었다.
       17.  
       18. std::remove_const<T>::type // C++11: const T -> T
       19. std::remove_const_t<T> // 해당 C++14 버전
       20.  
       21. std::remove_reference<T>::type // C++11: T&/T&& -> T
       22. std::remove_reference_t<T> // 해당 C++14 버전
       23.  
       24. std::add_lvalue_reference<T>::type // C++11: T -> T&
       25. std::add_lvalue_reference_t<T> // 해당 C++14 버전
       26.  
       27.  
       28. //-----------------------------------------------------------------------------
       29. // C++14를 사용할 수 없는 상황이라고
       30. // 하더라도, 해당 별칭 템플릿들을
       31. // 스스로 작성하는 것이 아이들 장난
       32. // 수준이다.
       33.  
       34. // C++11의 언어 기능들만 있으면 아이들이라도
       35. // 얼마든지 패턴을 흉내낼 수 있다.
       36.  
       37. // 다음을 출발점으로 삼기 바란다.
       38.  
       39. template <class T>
       40. using remove_const_t = typename remove_const<T>::type;
       41.  
       42. template <class T>
       43. using remove_reference_t = typename remove_reference<T>::type;
       44.  
       45. template <class T>
       46. using add_lvalue_reference_t =
       47. typename add_lvalue_reference<T>::type;
       48.  
       49. // 이 예에서 보듯이, 전혀 어렵지 않다.

       
       
       예제 코드 접기
       
       
       

  10. 범위 없는 enum보다 범위 있는 enum을 선호하라 / 72

      • C++98 스타일의 enum을 이제는 범위 없는 enum이라고 부른다.

        C++98 스타일의 enum으로 선언된 열거자(enumerator)들에 대해서는 "한 중괄호 쌍 안에서 어떤 이름을 선언하면 그 이름의 가시성은 해당 중괄호 쌍이 정의하는 범위로 한정된다"는 일반적인 규칙이 적용되지 않는다.
        
        그런 열거자 이름들은 enum을 포함하는 범위에 속하며, 따라서 그 범위에 같은 이름이 있으면 안 된다. 이러한 이유로 C++98 스타일의 enum을 범위 없는(unscoped) enum이라고 부른다.
        
        enum Color { black, white, red };
        // black, white, red는
        // Color가 속한 범위에 속함
        
        auto white = false;
        // 오류! 이 범위에 이미
        // white가 선언되어 있음
        
        

      • 범위 있는 enum의 열거자들은 그 안에서만 보인다. 이 열거자들은 오직 캐스팅을 통해서만 다른 타입으로 변환된다.

        C++11의 새로운 열거형인 범위 있는(scoped) enum은 "enum class"라는 구문으로 선언한다는 점 때문에, enum 클래스라고 부르기도 한다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 범위 있는 enum은 이름 누수가
        3. // 발생하지 않는다.
        4.  
        5. enum class Color { black, white, red }; // black, white, red는
        6. // Color 범위에 속함
        7.  
        8. auto white = false; // OK: 이 범위에 다른
        9. // "white"는 없음
        10.  
        11. Color c = white; // 오류! 이 범위에 "white"라는
        12. // 이름의 열거자가 없음
        13.  
        14. Color c = Color::white; // OK
        15.  
        16. auto c = Color::white; // 역시 OK(그리고 항목 5의
        17. // 조언과도 일치함)
        18.  
        19.  
        20. //-----------------------------------------------------------------------------
        21. // 이름공간(namespace) 오염을 줄여줄 뿐만
        22. // 아니라 열거자들에 타입이 훨씬 강력하게
        23. // 적용된다는 장점도 있다.
        24.  
        25. // 범위 없는 enum의 열거자들은 암묵적으로
        26. // 정수 타입으로 변환된다(그리고 정수
        27. // 타입으로부터 암묵적으로 부동소수점
        28. // 타입으로 변환된다).
        29.  
        30. enum Color { black, white, red }; // 범위 없는 enum
        31.  
        32. std::vector<std::size_t> // x의 소인수들을
        33. primeFactors(std::size_t x); // 돌려주는 함수
        34.  
        35. Color c = red;
        36. ...
        37.  
        38. if (c < 14.5) { // Color를 double과 비교(!)
        40. auto factors = // Color의 소인수들을
        41. primeFactors(c); // 계산(!)
        42. ...
        43. }
        44.  
        45. // 그러나 "enum" 다음에 그냥 "class"만 붙이면,
        46. // 그래서 범위 없는 enum을 범위 있는 enum으로
        47. // 바꾸면, 이야기가 아주 달라진다.
        48.  
        49. // 범위 있는 enum의 열거자는 암묵적으로 다른
        50. // 타입으로 변환되지 않기 때문이다.
        51.  
        52. enum class Color { black, white, red }; // 이제는 enum에
        53. // 범위가 적용됨
        54.  
        55. Color c = Color::red; // 이전과 동일하나,
        56. ... // 범위 한정사가 있음
        57.  
        58. if (c < 14.5) { // 오류! Color와 double을
        59. // 비교할 수 없음
        61. auto factors = // 오류! std::size_t를 기대하는
        62. primeFactors(c); // 함수에 Color를 전달할 수 없음
        63. ...
        64. }
        65.  
        66. // 이런 이유로 Color를 다른 타입으로 변환하고
        67. // 싶으면, 타입 시스템을 원하는 대로 굴복시킬
        68. // 때 항상 사용하는 바로 그것, 즉 캐스팅을
        69. // 사용하면 된다.
        70.  
        71. if (static_cast<double>(c) < 14.5) { // 이상한 코드이지만
        72. // 어쨌든 유효함
        74. auto factors = // 의심스럽지만
        75. primeFactors(static_cast<std::size_t>(c)); // 컴파일은 됨
        76. ...
        77. }
        78.  
        79.  
        80. //-----------------------------------------------------------------------------
        81. // 범위 있는 enum의 이런 장점들 때문에,
        82. // 범위 없는 enum은 더 이상 필요하지
        83. // 않다고 생각할 수도 있지만, 놀랍게도
        84. // 범위 없는 enum이 유용한 상황이
        85. // 적어도 하나는 존재한다.
        86.  
        87. // 바로, C++11의 std::tuple 안에 있는
        88. // 필드들을 지칭할 때이다.
        89.  
        90. // 예를 들어 어떤 소셜 네트워크 웹사이트의
        91. // 사용자 이름과 이메일 주소, 그리고 평판치
        92. // (reputation value)를 담는 다음과 같은
        93. // 튜플(tuple)이 있다고 하자.
        94.  
        95. using UserInfo = // 타입 별칭; 항목 9 참고
        96. std::tuple<std::string, // 사용자 이름
        97. std::string, // 이메일 주소
        98. std::size_t>; // 평판치
        99.  
        100. // 주석에는 튜플의 각 필드가 뜻하는 바가
        101. // 나와 있지만, 다른 어떤 소스 파일에서
        102. // 다음과 같은 코드와 마주친다면 해당
        103. // 필드가 무엇을 뜻하는지를 바로 알기
        104. // 힘들다.
        105.  
        106. UserInfo uInfo; // tuple 타입의 객체
        107. ...
        108.  
        109. auto val = std::get<1>(uInfo); // 필드 1의 값을 얻는다.
        110.  
        111. // 이럴 때 범위 없는 enum으로 필드 번호를
        112. // 필드 이름에 연관시키면 그런 것들을
        113. // 일일이 기억할 필요가 없다.
        114.  
        115. enum UserInfoFields { uiName, uiEmail, uiReputation };
        116.  
        117. UserInfo uInfo; // 이전과 동일
        118. ...
        119.  
        120. auto val = std::get<uiEmail>(uInfo); // 이메일 필드의 값을
        121. // 얻음이 명확함
        122.  
        123. // 범위 있는 enum 버전은 훨씬 장황하다.
        124.  
        125. enum class UserInfoFields { uiName, uiEmail, uiReputation };
        126.  
        127. UserInfo uInfo; // 이전과 동일
        128. ...
        129.  
        130. auto val =
        131. std::get<static_cast<std::size_t>(UserInfoFields::uiEmail)>
        132. (uInfo);
        133.  
        134. // 범위 없는 enum을 사용한 코드가 더 간단한 이유는,
        135. // 범위 없는 enum은 정수 타입으로 암묵적인 변환이
        136. // 가능하기 때문이다.
        137.  
        138. // 열거자(범위 있는) 하나를 받아서 그에 해당하는
        139. // std::size_t 값을 돌려주는 함수를 작성 한다면
        140. // 장황함이 줄어들겠지만, 그런 함수를 작성하는
        141. // 것이 다소 까다롭다.
        142.  
        143. // std::get은 하나의 템플릿이며, 여기에
        144. // 넘겨주는 것은 함수 인수가 아니라 템플릿
        145. // 타입 인수이다.
        146.  
        147. // 따라서 열거자를 std::size_t로 변환하는 함수는
        148. // 그 결과를 컴파일 도중에 산출해야 한다.
        149.  
        150. // 항목 15에서 설명하겠지만, 그러려면 그
        151. // 함수는 반드시 constexpr 함수 템플릿이어야
        152. // 한다.
        153.  
        154. // 함수 템플릿인 이유는 어떤 종류의 enum에
        155. // 대해서도 작동하게 하기 위함인데, 이러한
        156. // 일반화를 시도한다면, 반환 타입도 일반화할
        157. // 필요가 있다.
        158.  
        159. // 즉, std::size_t를 돌려주는 것이 아니라
        160. // enum의 바탕 타입을 돌려주어야 한다.
        161.  
        162. // 이 부분은 std::underlying_type 타입 특성을
        163. // 사용하면 된다(타입 특성에 관해서는 항목 9를
        164. // 보라).
        165.  
        166. // 마지막으로, 그 함수는 noexcept(항목 14 참고)
        167. // 로 선언해야 한다. 결코 예외를 던지지 않을
        168. // 것을 알고 있기 때문이다.
        169.  
        170. // 다음은 이상의 사항들을 모두 고려해서 만든,
        171. // 임의의 열거자 하나를 받아서 그 값을 컴파일
        172. // 시점 상수로서 돌려주는 함수 템플릿 toUType이다.
        173.  
        174. template <typename E>
        175. constexpr typename std::underlying_type<E>::type
        176. toUType(E enumerator) noexcept
        177. {
        178. return
        179. static_cast<typename
        180. std::underlying_type<E>::type>(enumerator);
        181. }
        182.  
        183. // c++14에서는 typename std::underlying_type<E>::type을
        184. // 깔끔한 std::underlying_type_t(항목 9 참고)로
        185. // 대체해서 toUType을 더욱 단순화할 수 있다.
        186.  
        187. template <typename E> // C++14
        188. constexpr std::underlying_type_t<E>
        189. toUType(E enumerator) noexcept
        190. {
        191. return static_cast<std::underlying_type_t<E> >(enumerator);
        192. }
        193.  
        194. // C++14가 지원하는 auto 반환 타입(항목 3 참고)
        195. // 을 적용하면 더욱 깔끔해진다.
        196.  
        197. template <typename E> // C++14
        198. constexpr auto
        199. toUType(E enumerator) noexcept
        200. {
        201. return static_cast<std::underlying_type_t<E> >(enumerator);
        202. }
        203.  
        204. // 어떤 형태로 구현했든, toUType을 이용하면
        205. // 튜플의 한 필드에 다음과 같이 접근할
        206. // 수 있다.
        207.  
        208. auto val = std::get<toUType(UserInfoFields::uiEmail)>(uInfo);
        209.  
        210. // 범위 없는 enum을 사용할 때보다는 여전히
        211. // 타자량이 많지만, 그래도 이름공간 오염을
        212. // 피하고 열거자들과 관련된 의도치 않은
        213. // 변환이 방지된다는 장점이 있다.
        214.  
        215. // 글자 몇 개를 더 타자해야 한다고 해도,
        216. // 구세대 기술의 함정들을 피하는 것이 더
        217. // 이득인 경우가 많다.

        
        
        예제 코드 접기
        
        
        

      • 범위 있는 enum과 범위 없는 enum 모두 바탕 타입 지정을 지원한다. 범위 있는 enum의 기본 바탕 타입은 int이다. 범위 없는 enum에는 기본 바탕 타입이 없다.

        예제 코드 보기
        
        
        

        1. // 범위 있는 enum의 바탕 타입은
        2. // 기본적으로 int이다.
        3.  
        4. enum class Status; // 바탕 타입은 int
        5.  
        6. // 그 기본 타입이 마음에 들지 않는다면
        7. // 다른 타입을 명시적으로 지정하면 된다.
        8.  
        9. enum class Status: std::uint32_t; // Status의 바탕 타입은
        10. // std::uint32_t
        11. // (<cstdint>에 있음)
        12.  
        13. // 범위 없는 enum의 바탕 타입을 지정하는
        14. // 방법은 범위 있는 enum에 대한 것과
        15. // 동일하다.
        16.  
        17. // 그리고 바탕 타입이 지정된 범위 없는
        18. // enum은 전방 선언을 지원한다.
        19.  
        20. enum Color: std::uint8_t; // 범위 없는 enum의 전방 선언
        21. // 바탕 타입은 std::uint8_t
        22.  
        23. // enum을 '정의'할 때에도 바탕 타입을
        24. // 지정할 수 있다.
        25.  
        26. enum class Status: std::uint32_t {
        27. good = 0,
        28. failed = 1,
        29. incomplete = 100,
        30. corrupt = 200,
        31. audited = 500,
        32. indeterminate = 0xFFFFFFFF
        33. };

        
        
        예제 코드 접기
        
        
        

      • 범위 있는 enum은 항상 전방 선언이 가능하다. 범위 없는 enum은 해당 선언에 바탕 타입을 지정하는 경우에만 전방 선언이 가능하다.

        메모리를 효율적으로 활용하기 위해, 컴파일러들은 주어진 enum의 열거자 값들의 범위를 표현할 수 있는 가장 작은 바탕 타입을 선택하는 경향이 있다.
        
        그러나 경우에 따라서는 컴파일러가 크기 대신 속도를 위한 최적화를 적용하며, 그런 경우에는 허용되는 가장 작은 바탕 타입을 선택하지 않을 수도 있다. 그렇다고 해도, 컴파일러는 크기를 위해 최적화를 적용할 수 있길 원한다.
        
        이를 가능하게 하기 위해, C++98은 오직 enum 정의(모든 열거자가 나열된)만 지원하고 enum 선언은 허용하지 않는다. 그러면 enum이 실제로 쓰이기 전에 컴파일러가 enum의 바탕 타입을 선택할 수 있기 때문이다.
        
        그러나 enum을 전방 선언할 수 없으면 몇 가지 단점이 생기는데, 가장 주목할 만한 것은 아마 컴파일 의존 관계가 늘어난다는 점일 것이다.
        
        그래서, 범위 없는 enum은 바탕 타입을 명시적으로 지정해 주는 경우에 한해 전방 선언을 할 수 있다.
        
        enum Color: std::uint8_t;
        // 범위 없는 enum의 전방 선언
        // 바탕 타입은 std::uint8_t
        
        enum Color;
        // 오류! 바탕 타입 지정 없이
        // 전방 선언 불가능
        
        하지만, 범위 있는 enum의 경우 기본 바탕 타입이 int라고 못박아 두었기 때문에 항상 전방 선언이 가능하다.
        
        enum class Status: std::uint32_t;
        // Status의 바탕 타입은
        // std::uint32_t
        
        enum class Color;
        // OK Color의 바탕 타입은
        // 기본 바탕 타입인 int
        
        

  11. 정의되지 않은 비공개 함수보다 삭제된 함수를 선호하라 / 79

      • 정의되지 않은 비공개 함수보다 삭제된 함수를 선호하라.

        C++98에서는 어떤 함수의 사용을 막고 싶으면, 그 함수를 private로 선언하고 함수의 정의를 만들지 않는 방법을 사용하였다.
        
        C++11에서는 같은 목적을 달성하는 더 나은 방법이 있다. 바로 사용을 막을 함수 선언의 끝에 "= delete"를 붙이는 것이다. = delete를 붙인 함수를 삭제된 함수(deleted function)라고 부른다.
        
        사용을 막아둔 함수를 사용하려고 했을 경우, C++98은 링크 시점에 가서야 발견되지만, C++11의 삭제된 함수는 컴파일 시점에 발견될 수 있다.
        
        C++11의 삭제된 함수는 private이 아니라 public으로 선언하는 것이 관례이다. 여기에는 이유가 있다.
        
        클라이언트 코드가 멤버 함수를 사용하려 할 때, C++은 먼저 그 함수의 접근성을 점검한 후에야 삭제 여부를 점검한다. 그런데 private 함수를 사용하는 클라이언트 코드에 대해 그 함수가 private이라는 점을 문제 삼는 컴파일러들이 있다.
        
        사실 함수를 사용할 수 없는 주된 이유가 함수의 접근성 때문이 아니라는 점에서, 이는 오해의 여지를 제공한다. 삭제된 함수를 private로 선언하는 것 보다 public으로 선언했을 때, 대체로 더 나은 오류 메시지가 나온다는 점을 명심하기 바란다.
        
        예제 코드 보기
        
        
        

        1. // 다음은 C++11 표준에 명시된 basic_ios의
        2. // 일부분(삭제된 함수가 사용된)이다.
        3.  
        4. template <class charT, class traits = char_traits<charT> >
        5. class basic_ios : public ios_base {
        6. public:
        7. ...
        8. basic_ios(const basic_ios&) = delete;
        9. basic_ios& operator=(const basic_ios&) = delete;
        10. ...
        11. }
        12.  
        13. // 입출력 스트림 객체의 복사는 명확히 정의되지
        14. // 않음으로 아예 금지하는것이 좋다.
        15.  
        16. // 이를 위해 복사 생성자와 복사 대입 연산자의
        17. // 끝에 "= delete"를 붙여 삭제된 함수로 만들었다.
        18.  
        19. // 삭제된 함수가 public으로 선언됨에 주의하자.

        
        
        예제 코드 접기
        
        
        

      • 비멤버 함수와 템플릿 인스턴스를 비롯한 그 어떤 함수도 삭제할 수 있다.

        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // C에서 물려받은 유산 때문에, 수치로 간주될
        3. // 여지가 조금이라도 있는 타입은 암묵적으로
        4. // int로 변환된다.
        5.  
        6. // 그래서 다음 예처럼 별로 논리적이지도 않은
        7. // 코드들이 무사히 컴파일된다.
        8.  
        9. bool isLucky(int number); // 정수 값을 하나 받고
        10. // 그 값이 행운의 번호인지의
        11. // 여부를 돌려주는 비멤버 함수
        12.  
        13. if (isLucky('a')) ... // 'a'가 행운의 번호인가?
        14.  
        15. if (isLucky(true)) ... // true는 어떤가?
        16.  
        17. if (isLucky(3.5)) ... // 먼저 소수부를 버려서 3을 만든 후
        18. // 행운을 시험해야 할까?
        19.  
        20. // 행운의 번호가 반드시 정수이어야 한다면,
        21. // 위의 호출들이 아예 컴파일되지 않게
        22. // 만드는 것이 바람직하다.
        23.  
        24. // 이를 달성하는 한 가지 방법은, 배제할
        25. // 타입들에 대해 오버로딩된 함수들을 명시적으로
        26. // 삭제하는 것이다.
        27.  
        28. bool isLucky(int number); // 원래의 함수
        29.  
        30. bool isLucky(char) = delete; // char을 배제
        31.  
        32. bool isLucky(bool) = delete; // bool을 배제
        33.  
        34. bool isLucky(double) = delete; // double과 float를 배제
        35.  
        36. // 주석에서 보듯이, double을 받는 오버로딩된 함수를 삭제하면
        37. // double과 float이 모두 배제된다.
        38.  
        39. // 이는 float가 int와 double 모두로 변환될 수 있는
        40. // 상황에서는 double로 변환되기 때문이다.
        41.  
        42. // 삭제된 함수들은 비록 사용할 수는 없지만,
        43. // 그래도 프로그램의 일부이다.
        44.  
        45. // 따라서 이들도 오버로딩 해소 과정에서
        46. // 후보로 간주된다.
        47.  
        48. if (isLucky('a')) ... // 오류! 삭제된 함수를 호출하려 함
        49.  
        50. if (isLucky(true)) ... // 오류!
        51.  
        52. if (isLucky(3.5f)) ... // 오류!
        53.  
        54.  
        55. //-----------------------------------------------------------------------------
        56. // 삭제된 함수로만 수행할 수 있는 또 다른
        57. // 요령은 원치 않는 템플릿 인스턴스화를
        58. // 방지하는 것이다.
        59.  
        60. // 예를 들어 내장 포인터들을 다루는 다음과
        61. // 같은 템플릿이 있다고 하자.
        62.  
        63. template <typename T>
        64. void processPointer(T* ptr);
        65.  
        66. // 이 중에서 void* 타입이나 char*타입의 포인터로는
        67. // processPointer를 호출하지 못하게 하고 싶다고
        68. // 하자.
        69.  
        70. // 이를 달성하는 것은 쉬운 일이다. 그냥
        71. // 해당 템플릿 인스턴스들을 삭제하면 된다.
        72.  
        73. template <>
        74. void processPointer<void>(void*) = delete;
        75.  
        76. template <>
        77. void processPointer<char>(char*) = delete;
        78.  
        79. // 이제 void*나 char*로 processPointer를
        80. // 호출하는 것은 유효하지 않다.
        81.  
        82. // 일반적으로, void*나 char*가 안 된다면
        83. // const void*나 const char*도 안 되어야 마땅하다.
        84.  
        85. // 따라서 해당 인스턴스들도 삭제할
        86. // 필요가 있다.
        87.  
        88. template <>
        89. void processPointer<const void>(const void*) = delete;
        90.  
        91. template <>
        92. void processPointer<const char>(const char*) = delete;
        93.  
        94. // 더욱 철저하게 하고 싶다면 const volatile void*
        95. // 오버로딩 버전과 const volatile char* 버전,
        96. // 그리고 다른 표준 문자 타입들인 wchar_t, char16_t,
        97. // char32_t의 포인터들에 대한 버전들도 삭제해야
        98. // 할 것이다.
        99.  
        100. // 클래스 안의 함수 템플릿의 일부 인스턴스화를
        101. // 방지하려는 목적으로 private 선언 접근방식은
        102. // 적용할 수 없다.
        103.  
        104. // 멤버 함수 템플릿의 한 특수화의 접근 수준을
        105. // 그 템플릿 자체의 것과는 다른 수준으로 지정하는
        106. // 것은 불가능하기 때문이다.
        107.  
        108. // 예를 들어 processPointer가 Widget 클래스의
        109. // 한 멤버 함수 템플릿이고, void* 포인터로
        110. // 그 템플릿을 호출하지 못하게 한다고 할 때,
        111. // 다음과 같은 C++98 접근방식은 컴파일되지
        112. // 않는다.
        113.  
        114. class Widget {
        115. public:
        116. ...
        117. template <typename T>
        118. void processPointer(T* ptr)
        119. { ... }
        121. private:
        122. template <> // 오류!
        123. void processPointer<void>(void*);
        124. };
        125.  
        126. // 이것이 불가능한 이유는, 템플릿 특수화는 반드시
        127. // 클래스 범위가 아니라 이름공간 범위에서 작성해야
        128. // 한다는 것이다.
        129.  
        130. // 삭제된 함수에는 다른 접근 수준을 지정할 필요가
        131. // 없으므로 이런 문제가 없다.
        132.  
        133. // 멤버 함수를 클래스 바깥에서 삭제하는 것이
        134. // 가능하다.
        135.  
        136. class Widget {
        137. public:
        138. ...
        139. template <typename T>
        140. void processPointer(T* ptr);
        141. { ... }
        142. ...
        143. };
        144.  
        145. template <> // 여전히
        146. void Widget::processPointer<void>(void*) = delete; // public,
        147. // 그러나
        148. // 삭제되었음
        149.  

        
        
        예제 코드 접기
        
        
        

  12. 재정의 함수들을 override로 선언하라 / 84

      • 재정의 함수는 override로 선언하라.

        재정의가 일어나려면 다음과 같은 여러 필수조건을 만족해야 한다.
        
        
        • 기반 클래스 함수가 반드시 가상 함수이어야 한다.
        • 기반 함수와 파생 함수의 이름이 반드시 동일해야 한다(단, 소멸자는 제외).
        • 기반 함수와 파생 함수의 매개변수 타입들이 반드시 동일해야 한다.
        • 기반 함수와 파생 함수의 const성이 반드시 동일해야 한다.
        • 기반 함수와 파생 함수의 반환 타입과 예외 지정(exception specification)이 반드시 호환되어야 한다.
        • [C++11에서 추가된 조건] 멤버 함수들의 참조 한정사(reference qualifier)들이 반드시 동일해야 한다. 참조 한정사가 붙은 멤버 함수에 관해서는 나중에 좀 더 이야기할 것이다.
        
        
        이러한 모든 재정의 요구조건들이 뜻하는 것은, 작은 실수가 큰 차이를 빚을 수 있다는 것이다.
        
        재정의 실수가 포함된 코드는 프로그래머가 의도한 것과는 다르게 행동하기 마련이지만, 그래도 여전히 유효한(컴파일 오류가 아닌) 경우가 많다.
        
        그래서 C++11은 파생 클래스 함수가 기반 클래스의 버전을 재정의하려 한다는 의도를 명시적으로 표현하는 방법을 제공한다. 바로, 그런 파생 클래스 함수를 override로 선언하는 것이다.
        
        파생 함수를 override로 선언하면, 컴파일러는 재정의 관련 문제점들을 모두 지적해준다.
        
        override 예제 코드 보기
        
        
        

        1. // 재정의 함수를 override로 선언하지 않으면
        2. // 다음과 같은 재정의 실수를 해도 문제
        3. // 없이 컴파일 되는 경우가 많다.
        4.  
        5. class Base {
        6. public:
        7. virtual void mf1(void) const;
        8. virtual void mf2(int x);
        9. virtual void mf3(void) &;
        10. void mf4(void) const;
        11. };
        12.  
        13. class Derived: public Base {
        14. public:
        15. virtual void mf1(void);
        16. virtual void mf2(unsigned int x);
        17. virtual void mf3(void) &&;
        18. void mf4(void) const;
        19. };
        20.  
        21. // 다음은 위의 코드에서 발견된
        22. // 네 가지 재정의 실수들이다.
        23.  
        24. // 1. Base에서는 mf1이 const로 선언되었지만,
        25. // Derived에서는 그렇지 않다.
        26.  
        27. // 2. Base에서는 mf2가 int를 받지만,
        28. // Derived에서는 unsigned int를 받는다.
        29.  
        30. // 3. Base에서는 mf3이 좌측값으로 한정되지만,
        31. // Derived에서는 우측값으로 한정된다.
        32.  
        33. // 4. Base에서 mf4는 virtual로 선언되지 않았다.
        34.  
        35. // 이런 실수들이 있음에도 불구하고, 컴파일러는
        36. // 불만 없이 이 코드들을 컴파일 하는 경우가 많다.
        37.  
        38. // 문법적으로 문제가 없기 때문이며, 이런 경우,
        39. // 재정의가 일어나지 않는다. 그냥 Base 클래스의
        40. // 멤버 함수들이 가려질 뿐이다.
        41.  
        42. // 컴파일러로부터 이러한 재정의 실수들을
        43. // 지적받고 싶다면 재정의 함수들을
        44. // override로 선언해야 한다.
        45.  
        46. class Derived: public Base {
        47. public:
        48. virtual void mf1(void) override;
        49. virtual void mf2(unsigned int x) override;
        50. virtual void mf3(void) && override;
        51. virtual void mf4(void) const override;
        52. };
        53.  
        54. // 이제 이 코드는 컴파일되지 않는다.
        55.  
        56. // 다음은 override를 사용하는, 그리고
        57. // 제대로 컴파일되는 코드이다.
        58.  
        59. class Base {
        60. public:
        61. virtual void mf1(void) const;
        62. virtual void mf2(int x);
        63. virtual void mf3(void) &;
        64. virtual void mf4(void) const;
        65. };
        66.  
        67. class Derived: public Base {
        68. public:
        69. virtual void mf1(void) const override;
        70. virtual void mf2(int x) override;
        71. virtual void mf3(void) & override;
        72. void mf4(void) const override; // virtual을 붙여도 되지만,
        73. }; // 꼭 그럴 필요는 없다.
        74.  
        75. // Base의 mf4를 가상 함수로 선언하는 것도
        76. // 코드가 제대로 컴파일되게 하는 데
        77. // 필요한 일임을 주목하기 바란다.
        78.  
        79. // 재정의 관련 오류는 대부분 파생 클래스에서
        80. // 일어나지만, 기반 클래스에서 뭔가 잘못되었을
        81. // 가능성도 있다.

        
        
        override 예제 코드 접기
        
        
        파생 클래스를 override로 선언한다는 방침은, 재정의를 의도한 함수가 실제로는 아무것도 재정의하지 않는다는 점을 컴파일러가 지적해 주는 것 이상의 장점을 제공한다.
        
        그러한 방침은 기반 클래스의 한 가상 함수의 시그니처를 변경했을 때 그 영향이 어느 정도인지 가늠하려 할 때에도 도움이 된다.
        
        파생 클래스들에서 override를 일관되게 적용했다면, 그냥 기반 함수의 시그니처를 변경하고, 시스템을 다시 컴파일하고, 컴파일에 실패한 파생 클래스가 몇 개나 되는지 파악하고, 그에 따라 해당 시그니처를 그렇게 변경하는 것이 가치가 있는 일인지 판단하면 된다.
        
        그러나 override를 사용하지 않았다면, 상세한 단위 테스트(unit test)들을 마련해 두길 잘했다는 생각이 들(또는 그렇지 않았음을 후회할) 것이다.
        
        왜냐하면, 앞에서 보았듯이 기반 클래스의 함수들을 재정의하려 했지만 실제로는 그렇지 않은 파생 클래스 가상 함수들에 대해 컴파일러가 아무런 경고도 하지 않기 때문이다.
        
        참고로 C++11에는 두 개의 문맥 의존 키워드(contextual keyword) override, final가 추가되었다. 이 키워드들은 오직 특정한 문맥에서만 예약어로 작용하는 특성이 있어서, override나 final이라는 이름을 사용하는 구식 코드가 남아 있다고 해도, C++11을 위해 그 이름을 변경할 필요는 없다.

      • 멤버 함수 참조 한정사를 이용하면 멤버 함수가 호출되는 객체(*this)의 좌측값 버전과 우측값 버전을 다른 방식으로 처리할 수 있다.

        멤버 함수 참조 한정사 예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 멤버 함수 참조 한정사를 사용하면 멤버 함수를
        3. // 좌측값에만 또는 우측값에만 사용할 수 있게
        4. // 제한할 수 있다.
        5.  
        6. // 가상 함수가 아닌 멤버 함수에도 멤버 함수
        7. // 참조 한정사를 적용할 수 있다.
        8.  
        9. class Widget {
        10. public:
        11. ...
        12. void doWork(void) &; // doWork의 이 버전은 *this가 좌측값일
        13. // 때에만 적용된다.
        15. void doWork(void) &&; // doWork의 이 버전은 *this가 우측값일
        16. }; // 때에만 적용된다.
        17.  
        18. ...
        19.  
        20. Widget makeWidget(void); // 팩터리 함수(우측값을 돌려줌)
        21.  
        22. Widget w; // 보통 객체(좌측값을 돌려줌)
        23.  
        24. ...
        25.  
        26. w.doWork(); // 좌측값용 Widget::doWork(즉,
        27. // Widget::doWork &)를 호출한다.
        28.  
        29. makeWidget().doWork(); // 우측값용 Widget::doWork(즉,
        30. // Widget::doWork &&)를 호출한다.
        31.  
        32.  
        33. //-----------------------------------------------------------------------------
        34. // 좌측값 인수만 받는 함수를 작성하고 싶다면,
        35. // 비 const 좌측값 참조 매개변수를 선언하면
        36. // 된다.
        37.  
        38. void doSomething(Widget& w); // 좌측값 Widget만 받는 함수
        39.  
        40. // 우측값 인수만 받는 함수를 작성하고 싶다면,
        41. // 우측값 참조 매개변수를 선언하면 된다.
        42.  
        43. void doSomething(Widget&& w); // 우측값 Widget만 받는 함수
        44.  
        45. // 멤버 함수 참조 한정사는 멤버 함수가
        46. // 호출되는 객체, 즉 *this에 대해 이러한
        47. // 구분이 가능하게 만드는 것일 뿐이다.
        48.  
        49. // 멤버 함수 참조 한정사는 주어진 멤버
        50. // 함수가 호출되는 대상(*this)이 const임을
        51. // 명시하기 위해 멤버 함수 선언 끝에
        52. // 붙이는 const와 딱 비슷하다.
        53.  
        54.  
        55. //-----------------------------------------------------------------------------
        56. // 이런 문법이 필요한 예를 보자.
        57.  
        58. // 예를 들어 Widget 클래스에 std::vector
        59. // 데이터 멤버가 있으며, 그것에 직접
        60. // 접근할 수 있는 접근용 멤버 함수를
        61. // 클라이언트에게 제공한다고 하자.
        62.  
        63. class Widget {
        64. public:
        65. using DataType = std::vector<double>; // using에 관해서는
        66. ... // 항목 9를 보라
        68. DataType& data(void) { return values; }
        69. ...
        71. private:
        72. DataType values;
        73. };
        74.  
        75. // 이 클래스의 설계가 아주 잘 캡슐화되어
        76. // 있다고는 할 수 없겠지만, 그 점은 제쳐
        77. // 놓고 다음과 같은 클라이언트 코드에서
        78. // 어떤 일이 일어나는지 생각해 보자.
        79.  
        80. Widget w;
        81. ...
        82.  
        83. auto vals1 = w.data(); // w.values를 vals1에 복사
        84.  
        85. // Widget::data의 반환 타입은 좌측값 참조이고
        86. // 좌측값 참조는 정의상 좌측값으로 취급되므로,
        87. // 이 코드는 하나의 좌측값으로 vals1을
        88. // 초기화한다.
        89.  
        90. // 따라서, 주석에도 나와 있듯이 vals1은 w.values
        91. // 로부터 복사 생성된다.
        92.  
        93. // 다음으로, Widget을 생성하는 팩터리 함수가
        94. // 있다고 하자.
        95.  
        96. Widget makeWidget(void);
        97.  
        98. // 그리고 이 makeWidget이 돌려준 Widget 객체 안의
        99. // std::vector를 이용해서 변수를 초기화한다고 하자.
        100.  
        101. auto vals2 = makeWidget(void).data(); // Widget 안에 있는
        102. // values를 vals2에 복사
        103.  
        104. // 이번에도 Widget::data는 좌측값 참조를 돌려주며,
        105. // 마찬가지로 vals2는 Widget안의 values로부터
        106. // 복사 생성된다.
        107.  
        108. // 그러나 이번에는 Widget이 makeWidget이 돌려준
        109. // 임시 객체(즉, 우측값)이다.
        110.  
        111. // 따라서 그 임시 객체 안의 std::vector를
        112. // 복사하는 것은 시간 낭비이다.
        113.  
        114. // 이를 해소하기 위해 정말로 필요한 것은
        115. // data가 우측값 Widget에 대해 호출된
        116. // 경우에는 반드시 우측값을 돌려주게 하는
        117. // 것이다.
        118.  
        119. // data를 좌측값 Widget과 우측값 Widget에 대해
        120. // 개별적으로 오버로딩하면 그런 일이 가능하다.
        121.  
        122. class Widget {
        123. public:
        124. using DataType = std::vector<double>;
        125. ...
        127. DataType& data(void) & // 좌측값 Widget에 대해서는
        128. { return values; } // 좌측값을 반환
        130. DataType&& data(void) && // 우측값 Widget에 대해서는
        131. { return std::move(values); } // 우측값을 반환
        132. ...
        134. private:
        135. DataType values;
        136. };
        137.  
        138. // 이제 클라이언트 코드는 우리가 원했던
        139. // 방식으로 작동한다.
        140.  
        141. auto vals1 = w.data(); // Widget::data의 좌측값
        142. // 오버로딩된 함수를 호출; vals1은
        143. // 복사 생성됨
        144.  
        145. auto vals2 = makeWidget().data(); // Widget::data의 우측값
        146. // 오버로딩된 함수를 호출; vals2는
        147. // 이동 생성됨
        148.  

        
        
        멤버 함수 참조 한정사 예제 코드 접기
        
        
        

  13. iterator보다 const_iterator를 선호하라 / 91

      • iterator보다 const_iterator를 선호하라.

        가능한 한 항상 const를 사용하는 것이 좋다. 하지만 프로그래머들은 가능한 한 항상 const를 사용하지 않는다. 실용적일 때에만 항상 사용할 뿐이다. 그리고 C++98에서 const_iterator는 그리 실용적이지 않았다.
        
        왜냐하면, C++98에서는 비상수 컨테이너로부터 const_iterator를 얻는 방법도 까다로웠고, 삽입(그리고 삭제) 위치를 iterator로만 지정할 수 있었기 때문이다(이에 관한 자세한 내용은 Effective STL의 항목 26에서 찾을 수 있다).
        
        하지만 C++11에서는 C++98에서의 문제점들이 개선되었다. 따라서 C++11 환경에서 프로그래밍을 한다면 가능한 한 iterator보다 const_iterator를 사용하는 것이 좋다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 예를 들어 std::vector<int>에서 1983이라는 값이
        3. // 처음 나오는 지점을 찾고 그 곳에 1998이라는
        4. // 값을 삽입한다고 하자.
        5.  
        6. // 벡터에 1983이 하나도 없으면 1998을 벡터의
        7. // 끝에 삽입해야 한다.
        8.  
        9. // C++98에서는 iterator를 사용하여
        10. // 간단하게 구현할 수 있다.
        11.  
        12. std::vector<int> values;
        13.  
        14. ...
        15.  
        16. std::vector<int>iterator it =
        17. std::find(values.begin(), values.end(), 1983);
        18.  
        19. values.insert(it, 1998);
        20.  
        21. // 하지만 const_iterator를 사용하면
        22. // 여러가지 문제가 많이 생긴다.
        23.  
        24. typedef std::vector<int>::iterator IterT; // typedef 들
        25. typedef std::vector<int>::const_iterator ConstIterT; // (C++98 코드이므로)
        26.  
        27. std::vector<int> values;
        28.  
        29. ...
        30.  
        31. ConstIterT ci =
        32. std::find(static_cast<ConstIterT>(values.begin()), // 캐스팅
        33. static_cast<ConstIterT>(values.end()), // 캐스팅
        34. 1983);
        35.  
        36. values.insert(static_cast<IterT>(ci), 1998); // 컴파일이 안
        37. // 될 수 있음;
        38.  
        39. // std::find에서 캐스팅을 사용한 이유는
        40. // C++98에서 비상수 컨테이너로부터
        41. // 상수 반복자를 얻을 수 있는 방법이
        42. // 없기 때문이다.
        43.  
        44. // insert에서 다시 비상수 반복자로 캐스팅을
        45. // 한 이유는, 삽입(과 삭제) 함수가
        46. // 오직 iterator만을 받아들이기 때문이다.
        47.  
        48. // 그런데 상수 반복자를 비상수 반복자로
        49. // 이식성을 유지한 채 변환하는 방법 또한
        50. // 존재하지 않는다(이는 C++11도 마찬가지이다).
        51.  
        52. // 즉 캐스팅이 안된다는 말이다.
        53.  
        54. // 이런 불편함 때문에 C++98에서는
        55. // const_iterator를 잘 사용하지 않았다.
        56.  
        57.  
        58. //-----------------------------------------------------------------------------
        59. // 하지만 C++11에서는 비상수 컨테이너로부터
        60. // const_iterator를 얻을 수 있는 멤버 함수가
        61. // 추가되었다.
        62.  
        63. // cbegin과 cend가 그것이다.
        64.  
        65. // 그리고 삽입(과 삭제) 함수가 const_iterator를
        66. // 받아들일 수 있도록 바뀌었다.
        67.  
        68. // 이제 iterator를 사용하는 기존 C++98 코드를
        69. // C++11에서 const_iterator를 사용하도록
        70. // 개정하는 과정은 아주 간단하다.
        71.  
        72. std::vector<int> values; // 이전과 동일
        73.  
        74. ...
        75.  
        76. auto it = // cbegin과
        77. std::find(values.cbegin(), values.cend(), 1983); // cend를 사용
        78.  
        79. values.insert(it, 1998);
        80.  
        81. // 이것이 바로 const_iterator를 사용하는
        82. // 실용적인 코드이다.

        
        
        예제 코드 접기
        
        
        

      • 최대한 일반적인 코드에서는 begin, end, rbegin 등의 비멤버 버전들을 해당 멤버 함수들보다 선호하라.

        일반적인 코드를 작성할때는 begin, end, rbegin등의 멤버 함수를 갖지 않은 컨테이너(이를테면, 배열)도 고려해야 하므로, 이 멤버 함수들의 비멤버 버전을 사용하는 것이 좋다.
        
        예제 코드 보기
        
        
        

        1. // 예를 들어, 다음은 앞에서 본 검색 및 삽입 코드를
        2. // findAndInsert라는 하나의 템플릿으로 일반화한 것이다.
        3.  
        4. template <typename C, typename V>
        5. void findAndInsert라는(C& container, // container에서
        6. const V& targetVal, // targetVal의 첫
        7. const V& insertVal) // 출현을 찾고, 그
        8. // 위치에 insertVal을
        9. { // 삽입한다.
        10. using std::cbegin;
        11. using std::cend;
        13. auto it = std::find(cbegin(container), // 비멤버 cbegin
        14. cend(container), // 비멤버 cend
        15. targetVal);
        17. container.insert(it, insertVal);
        18. }
        19.  
        20. // 이 템플릿은 C++14에서는 잘 작동하지만, 안타깝게도
        21. // C++11에서는 그렇지 않다.
        22.  
        23. // C++11 표준화 과정에서 비멤버 함수 begin과
        24. // end는 표준에 추가했지만, cbegin과 cend,
        25. // rbegin, rend, crbegin, crend는 빼먹고 추가하지 않았기 때문이다.
        26.  
        27. // C++11에서 이런 비멤버 함수들을 사용하고 싶다면,
        28. // 여러분이 직접 구현하는 것도 어렵지 않다.
        29.  
        30. // 다음은 비멤버 cbegin의 한 구현이다.
        31.  
        32. template <class C>
        33. auto cbegin(const C& container)->decltype(std::begin(container))
        34. {
        35. return std::begin(container);
        36. }
        37.  
        38. // 비멤버 cbegin이 멤버 cbegin을 호출하지
        39. // 않는다는 점에 놀랄 수도 있다.
        40.  
        41. // 그러나 이는 논리적이다.
        42.  
        43. // 이 cbegin 템플릿은 컨테이너 같은 자료구조를
        44. // 대표하는 임의의 인수 타입 C를 받고, 해당
        45. // const 참조 매개변수 container를 통해서
        46. // 그 자료구조에 접근한다.
        47.  
        48. // 만일 C가 통상적인 컨테이너 타입이면
        49. // container는 그 컨테이너의 const 버전에
        50. // 대한 참조가 된다.
        51.  
        52. // 그러한 const 컨테이너에 대해 비멤버 begin
        53. // 함수를 호출하면 const_iterator 타입의 반복자가
        54. // 반환된다.
        55.  
        56. // 이런 구현 방식의 장점은, begin 멤버 함수를
        57. // 제공하지만 cbegin 멤버 함수는 제공하지 않는
        58. // 컨테이너에 대해서도 작동한다는 것이다.
        59.  
        60. // 심지어 C가 내장 배열 타입일 때에도 작동한다.
        61. // C++11은 내장 배열에 특화된 버전의 비멤버
        62. // begin을 제공하기 때문이다.

        
        
        예제 코드 접기
        
        
        

  14. 예외를 방출하지 않을 함수는 noexcept로 선언하라 / 95

      • noexcept는 함수의 인터페이스의 일부이다. 이는 호출자가 noexcept 여부에 의존할 수 있음을 뜻한다.

        C++98에서 예외 지정(exception specification)은 다소 변덕스러운 야수였다. 함수 구현이 바뀌면 예외 지정도 바뀔 가능성이 생겼고, 기존의 예외 지정에 의존하던 클라이언트 코드는 깨질 수 있었다.
        
        게다가, 대체로 컴파일러는 함수 구현과 예외 지정, 그리고 클라이언트 코드 사이의 일관성 유지에 아무런 도움도 주지 않았다. 그래서 대부분의 프로그래머는 결국 C++98의 예외 지정이 득보다 실이 크다고 판단하게 되었다.
        
        C++11 제정 과정에서, 함수의 예외 방출 행동에 관해 정말로 의미 있는 정보는 함수가 예외를 하나라도 던질 수 있는지 아니면 절대로 던지지 않는지의 여부라는 점에 대한 공감대가 형성되었다.
        
        본질적으로 C++98의 것을 대체하는 C++11의 예외 지정에는 바로 그러한 흑백논리가 깔려 있다(C++98 스타일의 예외 지정도 여전히 유효하나, 비권장(deprecate) 기능으로 분류되었다).
        
        C++11에서 함수 선언 시 그 함수가 예외를 방출하지 않을 것임을 명시할 때에는 noexcept라는 키워드를 사용하면 된다.
        
        함수를 noexcept로 선언할 것인지의 여부는 인터페이스 설계상의 문제이다. 함수의 예외 방출 행동은 클라이언트에게 아주 중요한 사항이다. 함수의 호출자는 함수의 noexcept 여부를 조회할 수 있으며, 그 조회 결과는 호출 코드의 예외 안정성이나 효율성에 영향을 미친다.
        
        그런 만큼, 함수의 noexcept 여부는 멤버 함수의 const 여부만큼이나 중요한 정보이다.

      • noexcept 함수는 비noexcept 함수보다 최적화의 여지가 크다.

        함수 f를 호출했을 때 호출자가 예외를 받게 되는 일이 결코 없음을 약속하고 싶다고 하자. 이를 표현하는 방법은 두 가지이다.
        
        // f는 예외를 방출하지 않음:
        // C++98 방식
        int f(int x) throw();
        
        // f는 예외를 방출하지 않음:
        // C++11 방식
        int f(int x) noexcept;
        
        실행시점에서 어떤 예외가 f 바깥으로 튀어나오면 f의 예외 지정이 위반된다. C++98에서는 예외 지정이 위반되면 호출 스택이 f를 호출한 지점에 도달할 때까지 풀리며(unwind), 그 지점에서 몇 가지 동작이 취해진 후 프로그램 실행이 종료된다(terminate).
        
        C++11의 예외 지정에서는 실행시점 행동이 약간 다르다. C++11에서는 프로그램 실행이 종료되기 전에 호출 스택이 풀릴 수도 있고 풀리지 않을 수도 있다.
        
        호출 스택이 풀리는 것과 풀릴 수도 있는 것의 차이는 컴파일러의 코드 작성에 놀랄 만큼 큰 영향을 미친다.
        
        noexcept 함수에서 컴파일러의 최적화기(optimizer)는 예외가 함수 바깥으로 전파될 수 있다고 해도 실행시점 스택을 풀기 가능 상태로 유지할 필요가 없다. 또한, 예외가 noexcept 함수를 벗어난다고 해도 noexcept 함수 안의 객체들을 반드시 생성의 반대 순서로 파괴해야 하는 것도 아니다.
        
        그러나 예외 지정이 "throw()"인 함수에는 그러한 최적화 유연성이 없으며, 예외 지정이 아예 없는 함수 역시 마찬가지로 그런 유연성이 없다.

      • noexcept는 이동 연산들과 swap, 메모리 해제 함수들, 그리고 소멸자들에 특히나 유용하다.

        std::vector<Widget>을 사용하는 어떤 코드에서, 종종 Widget들을 push_back을 이용해서 벡터에 추가한다고 하자.
        
        push_back을 하다 보면 메모리가 부족하여 재할당하는 경우가 생긴다. 재할당이 일어날 때 기존의 메모리에서 새로 할당받은 메모리로 각 요소(예에서는 Widget 객체)가 복사된다.
        
        복사되는 경우 push_back은 강력한 예외 안전성을 보장할 수 있다. 복사가 모두 끝난 후 기존의 메모리에 있던 객체들과 기존의 메모리가 해제되므로, 복사 도중에 예외가 발생해도 std::vector의 상태는 변하지 않는다.
        
        하지만 C++11의 이동 연산을 통해 최적화를 하면 push_back은 강력한 예외 안전성을 보장할 수 없게 된다.
        
        기존 메모리에서 n개의 요소를 이동한 후 (n+1)번째 요소를 이동하는 도중에 예외가 발생하면 push_back 연산이 완료되지 못하고 실패한다. 그런데 원래의 std::vector는 이미 수정된 상태이다.
        
        요소 중 n개가 다른 곳으로 이동했는데, 그것들을 원래대로 복원하는 것은 불가능할 수 있다. 객체를 원래의 메모리로 다시 이동하는 연산 자체에서도 예외가 발생할 수 있기 때문이다.
        
        그래서, 이동 연산들이 예외를 방출하지 않음이 확실하지 않은 한 C++11 컴파일러는 push_back 안의 복사 연산들을 소리없이 이동 연산들로 대체하지 않는다. 이동 연산이 예외를 방출하지 않음이 확실한 경우에는 복사를 이동으로 대체해도 안전하다.
        
        std::vector::push_back 외에도, 표준 라이브러리의 여러 함수는 이러한 "가능하면 이동하되 필요하면 복사한다" 전략을 활용한다. 특히 C++98에서 강한 예외 안전성을 보장하는 다른 함수들이 그런 식으로 작동한다.
        
        그런데 이동 연산이 예외를 방출하지 않음을 함수가 어떻게 알아낼 수 있을까? 답은 명백하다. 주어진 연산이 noexcept로 선언되어 있는지를 점검하면 된다.
        
        std::vector::push_back 같은 함수는 std::move_if_noexcept를 호출하는데, 이것은 타입의 이동 생성자의 noexcept 여부에 따라 우측값으로의 조건부 캐스팅을 수행하는, std::move의 한 변형이다(항목 23 참고).
        
        한편 std::move_if_noexcept 자체는 std::is_nothrow_move_constructible을 점검하는데, 이 타입 특성(항목 9 참고)의 값은 컴파일러가 이동 생성자의 noexcept(또는 throw()) 지정 여부를 보고 설정한다.
        
        noexcept가 특히나 바람직한 또 다른 예로 swap 함수들이 있다. swap은 여러 STL 알고리즘 구현에서 핵심 구성요소이며, 복사 대입 연산자들에서도 흔히 쓰인다. 그러럼 여러 곳에서 쓰이기 때문에, noexcept를 통해서 최적화할 가치가 크다.
        
        흥미롭게도, 표준 라이브러리에 있는 swap들의 noexcept 여부는 사용자 정의 swap들의 noexcept 여부에 어느 정도 의존한다.
        
        예제 코드 보기
        
        
        

        1. // 예를 들어 다음은 표준 라이브러리에 있는
        2. // 배열에 대한 swap과 std::pair에 대한
        3. // swap의 선언들이다.
        4.  
        5. template <class T, size_t N>
        6. void swap(T (&a)[N],
        7. T (&b)[N]) noexcept(noexcept(swap(*a, *b)));
        8.  
        9. template <class T1, class T2>
        10. struct pair {
        11. ...
        12. void swap(pair& p) noexcept(noexcept(swap(first, p.first)) &&
        13. noexcept(swap(second, p.second)));
        14. ...
        15. };
        16.  
        17. // 이 함수들은 조건부 noexcept이다.
        18.  
        19. // 즉, 이들이 noexcept인지의 여부는
        20. // noexcept절 안의 표현식들이 noexcept인지에
        21. // 의존한다.
        22.  
        23. // 예를 들어 Widget 배열들에 대한 swap은
        24. // Widget들에 대한 swap이 noexcept일
        25. // 때에만 noexcept인 것이다.
        26.  
        27. // 따라서, Widget 배열들에 대한 swap이
        28. // noexcept인지는 Widget을 위한 swap을
        29. // 작성한 프로그래머가 결정한다.

        
        
        예제 코드 접기
        
        
        noexcept로 선언하는 것이 아주 중요한 일부 함수들은 기본적으로 noexcept로 선언된다. 기본적으로 모든 메모리 해제 함수(operator delete와 operator delete[] 등)와 모든 소멸자는 암묵적으로 noexcept이다.
        
        따라서 그런 함수들은 직접 noexcept로 선언할 필요가 없다(직접 선언해도 해가 되지는 않지만, 관례에서 벗어나는 일이다).
        
        소멸자가 암묵적으로 noexcept로 선언되지 않는 유일한 경우는, 예외 방출 가능성을 명시적으로 밝힌(즉, noexcept(false)로 선언된) 소멸자를 가진 타입의 데이터 멤버가 클래스에 있을 때 뿐이다.
        
        그런 소멸자들은 흔치 않으며, 라이브러리가 사용하는 어떤 객체의 소멸자가 예외를 방출하면, 프로그램의 행동은 정의되지 않는다.

      • 대부분의 함수는 noexcept가 아니라 예외에 중립적이다.

        noexcept는 함수의 인터페이스의 일부이다. 따라서 함수의 구현이 예외를 방출하지 않는다는 성질을 오랫동안 유지할 결심이 선 경우에만 함수를 noexcept로 선언해야 한다.
        
        만일 함수를 noexcept로 선언하고는 나중에 마음을 바꾼다면, 딱히 흡족한 수습 방안이 없다. 함수의 인터페이스가 변경(noexcept를 제거)되면 클라이언트 코드가 깨질 위험이 생긴다.
        
        중요한 것은, 대부분의 함수가 예외에 중립적(exception-neutral)이라는 점이다. 예외 중립적 함수는 스스로 예외를 던지지는 않지만, 예외를 던지는 다른 함수들을 호출할 수는 있다.
        
        다른 함수가 예외를 던지면 예외 중립적 함수는 그 예외를 그대로 통과시킨다. 이처럼 통과하는 예외가 있을 수 있으므로, 예외 중립적 함수는 결코 noexcept가 될 수 없다.
        
        그러나, 예외를 전혀 방출하지 않는 것이 자연스러운 구현인 함수들도 있으며, noexcept로 선언하면 최적화에 큰 도움이 되는 함수들도 많다(특히 이동 연산들과 swap). 어떤 함수가 예외를 방출하지 않는다는 점을 확신할 수 있다면, 당연히 noexcept로 선언해야 한다.
        
        앞에서 어떤 함수들은 noexcept가 자연스러운 구현이라고 말했음을 주목하기 바란다. 함수를 noexcept로 선언하기 위해 함수의 구현을 작위적으로 비트는 것은 마치 꼬리가 개를 흔드는 격이자, 마차를 말 앞에 두는 격이다.
        
        예외를 방출하는 함수를, noexcept로 선언하려고 억지로 고치면 함수의 구현이 복잡해질 뿐만 아니라 호출 지점의 코드도 복잡해질 가능성이 크다.
        
        이런 코드가 유발하는 실행비용이, noexcept를 통해서 가능한 최적화가 주는 성능 향상을 능가할 수 있고, 복잡한 코드는 유지보수하기도 어려워진다.
        
        넓은 계약(wide contract)들을 가진 함수와 좁은 계약(narrow contract)들을 가진 함수를 구분하는 사람들은 넓은 계약을 가진 함수들에 대해서만 noexcept를 사용하는 경향이 있다.
        
        넓은 계약을 가진 함수는 전제조건이 없는 함수를 말한다. 그런 함수는 프로그램의 상태와 무관하게 호출할 수 있으며, 호출자가 전달하는 인수들에 그 어떤 제약도 가하지 않는다. 넓은 계약 함수는 켤코 미정의 행동을 보이지 않는다.
        
        넓은 계약을 가진 함수가 아닌 함수들은 모두 좁은 계약을 가진 함수이다. 그런 함수의 경우 함수의 전제조건이 위반되면 그 결과는 미정의 행동이다.
        
        넓은 계약을 가진 함수를 작성하는 경우, 만일 그 함수가 예외를 던지지 않음을 알고 있다면 이 항목의 조언을 따라 함수를 noexcept로 선언하는 것은 쉬운 일이다.
        
        좁은 계약을 가진 함수는 함수 내에서 전제조건을 위반하였음을 알리는 예외를 던질 가능성이 있다. 던져진 예외를 디버깅하는 것이 미정의 행동의 원인을 추적하는 것보다 더 쉽기 때문이다.
        
        이런 이유로, 넓은 계약과 좁은 계약을 구분하는 라이브러리 설계자들은 넓은 계약을 가진 함수들에 대해서만 noexcept를 사용하는 경향이 있다.
        
        마지막 요점으로, C++11에서도 함수 구현과 예외 지정 사이의 비일관성을 파악하는 데 컴파일러가 별 도움을 주지 않는다.
        
        예제 코드 보기
        
        
        

        1. // 다음의 코드는 완벽히 적법한 코드이다.
        2.  
        3. void setup(void); // 다른 어딘가에 정의된 함수들
        4. void cleanup(void);
        5.  
        6. void doWork(void) noexcept
        7. {
        8. setup(); // 필요한 준비 작업을 수행
        10. ... // 실제 작업을 수행
        12. cleanup(); // 정리 작업을 수행
        13. }
        14.  
        15. // 여기서 doWork는 비noexcept 함수
        16. // setup과 cleanup을 호출함에도
        17. // noexcept로 선언되어 있다.
        18.  
        19. // 이는 모순된 일로 보이지만, 어쩌면
        20. // 그냥 문서화의 문제일 수도 있다.
        21.  
        22. // 즉, setup과 cleanup이 비록 noexcept로
        23. // 선언되어 있지는 않지만, 실제로는
        24. // 예외를 절대로 던지지 않을 수도 있다.
        25.  
        26. // 이들을 noexcept로 선언하지 않은 데에는
        27. // 나름의 이유가 있을 것이다.
        28.  
        29. // 이를테면, C로 작성된 라이브러리의 일부일
        30. // 수도 있다.
        31.  
        32. // 아니면, C++98의 예외 지정을 사용하지
        33. // 않기로 결정한, 그리고 C++11에 맞게
        34. // 갱신되지 는 않은 어떤 C++98 라이브러리의
        35. // 일부일 수도 있다.
        36.  
        37. // 이처럼 noexcept 함수가 적법한 이유로
        38. // noexcept 보장이 없는 코드에 의존하는
        39. // 경우가 있으므로, C++은 이런 코드를
        40. // 허용하며, 일반적으로 컴파일러는 이에
        41. // 대해 경고 메시지를 표시하지 않는다.

        
        
        예제 코드 접기
        
        
        

  15. 가능하면 항상 constexpr을 사용하라 / 104

      • constexpr 객체는 const이며, 컴파일 도중에 알려지는 값들로 초기화된다.

        컴파일 시점에 알려지는 값들에는 특별한 권한이 있다. 예를 들어 그런 값들을 읽기 전용 메모리에 배치될 수 있다.
        
        좀 더 광범위한 프로그래머들에게 중요한 점은, 상수이자 컴파일 시점에 알려진 정수 값을 C++에서 정수 상수 표현식(integral constant expression)이 요구되는 문맥에서 사용할 수 있다는 것이다.
        
        배열 크기나 정수 템플릿 인수, 열거자 값, 정합(alignment) 지정자를 지정하는 등의 여러 문맥이 그런 문맥에 해당한다.
        
        constexpr 객체 예제 코드 보기
        
        
        

        1. int sz; // 비constexpr 변수
        2.  
        3. ...
        4.  
        5. constexpr auto arraySize1 = sz; // 오류! sz의 값이 컴파일
        6. // 도중에 알려지지 않음
        7.  
        8. std::array<int, sz> data1; // 오류! 같은 문제
        9.  
        10. constexpr auto arraySize2 = 10; // OK, 10은 확실히
        11. // 컴파일 시점 상수
        12.  
        13. std::array<int, arraySize2> data2; // OK, arraySize2는
        14. // constexpr 객체
        15.  
        16. // const가 constexpr에서와 동일한 보장을
        17. // 제공하지는 않음을 주목하기 바란다.
        18.  
        19. // const 객체가 반드시 컴파일 시점에서
        20. // 알려지는 값으로 초기화되지는 않기
        21. // 때문이다.
        22.  
        23. int sz; // 이전과 동일
        24.  
        25. ...
        26.  
        27. const auto arraySize = sz; // OK, arraySize는
        28. // sz의 const 복사본
        29.  
        30. std::array<int, arraySize> data; // 오류! arraySize의 값은
        31. // 컴파일 시점에서 알려지지 않음
        32.  
        33. // 간단히 말해서, 모든 constexpr 객체는
        34. // const이지만 모든 const 객체가
        35. // constexpr인 것은 아니다.

        
        
        constexpr 객체 예제 코드 접기
        
        
        

      • constexpr 함수는 그 값이 컴파일 도중에 알려지는 인수들로 호출하는 경우에는 컴파일 시점 결과를 산출한다.

        constexpr 함수는 컴파일 시점 상수를 인수로 해서 호출된 경우에는 컴파일 시점 상수를 산출한다.
        
        실행시점이 되어서야 알려지는 값으로 호출하면 실행시점 값을 산출한다.
        
        
        • 컴파일 시점 상수를 요구하는 문맥에 constexpr 함수를 사용할 수 있다. 그런 문맥에서, 만일 constexpr 함수에 넘겨주는 인수의 값이 컴파일 시점에서 알려진다면, 함수의 결과는 컴파일 도중에 계산된다. 인수의 값이 컴파일 시점에서 알려지지 않는다면, 코드의 컴파일이 거부된다.
        • 컴파일 시점에서 알려지지 않는 하나 이상의 값들로 constexpr 함수를 호출하면 함수는 보통의 함수처럼 작동한다. 즉, 그 결과는 실행시점에서 계산된다. 이는 같은 연산을 수행하는 함수를 두 버전, 즉 컴파일 시점 상수를 위한 버전과 다른 모든 값을 위한 버전으로 나누어 구현할 필요가 없음을 뜻한다. 그냥 하나의 constexpr 함수를 두 가지 용도로 사용하면 된다.
        
        
        constexpr 함수를 작성하는데 제약이 있는데, C++11과 C++14의 제약들이 조금 다르다.
        
        C++11의 경우 실행 가능한 문장이 많아야 하나(1개 혹은 0개)이어야 하고 보통의 경우 그 문장은 return문일 수밖에 없다. 그리고, constexpr 멤버 함수는 암묵적으로 const로 선언되며, C++11에서 void는 리터럴 타입이 아니라서 반환 타입이 void가 될 수 없다.
        
        constexpr 함수는 반드시 리터럴 타입(literal type)들을 받고 돌려주어야 한다. C++11에서 void를 제외한 모든 내장 타입이 리터럴 타입에 해당한다. 그리고 생성자와 적절한 멤버 함수들이 constexpr인 사용자 정의 타입도 리터럴 타입이 될 수 있다.
        
        C++14에서는 constexpr 함수가 리터럴 타입이 아닌 타입도 돌려줄 수 있게 되었고, constexpr 함수의 return 문이 많아야 하나이어야 한다는 제약도 사라졌다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 컴파일 도중에 3ⁿ의 크기를 갖는 array를
        3. // 만드려면 어떻게 해야 할까?
        4.  
        5. // 수학적 기능성을 제공하는 C++ 표준 라이브러리
        6. // 함수로는 std::pow가 있지만, 두 가지 문제점
        7. // 때문에 이것을 그대로 사용할 수 없다.
        8.  
        9. // 첫째로, std::pow는 부동소수점 타입에 대해
        10. // 작동하지만 지금 필요한 것은 정수 결과이다.
        11.  
        12. // 둘째로, std::pow는 constexpr이 아니다.
        13.  
        14. // 이 두 가지 문제점은 지금 요구에 맞는 pow함수를
        15. // 직접 작성하면 해결된다.
        16.  
        17. constexpr // pow는 결코 예외를 던지지
        18. int pow(int base, int exp) noexcept // 않는 constexpr 함수
        19. {
        20. ... // 구현은 나중에
        21. }
        22.  
        23. constexpr auto numConds = 5; // 조건들의 개수
        24.  
        25. std::array<int, pow(3, numConds)> results; // results 개의
        26. // 3^numConds 개의
        27. // 요소들을 담는다.
        28.  
        29. // pow 앞에 constexpr이 있다고 해서
        30. // pow가 반드시 const 값을 돌려주는
        31. // 것은 아님을 기억하기 바란다.
        32.  
        33. // 만일 base나 exp 중 하나라도 컴파일
        34. // 시점 상수가 아니면 pow의 결과가
        35. // 실행시점에서 계산될 수 있다.
        36.  
        37. // 즉, 다음과 같이 pow를 사용할 수 있다.
        38.  
        39. auto base = readFromDB("base"); // 실행시점에서 값들을
        40. auto exp = readFromDB("exponent"); // 구한다.
        41.  
        42. auto baseToExp = pow(base, exp); // 실행시점에서 pow 함수를
        43. // 호출한다.
        44.  
        45.  
        46. //-----------------------------------------------------------------------------
        47. // constexpr 함수는 컴파일 시점 값들로
        48. // 호출했을 때 반드시 컴파일 시점 결과를
        49. // 산출할 수 있어야 하므로, 구현에 일정한
        50. // 제약들이 따른다.
        51.  
        52. // C++11에서 constexpr 함수는 실행 가능
        53. // 문장이 많아야 하나(1개 혹은 0개)이어야 한다.
        54.  
        55. // 이것이 큰 제약이긴 하지만, 두 가지 요령을
        56. // 이용하면 constexpr 함수의 표현력을 생각 이상으로
        57. // 확장할 수 있다.
        58.  
        59. // 하나는 조건부 연산자(삼항 연산자) "?:"을
        60. // if-else 문 대신 사용하는 것이고, 또 하나는
        61. // 루프 대신 재귀를 사용하는 것이다.
        62.  
        63. // 다음은 이 요령들을 이용해서 pow를 구현한
        64. // 예이다.
        65.  
        66. constexpr int pow(int base, int exp) noexcept
        67. {
        68. return (exp == 0 ? 1 : base * pow(base, exp - 1));
        69. }
        70.  
        71. // C++14에서는 constexpr 함수에 대한 제약이
        72. // 상당히 느슨해져서, 다음과 같은 구현이 허용된다.
        73.  
        74. constexpr int pow(int base, int exp) noexcept // C++14
        75. {
        76. auto result = 1;
        77. for (int i = 0; i < exp; ++i) result *= base;
        79. return result;
        80. }
        81.  
        82.  
        83. //-----------------------------------------------------------------------------
        84. // constexpr 함수는 반드시 리터럴 타입
        85. // (literal type)들을 받고
        86. // 돌려주어야 한다.
        87.  
        88. // 리터럴 타입은 컴파일 도중에 값을
        89. // 결정할 수 있는 타입이다.
        90.  
        91. // C++11에서 void를 제외한 모든
        92. // 내장 타입이 리터럴 타입에 해당한다.
        93.  
        94. // 그리고 생성자와 적절한 멤버 함수들이
        95. // constexpr인 사용자 타입도 리터럴 타입이
        96. // 될 수 있다.
        97.  
        98. class Point {
        99. public:
        100. constexpr Point(double xVal = 0, double yVal = 0) noexcept
        101. : x(xVal), y(yVal)
        102. {}
        104. constexpr double xValue(void) const noexcept { return x; }
        105. constexpr double yValue(void) const noexcept { return y; }
        107. void setX(double newX) noexcept { x = newX; }
        108. void setY(double newY) noexcept { y = newY; }
        110. private:
        111. double x, y;
        112. };
        113.  
        114. // 여기서 Point의 생성자를 constexpr로
        115. // 선언할 수 있는 이유는, 주어진 인수들이
        116. // 컴파일 시점에서 알려진다면 생성된 Point
        117. // 객체의 데이터 멤버들의 값 역시 컴파일
        118. // 시점에서 알려질 수 있기 때문이다.
        119.  
        120. constexpr Point p1(9.4, 27.7); // OK, constexpr 생성자가
        121. // 컴파일 시점에서 "실행됨"
        122.  
        123. constexpr Point p2(28.8, 5.3); // 역시 OK
        124.  
        125. // 마찬가지로 컴파일 도중에 알려진 값으로
        126. // 초기화된 Point 객체에 대해 호출된다면
        127. // 조회용 멤버 함수(getter; 줄여서 조회 함수)
        128. // 역시 constexpr이 될 수 있다.
        129.  
        130. // 따라서 다음과 같은 함수를 작성하는 것이
        131. // 가능하다.
        132.  
        133. constexpr
        134. Point midpoint(const Point& p1, const Point& p2) noexcept
        135. {
        136. return { (p1.xValue() + p2.xValue()) / 2, // constexpr 멤버
        137. (p1.yValue() + p2.yValue()) / 2 }; // 함수들을 호출
        138. }
        139.  
        140. constexpr auto mid = midpoint(p1, p2); // constexpr 함수의
        141. // 결과를 이용해서
        142. // constexpr 객체를
        143. // 초기화한다.
        144.  
        145.  
        146. //-----------------------------------------------------------------------------
        147. // C++11에서는 두 가지 제약 때문에 Point의
        148. // 멤버 함수 setX와 setY를 constexpr로 선언할
        149. // 수 없다.
        150.  
        151. // 첫째로, 이 멤버 함수들은 대상 객체를 수정하는데,
        152. // C++11에서 constexpr 멤버 함수는 암묵적으로
        153. // const로 선언된다.
        154.  
        155. // 둘째로, 이 멤버 함수들은 반환 타입이 void인데,
        156. // C++11에서 void는 리터럴 타입이 아니다.
        157.  
        158. // C++14에서는 두 제약 모두 사라졌다. 그래서
        159. // C++14에서는 Point의 설정용 멤버 함수
        160. // (setter; 줄여서 설정 함수)들도 constexpr이
        161. // 될 수 있다.
        162.  
        163. class Point {
        164. public:
        165. ...
        167. constexpr void setX(double newX) noexcept // C++14
        168. { x = newX; }
        170. constexpr void setY(double newY) noexcept // C++14
        171. { y = newY; }
        173. ...
        174. };
        175.  
        176. // 이를 이용해서 이제 이런 함수를 작성할 수 있다.
        177.  
        178. // 원점을 기준으로 p와 대칭인 Point 객체를 돌려준다(C++14).
        179. constexpr Point reflection(const Point& p) noexcept
        180. {
        181. Point result; // 비const Point를 생성
        183. result.setX(-p.xValue()); // 그 Point의 x와 y를 설정
        184. result.setY(-p.yValue());
        186. return result; // 그 복사본을 반환
        187. }
        188.  
        189. // 다음은 이들을 사용하는 클라이언트
        190. // 코드의 모습이다.
        191.  
        192. constexpr Point p1(9.4, 27.7); // 이전과 동일
        193. constexpr Point p2(28.8, 5.3);
        194. constexpr auto mid = midpoint(p1, p2);
        195.  
        196. constexpr auto reflectedMid = // reflectedMid의 값은
        197. reflection(mid); // (-19.1, -16.5)이다; 이는
        198. // 컴파일 도중에 알려진다.
        199.  

        
        
        예제 코드 접기
        
        
        

      • constexpr 객체나 함수는 비constexpr 객체나 함수보다 광범위한 문맥에서 사용할 수 있다.

      • constexpr은 객체나 함수의 인터페이스의 일부이다.

        어떤 객체나 함수를 constexpr로 선언했다면, 클라이언트들은 그것을 믿고 그 객체나 함수를 그런 문맥들에서 사용할 것이다. 나중에 마음을 바꾸어서 constexpr을 제거하면, 갑자기 컴파일이 되지 않는 클라이언트가 얼마나 될지는 아무도 모르는 일이다.
        
        "가능한 한 항상 constexpr을 사용해라"라는 조언에서 "가능한 한 항상" 부분에는 constexpr을 가능하게 하기 위해 객체나 함수를 적용한 제약들을 최대한 오래 유지하겠다는 여러분의 의지가 포함됨을 명심하기 바란다.

  16. const 멤버 함수를 스레드에 안전하게 작성하라 / 111

      • 동시적 문맥에서 쓰이지 않을 것이 확실한 경우가 아니라면, const 멤버 함수는 스레드에 안전하게 작성하라.

        예제 코드 보기
        
        
        

        1. // 다항식을 대표하는 클래스를 만든다고 하자.
        2.  
        3. // 이 클래스가 유용하려면 다항식의 근을
        4. // 계산하는 멤버 함수를 갖추어야 할 것이다.
        5.  
        6. // 그런 함수는 다항식을 수정하지 않을 것이므로,
        7. // const로 선언하는 것이 자연스럽다.
        8.  
        9. // 다항식 근의 계산 비용이 클 수 있으므로,
        10. // 꼭 필요할 때에만 계산하는 것이 바람직하다.
        11.  
        12. // 즉, 필요할 때에만 근(들)을 실제로 계산해서
        13. // 캐시에 저장하고, 그렇지 않을 때에는 그냥
        14. // 캐시에 있는 값을 돌려주도록 구현하는
        15. // 것이 바람직하다.
        16.  
        17. class Polynomial {
        18. public:
        19. using RootsType = // 다항식이 0으로 평가되는 값들을
        20. std::vector<double>; // 담는 자료구조(using의 용법에
        21. // 관해서는 항목 9를 보라)
        22. ...
        23. RootsType roots(void) const
        24. {
        25. if (!rootsAreValid) { // 캐시가 유효하지 않으면
        27. ... // 근들을 계산해서
        28. // rootVals에 저장해 둔다.
        29. rootsAreValid = true;
        30. }
        32. return rootVals;
        33. }
        34. ...
        36. private:
        37. mutable bool rootsAreValid{ false }; // 중괄호 초기치에 관해서는
        38. mutable RootsType rootVals{}; // 항목 7을 보라
        39. };
        40.  
        41. // 만약 두 스레드가 하나의 Polynomial 객체에 대해
        42. // 동시에 roots를 호출한다고 생각해 보자.
        43.  
        44. // 두 스레드 중 하나나 둘 다가 데이터 멤버
        45. // rootsAreValid와 rootVals를 수정하려
        46. // 들 수 있다.
        47.  
        48. // 이 문제를 해결하는 가장 쉬운 방법은
        49. // 통상적인 동기화 수단, 즉 뮤텍스(std::mutex)를
        50. // 사용하는 것이다.
        51.  
        52. class Polynomial {
        53. public:
        54. using RootsType = std::vector<double>;
        56. RootsType roots(void) const
        57. {
        58. std::lock_guard<std::mutex> g(m); // 뮤텍스를 잠근다.
        60. if (!rootsAreValid) { // 캐시가 유효하지 않으면
        62. ... // 근들을 계산, 저장한다.
        64. rootsAreValid = true;
        65. }
        67. return rootVals;
        68. } // 뮤텍스를 푼다.
        70. private:
        71. mutable std::mutex m;
        72. mutable bool rootsAreValid{ false };
        73. mutable RootsType rootVals{};
        74. };
        75.  
        76. // 뮤텍스를 잠그고 푸는 멤버 함수들이 비const
        77. // 이기 때문에 mutex도 mutable로 선언해야 한다.
        78.  
        79. // std::mutex를 복사하거나 이동할 수 없기 때문에,
        80. // m을 Polynomial에 추가하면 Polynomial의
        81. // 복사와 이동 능력도 사라진다는 점을 주목하기 바란다.

        
        
        예제 코드 접기
        
        
        동시적 문맥에서 쓰이지 않는 상황은 점점 드물어지고 있으며, 앞으로는 아주 희귀한 경우가 될 가능성이 크다. const 멤버 함수가 언제라도 동시적 실행 상황에 처할 것이라고 가정하는 것이 안전하며, 따라서 const 멤버 함수는 항상 스레드에 안전하게 만드는 것이 바람직하다.

      • std::atomic 변수는 뮤텍스에 비해 성능상의 이점이 있지만, 하나의 변수 또는 메모리 장소를 다룰 때에만 적합하다.

        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 멤버 함수의 호출 횟수를 세고 싶다면,
        3. // std::atomic 카운터(항목 40 참고)를
        4. // 사용해서 비용을 줄일 수 있는 경우가
        5. // 많다.
        6.  
        7. // (실제로 비용이 절감되는지는 프로그램이 실행되는
        8. // 컴퓨터 하드웨어에 따라, 그리고 표준 라이브러리의
        9. // 구체적인 뮤텍스 구현 방식에 따라 다를 수 있다)
        10.  
        11. // 다음은 std::atomic을 이용해서 멤버 함수의
        12. // 호출 횟수를 세는 방법을 보여주는 예제 코드이다.
        13.  
        14. class Point { // 2차원 점
        15. public:
        16. ...
        17. double distanceFromOrigin(void) const noexcept // noexcept는
        18. { // 항목 14 참고
        20. ++callCount; // 원자적 증가
        22. return std::hypot(x, y); // std::hypot은
        23. } // C++11의 새 함수
        25. private:
        26. mutable std::atomic<unsigned> callCount{ 0 };
        27. double x, y;
        28. };
        29.  
        30. // std::mutex처럼 std::atomic도 복사와
        31. // 이동이 불가능하다.
        32.  
        33. // 따라서 Point에 이 callCount를 도입하면
        34. // Point 역시 복사와 이동이 불가능해진다.
        35.  
        36. // std::atomic 변수에 대한 연산들이 뮤텍스를
        37. // 획득하고 해제하는 것보다 비용이 싸다는
        38. // 점에 현혹되어서 std::atomic을 남용하기
        39. // 쉬우니 조심하기 바란다.
        40.  
        41.  
        42. //-----------------------------------------------------------------------------
        43. // 예를 들어 계산 비용이 큰 int 값을 캐시에
        44. // 저장하는 클래스라면 뮤텍스 대신 한 쌍의
        45. // std::atomic 변수들을 사용해볼 만하다.
        46.  
        47. class Widget {
        48. public:
        49. ...
        51. int magicValue(void) const
        52. {
        53. if (cacheValid) return cacheValue;
        54. else {
        55. auto val1 = expensiveComputation1();
        56. auto val2 = expensiveComputation2();
        57. cacheValue = val1 + val2; // !?
        58. cacheValid = true; // !?!?
        59. return cacheValue;
        60. }
        61. }
        63. private:
        64. mutable std::atomic<bool> cacheValid{ false };
        65. mutable std::atomic<int> cacheValue;
        66. };
        67.  
        68. // 이 코드가 작동하긴 하지만,
        69. // 생각보다 비용이 클 수 있다.
        70.  
        71. // 1. 한 스레드가 Widget::magicValue를 호출한다.
        72. // cacheValid가 false라고 관측하고, 비용이 큰 두
        73. // 계산을 수행한 후 둘의 합을 cacheValue에 대입한다.
        74.  
        75. // 2. 그 시점에서 둘째 스레드가 Widget::magicValue를
        76. // 호출하는데, 역시 cacheValid가 false라고 관측해서
        77. // 첫 스레드가 방금 마친 것과 동일한 비싼 계산들을
        78. // 수행한다(이 '둘째 스레드'가 실제로는 여러 개의
        79. // 다른 스레드들일 수도 있다).
        80.  
        81.  
        82. //-----------------------------------------------------------------------------
        83. // cacheValue와 cacheValid의 대입 순서를
        84. // 반대로 바꾸면 이 문제가 해결될 것으로
        85. // 생각할 수 있지만, 여전히 cacheValid가 true로
        86. // 설정되기 전에 여러 스레드가 val1과 val2를
        87. // 계산하게 되는 상황이 생길 수 있으며,
        88. // 상황이 더 나빠질 수도 있다.
        89.  
        90. class Widget {
        91. public:
        92. ...
        94. int magicValue(void) const
        95. {
        96. if (cacheValid) return cacheValue;
        97. else {
        98. auto val1 = expensiveComputation1();
        99. auto val2 = expensiveComputation2();
        100. cacheValid = true; // !?
        101. cacheValue = val1 + val2; // !?!?
        102. return cacheValue;
        103. }
        104. }
        106. private:
        107. mutable std::atomic<bool> cacheValid{ false };
        108. mutable std::atomic<int> cacheValue;
        109. };
        110.  
        111. // cacheValid가 false라고 할 때
        112.  
        113. // 1. 한 스레드가 Widget::magicValue를 호출해서,
        114. // cacheValid가 true로 설정되는 지점까지 나아간다.
        115.  
        116. // 2. 그 시점에서 둘째 스레드가 Widget::magicValue를
        117. // 호출해서 cacheValid를 점검한다. 그것이 true임을
        118. // 관측한 둘째 스레드는, 첫 스레드가 cacheValue에
        119. // 값을 대입하기도 전에 cacheValue를 돌려준다.
        120. // 따라서 그 반환값은 정확하지 않다.
        121.  
        122.  
        123. //-----------------------------------------------------------------------------
        124. // 위에서 보았듯이, 동기화가 필요한 변수 하나
        125. // 또는 메모리 장소 하나에 대해서는 std::atomic을
        126. // 사용하는 것이 적합하지만, 둘 이상의 변수나
        127. // 메모리 장소를 하나의 단위(unit)로서 조작해야
        128. // 할 때에는 뮤텍스를 꺼내는 것이 바람직하다.
        129.  
        130. // Widget::magicValue를 뮤텍스로 보호한다면
        131. // 다음과 같은 모습이 될 것이다.
        132.  
        133. class Widget {
        134. public:
        135. ...
        137. int magicValue(void) const
        138. {
        139. std::lock_guard<std::mutex> guard(m); // m을 잠근다.
        141. if (cacheValid) return cacheValue;
        142. else {
        143. auto val1 = expensiveComputation1();
        144. auto val2 = expensiveComputation2();
        145. cacheValid = true;
        146. cacheValue = val1 + val2;
        147. return cacheValue;
        148. }
        149. } // m을 푼다.
        151. private:
        152. mutable std::mutex m;
        153. mutable int cacheValue; // 이제는 atomic이 아님
        154. mutable bool cacheValid{ false }; // 이제는 atomic이 아님
        155. };

        
        
        예제 코드 접기
        
        
        

  17. 특수 멤버 함수들의 자동 작성 조건을 숙지하라 / 117

      • 컴파일러가 스스로 작성할 수 있는 멤버 함수들, 즉 기본 생성자와 소멸자, 복사 연산들, 이동 연산들을 가리켜 특수 멤버 함수라고 부른다.

        • 기본 생성자: C++98의 규칙들과 같다. 클래스에 사용자 선언 생성자가 없는 경우에만 자동으로 작성된다.
        • 소멸자: C++98의 규칙들과 본질적으로 같다. 유일한 차이는 소멸자가 기본적으로 noexcept라는 점이다(항목 14 참고). C++98에서처럼, 기본적으로 작성되는 소멸자는 오직 기반 클래스 소멸자가 가상일 때에만 가상이다.
        • 복사 생성자: 실행시점 행동은 C++98의 것과 같다. 즉, 비정적 데이터 멤버들을 멤버별로 복사 생성한다. 클래스에 사용자 선언 복사 생성자가 없을 때에만 자동으로 작성된다. 클래스에 이동 연산이 하나라도 선언되어 있으면 삭제(비활성화)된다. 사용자 선언 복사 대입 연산자나 소멸자가 있는 클래스에서 이 함수가 자동 작성되는 기능은 비권장이다.
        • 복사 대입 연산자: 실행시점 행동은 C++98의 것과 같다. 즉, 비정적 데이터 멤버들을 멤버별로 복사 대입한다. 클래스에 사용자 선언 복사 대입 연산자가 없을 때에만 자동으로 작성된다. 클래스에 이동 연산이 하나라도 선언되어 있으면 삭제(비활성화)된다. 사용자 선언 복사 생성자나 소멸자가 있는 클래스에서 이 함수가 자동 작성되는 기능은 비권장이다.
        • 이동 생성자와 이동 대입 연산자: 각각 비정적 데이터 멤버의 멤버별 이동을 수행한다. 클래스에 사용자 선언 복사 연산들과 이동 연산들, 소멸자가 없을 때에만 자동으로 작성된다.
        
        
        C++11에서는 명시적으로 선언된 특수 멤버 함수가 기본 행동을 사용하겠다는 의사를 " = default"를 이용해서 명시적으로 표현할 수 있다.
        
        " = default" 예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 소멸자나 복사 연산 중 하나를 선언하면
        3. // 복사 연산들이 자동으로 작성된다는 점에
        4. // 의존하는 것이 있다면, 그러한 의존성이
        5. // 사라지도록 클래스를 업그레이드하는 것이
        6. // 바람직하다.
        7.  
        8. // 컴파일러가 작성한 함수들의 행동이 정확하다면,
        9. // 그러한 업그레이드는 쉬운 일이다.
        10.  
        11. // C++11에서는 기본 행동을 사용하겠다는
        12. // 의사를 " = default"를 이용해서 명시적으로
        13. // 표현할 수 있기 때문이다.
        14.  
        15. class Widget {
        16. public:
        17. ...
        18. ~Widget(void); // 사용자 선언 소멸자
        20. ... // 기본 복사 생성자
        21. Widget(const Widget&) = default; // 기본 행동 OK
        23. Widget& // 기본 복사 대입
        24. operator=(const Widget&) = default; // 기본 행동 OK
        25. ...
        26. };
        27.  
        28.  
        29. //-----------------------------------------------------------------------------
        30. // 이러한 접근방식은 다형적 기반 클래스,
        31. // 즉 파생 클래스 객체들을 조작하는 데
        32. // 쓰이는 인터페이스를 정의하는 클래스에
        33. // 유용한 경우가 많다.
        34.  
        35. // 대체로 다형적 기반 클래스에는 가상
        36. // 소멸자가 있다.
        37.  
        38. // 이미 가상으로 선언된 소멸자를 상속하는
        39. // 것이 아닌 한, 소멸자가 가상이 되게
        40. // 만드는 유일한 방법은 명시적으로 virtual로
        41. // 선언하는 것뿐이다.
        42.  
        43. // 가상으로 만드는것 외에는 기본 구현을
        44. // 그대로 사용하고 싶다고 하자.
        45.  
        46. // 다음과 같이 할 수 있다.
        47.  
        48. class Base {
        49. public:
        50. virtual ~Base(void) = default; // 소멸자를 가상으로
        52. Base(Base&&) = default; // 이동 지원
        53. Base& operator=(Base&&) = default;
        55. Base(const Base&) = default; // 복사 지원
        56. Base& operator=(const Base&) = default;
        58. ...
        60. };
        61.  
        62.  
        63. //-----------------------------------------------------------------------------
        64. // 이렇게 기본 구현을 사용하겠다고 명시적으로
        65. // 선언하는것은, 타자량이 좀 늘더라도 이로울
        66. // 때가 많다.
        67.  
        68. // 정수 ID를 통해서 문자열 값을 빠르게 조회할
        69. // 수 있는 자료구조를 나타내는 클래스가 있다고
        70. // 하자.
        71.  
        72. class StringTable {
        73. public:
        74. StringTable(void) {}
        75. ... // 삽입, 삭제, 조회 등을 위한 함수들은 있지만
        76. // 복사/이동/소멸자 기능성은 없음
        78. private:
        79. std::map<int, std::string> values;
        80. };
        81.  
        82. // 이 클래스가 복사 연산들과 이동 연산들,
        83. // 그리고 소멸자를 전혀 선언하지 않는다면,
        84. // 그리고 그런 함수들을 사용하는 클라이언트
        85. // 코드가 있다면, 컴파일러는 해당 함수들을
        86. // 자동으로 만들어 준다.
        87.  
        88. // 그러나, 나중에 이런 객체들의 기본 생성과
        89. // 소멸을 기록하는 것이 유용하겠다는 생각이
        90. // 들었다고 하자.
        91.  
        92. class StringTable {
        93. public:
        94. StringTable(void)
        95. { makeLogEntry("Create StringTable object"); } // 추가됨
        97. ~StringTable(void) // 역시
        98. { makeLogEntry("Destroying StringTable object"); } // 추가됨
        100. ... // 다른 함수들은 이전과 동일
        102. private:
        103. std::map<int, std::string> values; // 이전과 동일
        104. };
        105.  
        106. // 이제 컴파일러는 복사 연산들은 자동으로
        107. // 작성하지만, 이동 연산들은 자동으로
        108. // 작성하지 않는다.
        109.  
        110. // 문제는 이동 연산이 없어도 무사히
        111. // 컴파일되며, 실행도 아무런 문제 없이
        112. // 된다.
        113.  
        114. // 때문에 이동 연산을 명시적으로 선언하지
        115. // 않는 실수를 하기 쉽다.
        116.  
        117. // 문제는, 이동 연산이 일어나야 할 시점에
        118. // 대신 복사 연산이 일어나서 효율이
        119. // 심각하게 떨어질 수 있다.

        
        
        " = default" 예제 코드 접기
        
        
        

      • 이동 연산들은 이동 연산들이나 복사 연산들, 소멸자가 명시적으로 선언되어 있지 않은 클래스에 대해서만 자동으로 작성된다.

        복사 연산들이나 소멸자가 명시적으로 선언되었다는 것은, 자동으로 작성된 복사 연산들과 소멸자가 적합하지 않다는 이야기인데, 이 경우 자동으로 작성된 이동 연산도 적합하지 않을 가능성이 크다.
        
        자동으로 작성된 이동 연산들은 비정적 데이터 멤버들을 멤버별로 이동을 수행하는데, 만일 어떤 데이터 멤버가 이동 연산을 지원하지 않는다면 그 데이터 멤버는 이동 연산 대신 복사 연산이 일어난다. 기반 클래스가 이동 연산을 지원하지 않는 경우에도 마찬가지로, 기반 클래스에 대해서 이동 연산 대신 복사 연산이 일어난다.

      • 복사 생성자는 복사 생성자가 명시적으로 선언되어 있지 않은 클래스에 대해서만 자동으로 작성되며, 만일 이동 연산이 하나라도 선언되어 있으면 삭제된다. 복사 대입 연산자는 복사 대입 연산자가 명시적으로 선언되어 있지 않은 클래스에 대해서만 자동으로 작성되며, 만일 이동 연산이 하나라도 선언되어 있으면 삭제된다. 소멸자가 명시적으로 선언된 클래스에서 복사 연산들이 자동 작성되는 기능은 비권장이다.

        이동 연산들이 명시적으로 선언되었다는 것은, 자동으로 작성된 이동 연산들이 적합하지 않다는 이야기인데, 이 경우 자동으로 작성된 복사 연산들도 적합하지 않을 가능성이 크다.
        
        복사 생성자(또는 복사 대입 연산자)가 복사 대입 연산자(또는 복사 생성자)나 소멸자가 명시적으로 선언되었을때도 자동으로 작성되는 것은, 그렇지 않도록 복사 연산들이 작성되는 조건을 제한하면 기존 코드가 너무 많이 깨질 것이라는 판단 때문이다.

      • 멤버 함수 템플릿 때문에 특수 멤버 함수의 자동 작성이 금지되는 경우는 전혀 없다.

        예제 코드 보기
        
        
        

        1. // 멤버 함수 템플릿이 존재하면 특수 멤버 함수의
        2. // 자동 작성이 비활성화된다는 규칙은 없음을
        3. // 주목하기 바란다.
        4.  
        5. // 다음과 같은 Widget 클래스가 있다고 하자.
        6.  
        7. class Widget {
        8. public:
        9. ...
        10. template <typename T> // 그 어떤 것으로도
        11. Widget(const T& rhs); // Widget을 생성
        13. template <typename T> // 그 어떤 것으로도
        14. Widget& operator=(const Widget& rhs); // Widget을 대입
        15. ...
        16. };
        17.  
        18. // 이 템플릿들이 복사 생성자나 복사 대입 연산자의
        19. // 시그니처와 일치하는 함수들로 인스턴스화될 가능성이
        20. // 있지만, 그래도 컴파일러는 여전히 Widget의
        21. // 복사 연산들과 이동 연산들을 작성한다(조건이
        22. // 만족되었다면).

        
        
        예제 코드 접기
        
        
        이 점이 중요한 영향을 미칠 수 있음을 항목 26에서 보게 될 것이다.

• Chapter 4   스마트 포인터

  18. 소유권 독점 자원의 관리에는 std::unique_ptr를 사용하라 / 127

      • std::unique_ptr는 독점 소유권 의미론을 가진 자원의 관리를 위한, 작고 빠른 이동 전용 스마트 포인터이다.

        std::unique_ptr는 기본적으로 생 포인터와 같은 크기라고 가정할 수 있으며, 대부분의 연산(역참조를 비롯해서)에서 생 포인터와 정확히 동일한 명령들을 실행한다.
        
        std::unique_ptr는 독점적 소유권(exclusive ownership) 의미론을 체현하고 있다. 널이 아닌 std::unique_ptr는 항상 자신이 가리키는 객체를 소유한다. std::unique_ptr를 이동하면 소유권이 원본 포인터에서 대상 포인터로 옮겨진다(원본 포인터는 널로 설정된다).
        
        std::unique_ptr의 복사는 허용되지 않는다. 만일 복사가 허용되면, 두 std::unique_ptr가 같은 자원을 가리킬 뿐만 아니라 두 포인터 모두 자신이 그 자원을 소유하고 있다고(따라서 그 자원을 파괴해야 한다고) 생각하는 상황이 벌어질 것이다.
        
        널이 아닌 std::unique_ptr는 소멸 시 자신이 가리키는 자원을 파괴한다. 기본적으로, 자원 파괴는 std::unique_ptr 안에 있는 생 포인터에 delete를 적용함으로써 수행된다.
        
        std::unique_ptr 예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // std::unique_ptr의 흔한 용도 하나는,
        3. // 계통구조(hierarchy) 안의 객체를 생성하는
        4. // 펙터리 함수의 반환 타입으로 쓰이는 것이다.
        5.  
        6. // 주식(stock), 채권(bond), 부동산(real estate)
        7. // 같은 여러 종류의 투자 대상들을 대표하는
        8. // Investment를 기반 클래스로 삼은
        9. // 다음과 같은 계통 구조가 있다고 하자.
        10.  
        11. class Investment { ... };
        12.  
        13. class Stock:
        14. public Investment { ... };
        15.  
        16. class Bond:
        17. public Investment { ... };
        18.  
        19. class RealEstate:
        20. public Investment { ... };
        21.  
        22. // 팩터리 함수는 다음과 같이 만들 수 있을 것이다.
        23.  
        24. template <typename... Ts> // 주어진 인수들로 생성한
        25. std::unique_ptr<Investment> // 객체를 가리키는
        26. makeInvestment(Ts&&... params); // std::unique_ptr를 돌려줌
        27.  
        28. // 다음은 이 팩터리 함수를 사용하는 예이다.
        29.  
        30. {
        31. ...
        32. auto pInvestment = // pInvestment의 타입은
        33. makeInvestment( 인수들 ); // std::unique_ptr<Investment>
        35. ...
        36. } // *pInvestment가 파괴된다.
        37.  
        38.  
        39. //-----------------------------------------------------------------------------
        40. // std::unique_ptr를 소유권 이전
        41. // 시나리오에서 사용할 수도 있다.
        42.  
        43. // 예를 들어 팩터리 함수가 돌려준 std::unique_ptr를
        44. // 어떤 컨테이너 안으로 이동하고, 이후
        45. // 그 컨테이너 요소를 어떤 객체의 한 데이터
        46. // 멤버로 이동하고, 그 후 어느 시점에서
        47. // 그 객체가 파괴된다고 하자.
        48.  
        49. // 예외나 기타 비전형적 제어 흐름(이를테면
        50. // 때 이른 함수 반환이나 루프로부터의 break 등)
        51. // 때문에 그러한 일련의 소유권 이동이 중도에
        52. // 가로채이면, 결국에는 관리되는 자원을
        53. // 소유하고 있던 std::unique_ptr의 소멸자가
        54. // 호출되며, 결과적으로 관리되는 자원이 파괴된다.
        55.  
        56. // 이 규칙에는 몇 가지 예외가 있다.
        57.  
        58. // 예외가 스레드의 주 함수(예를 들어 프로그램의
        59. // 초기 스레드의 경우에는 main) 바깥으로
        60. // 전파되거나 noexcept 명세가 위반되면 지역
        61. // 객체들이 파괴되지 않을 수 있으며, std::abort나
        62. // 어떤 종료 함수(즉 std::_Exit나 std::exit,
        63. // std::quick_exit)가 호출되면 지역 객체들은
        64. // 절대로 파괴되지 않는다.
        65.  
        66.  
        67. //-----------------------------------------------------------------------------
        68. // unique_ptr의 흔한 용도는
        69. // 팩터리 함수만이 아니다.
        70.  
        71. // std::unique_ptr는 Pimpl 관용구의
        72. // 구현 메커니즘으로 더 인기 있다.
        73.  
        74. // 이에 관한 예제는 항목 22를 찾아 보자.

        
        
        std::unique_ptr 예제 코드 접기
        
        
        std::unique_ptr는 두 가지 형태인데, 하나는 개별 객체를 위한 것(std::unique_ptr<T>)이고 또 하나는 배열을 위한 것(std::unique_ptr<T[]>)이다.
        
        이 때문에 생 포인터와 달리 std::unique_ptr는, 어떤 종류의 개채(배열인지 개별 객체인지)를 가리키는지에 관련된 애매함이 절대 발생하지 않는다.
        
        std::unique_ptr API는 사용 대상에 잘 맞는 형태로 설계되어 있다. 예를 들어 개별 객체 버전은 색인 적용 연산자(operator[])를 제공하지 않으며, 배열 버전은 역참조 연산자들(operator*와 operator->)을 제공하지 않는다.
        
        하지만, 내장 배열보다는 std::array나 std::vector, std::string이 거의 항상 더 나은 선택이다. 그러므로 std::unique_ptr의 배열 버전은, 힙에 생성된 배열을 가리키는 생 포인터를 돌려주는 C 스타일 API를 다루어야 하는 경우를 제외하면 마땅히 쓸 이유를 찾기 힘들다.

      • 기본적으로 자원 파괴는 delete를 통해 일어나나, 커스텀 삭제자를 지정할 수도 있다. 상태 있는 삭제자나 함수 포인터를 사용하면 std::unique_ptr 객체의 크기가 커진다.

        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 자원의 파괴는 기본적으로 delete를 통해서
        3. // 일어나지만, std::unique_ptr 객체를 생성할
        4. // 때 커스텀 삭제자(custom deleter)를 사용하도록
        5. // 지정하는 것도 가능하다.
        6.  
        7. // 커스텀 삭제자는 해당 자원의 파괴 시점에서
        8. // 호출되는 임의의 함수(또는 람다 표현식으로부터
        9. // 산출되는 것들을 포함한 함수 객체)이다.
        10.  
        11. // makeInvestment가 생성한 객체를 파괴하기 전에
        12. // 로그 항목을 기록하고 싶다면, makeInvestment를
        13. // 다음과 같이 구현하면 될 것이다.
        14.  
        15. auto delInvmt = [](Investment* pInvestment) // 커스텀
        16. { // 삭제자
        17. makeLogEntry(pInvestment); // (람다
        18. delete pInvestment; // 표현식)
        19. }
        20.  
        21. template <typename... Ts>
        22. std::unique_ptr<Investment, decltype(delInvmt)>
        23. makeInvestment(Ts&&... params)
        24. {
        25. std::unique_ptr<Investment, decltype(delInvmt)>
        26. pInv(nullptr, delInvmt);
        28. if ( /* Stock 객체를 생성해야 하는 경우 */ )
        29. {
        30. pInv.reset(new Stock(std::forward<Ts>(params)...));
        31. }
        32. else if ( /* Bond 객체를 생성해야 하는 경우 */ )
        33. {
        34. pInv.reset(new Bond(std::forward<Ts>(params)...));
        35. }
        36. else if ( /* RealEstate 객체를 생성해야 하는 경우 */ )
        37. {
        38. pInv.reset(new RealEstate(std::forward<Ts>(params)...));
        39. }
        41. return pInv;
        42. }
        43.  
        44. // 1 ------------------------------------------------------
        45. // delInvmt는 makeInvestment가 돌려준
        46. // 객체에 대한 커스텀 삭제자이다.
        47.  
        48. // 모든 커스텀 삭제 함수는 파괴할 객체를 가리키는
        49. // 포인터 하나를 받으며, 그 객체를 파괴하는 데
        50. // 필요한 일들을 수행한다.
        51.  
        52. // 람다 표현식을 이용해서 delInvmt를 생성하는 것은
        53. // 편리할 뿐만 아니라, 잠시 후에 보겠지만 통상적인
        54. // 함수를 작성하는 것보다 더 효율적이기도 하다.
        55.  
        56. // 2 ------------------------------------------------------
        57. // 커스텀 삭제자를 사용할 때에는 그 타입을
        58. // std::unique_ptr의 둘째 타입 인수로 지정해야 한다.
        59.  
        60. // 지금 예에서 삭제자의 타입은 delInvmt의
        61. // 타입이며, makeInvestment의 반환 타입이
        62. // std::unique_ptr<Investment, decltype(delInvmt)>인
        63. // 것은 바로 그 때문이다(decltype에 관해서는
        64. // 항목 3을 보라).
        65.  
        66. // 3 ------------------------------------------------------
        67. // makeInvestment의 기본 전략은 널 std::unique_ptr를
        68. // 만들어서 적절한 타입의 객체를 가리키게 한 후
        69. // 돌려주는 것이다.
        70.  
        71. // 커스텀 삭제자 delInvmt를 pInv에 연관시키기
        72. // 위해, pInv 생성 시 delInvmt를 둘째 타입으로
        73. // 지정한다.
        74.  
        75. // 4 ------------------------------------------------------
        76. // 생 포인터(이를테면 new로 얻은 포인터)를
        77. // std::unique_ptr에 대입하는 문장은 컴파일되지
        78. // 않는다.
        79.  
        80. // 그런 문장을 허용한다면, 생 포인터에서 스마트
        81. // 포인터로의 암묵적 변환이 성립하기 때문이다.
        82.  
        83. // 그런 암묵적 변환에는 문제가 있으므로, C++11의
        84. // 스마트 포인터들은 그런 변환을 금지한다.
        85.  
        86. // 이 때문에, new로 생성한 객체의 소유권을
        87. // pInv에 부여하기 위해 reset을 호출했다.
        88.  
        89. // 5 ------------------------------------------------------
        90. // 각 new 호출에서는 makeInvestment 함수에
        91. // 전달된 인수들을 new에 완벽하게 전달하기
        92. // 위해 std::forward를 사용했다(항목 25 참고).
        93.  
        94. // 이렇게 하면 호출자가 함수에 제공한 모든
        95. // 정보를 함수 안에서 생성할 객체의 생성자에게
        96. // 손실 없이 넘겨줄 수 있다.
        97.  
        98. // 6 ------------------------------------------------------
        99. // 커스텀 삭제자는 Investment*
        100. // 타입의 매개변수를 받는다.
        101.  
        102. // makeInvestment 안에서 생성하는 객체의 실제
        103. // 타입이 무엇이든, 그 객체는 람다 표현식
        104. // 안에서 Investment* 객체로서 delete된다.
        105.  
        106. // 즉, 기반 클래스 포인터를 통해서 파생 클래스의
        107. // 객체를 삭제하는 것이다.
        108.  
        109. // 이것이 제대로 작동하려면 기반 클래스, 즉
        110. // Investment의 소멸자가 가상 소멸자이어야 한다.
        111.  
        112.  
        113. //-----------------------------------------------------------------------------
        114. // C++14는 함수 반환 타입의 추론을 지원하므로
        115. // (항목 3 참고), makeInvestment를 다음과 같이
        116. // 좀 더 간결하고 캡슐화된 방식으로 구현할 수 있다.
        117.  
        118. template <typename... Ts>
        119. auto makeInvestment(Ts&&... params) // C++14
        120. {
        121. auto delInvmt = [](Investment* pInvestment) // 이제는 make-
        122. { // Investment의
        123. makeLogEntry(pInvestment); // 내부에서
        124. delete pInvestment; // 삭제자를 정의
        125. };
        127. std::unique_ptr<Investment, decltype(delInvmt)> // 이전과 동일
        128. pInv(nullptr, delInvmt);
        130. if ( ... ) // 이전과 동일
        131. {
        132. pInv.reset(new Stock(std::forward<Ts>(params)...));
        133. }
        134. else if ( ... ) // 이전과 동일
        135. {
        136. pInv.reset(new Bond(std::forward<Ts>(params)...));
        137. }
        138. else if ( ... ) // 이전과 동일
        139. {
        140. pInv.reset(new RealEstate(std::forward<Ts>(params)...));
        141. }
        143. return pInv; // 이전과 동일
        144. }
        145.  
        146.  
        147. //-----------------------------------------------------------------------------
        148. // 기본 삭제자(즉 delete)를 사용할 때에는
        149. // std::unique_ptr객체의 크기는 생 포인터의 크기와
        150. // 같다고 가정하는 것이 합당하다.
        151.  
        152. // 그러나 커스텀 삭제자를 사용하면 상황이 달라진다.
        153.  
        154. // 일반적으로, 함수 포인터를 삭제자로 지정한 경우에는
        155. // std::unique_ptr의 크기가 1 워드에서 2 워드로
        156. // 증가한다.
        157.  
        158. // 삭제자가 함수 객체일 때에는 std::unique_ptr의
        159. // 크기가 그 함수 객체에 저장된 상태의
        160. // 크기만큼 증가한다.
        161.  
        162. // 상태 없는 함수 객체(이를테면 갈무리 없는 람다
        163. // 표현식이 산출한)의 경우에는 크기 변화가
        164. // 없으며, 따라서 가능하면 람다 표현식을 선호하는
        165. // 것이 바람직하다.
        166.  
        167. auto delInvmt1 = [](Investment* pInvestment) // 상태 없는
        168. { // 람다 형태의
        169. makeLogEntry(pInvestment); // 삭제자
        170. delete pInvestment;
        171. }
        172.  
        173. template <typename... Ts> // 반환 타입은
        174. std::unique_ptr<Investment, decltype(delInvmt1)> // Investment*와
        175. makeInvestment(Ts&&... args); // 같은 크기
        176.  
        177. void delInvmt2(Investment* pInvestment) // 함수 형태의
        178. { // 삭제자
        179. makeLogEntry(pInvestment);
        180. delete pInvestment;
        181. }
        182.  
        183. template <typename... Ts> // 반환 타입의 크기는
        184. std::unique_ptr<Investment, // Investment*의 크기에
        185. void (*)(Investment*)> // 적어도 함수 포인터의
        186. makeInvestment(Ts&&... params); // 크기를 더한 것임!
        187.  
        188. // 상태가 많은 함수 객체를 사용한다면
        189. // std::unique_ptr의 크기가 상당히
        190. // 커질 수 있다.

        
        
        예제 코드 접기
        
        
        

      • std::unique_ptr를 std::shared_ptr로 손쉽게 변환할 수 있다.

        팩터리 함수는 자신이 돌려준 객체를 호출자가 독점적으로 소유하려 하는지, 아니면 소유권을 공유하고자 하는지(std::shared_ptr에 해당) 미리 알 수 없다. 팩터리 함수가 std::unique_ptr를 반환한다면 호출자는 가장 효율적인 스마트 포인터를 얻게 되며, 상황에 따라 std::shared_ptr로 변환하여 쓸 수도 있다.
        
        다음은 makeInvestment가 반환한 std::unique_ptr를 std::shared_ptr로 변환하는 코드이다.
        
        std::shared_ptr<Investment> sp =
        makeInvestment( 인수들 );
        
        하지만 반대로 std::shared_ptr을 std::unique_ptr로 변환하는 것은 불가능하다.

  19. 소유권 공유 자원의 관리에는 std::shared_ptr를 사용하라 / 134

      • std::shared_ptr는 임의의 공유 자원의 수명을 편리하게(가비지 컬렉션에 맡길 때만큼이나) 관리할 수 있는 수단을 제공한다.

        std::shared_ptr가 할 수 없는 일로는 배열 관리가 있다. std::unique_ptr와는 다르게, std::shared_ptr의 API는 단일 객체를 가리키는 포인터만 염두에 두고 설계되었다.
        
        std::shared_ptr<T>로 배열을 가리키되, 배열 삭제를 수행하는 커스텀 삭제자를 지정하면 되지 않겠느냐는 발상을 할 수도 있다. 그런 코드가 컴파일되긴 하지만, 그리 좋은 발상은 아니다.
        
        한 가지 이유는, std::shared_ptr는 operator[]를 제공하지 않는다는 것이다. 또 다른 이유로, std::shared_ptr가 지원하는 파생 클래스 포인터에서 기반 클래스 포인터로의 변환은 단일 객체에는 합당하지만, 배열에 적용하면 타입 시스템에 구멍이 생긴다(그래서 std::unique_ptr<T[]> API는 그러한 변환을 금지한다).
        
        가장 중요하게는, C++11은 내장 배열에 대한 다양한 대안들(이를테면 std::array나 std::vector, std::string)을 제공하며, 따라서 멍청한(dumb) 배열을 가리키는 스마트 포인터를 선언한다는 것은 거의 항상 나쁜 설계의 징조이다.

      • 대체로 std::shared_ptr 객체는 그 크기가 std::unique_ptr 객체의 두 배이며, 제어 블록에 관련된 추가 부담을 유발하며, 원자적 참조 카운트 조작을 요구한다.

        어떤 객체를 가리키는 마지막 std::shared_ptr가 객체를 더 이상 가리키지 않게 되면, 그 std::shared_ptr는 자신이 가리키는 객체를 파괴한다.
        
        그런데 std::shared_ptr는 자신이 객체를 가리키는 최후의 공유 포인터임을 어떻게 알까? 그 비결은 바로 자원의 참조 카운트(reference count)에 있다. 참조 카운트는 관리되는 자원에 연관된 값으로, 그 자원을 가리키는 std::shared_ptr들의 개수에 해당한다.
        
        이러한 참조 카운트 관리는 성능에 다음과 같은 영향을 미친다.
        
        
        • std::shared_ptr의 크기는 생 포인터의 두 배이다. 내부적으로 자원을 가리키는 생 포인터뿐만 아니라 자원의 참조 카운트를 가리키는 생 포인터도 저장해야 하기 때문이다.
        • 참조 카운트를 담을 메모리를 반드시 동적으로 할당해야 한다. 개념적으로는 참조 카운트는 공유 포인터가 가리키는 객체에 연관된 것이지만, 그 객체 자제는 참조 카운트를 전혀 알지 못한다. 따라서 객체는 참조 카운트를 담을 장소를 따로 마련하지 않는다. 항목 21에서 설명하겠지만, std::make_shared를 이용해서 std::shared_ptr를 생성하면 동적 할당의 비용을 피할 수 있다. 그러나 std::make_shared를 사용할 수 없는 상황들도 존재한다. 어떤 경우이든, 참조 카운트는 동적으로 할당된 데이터로서 저장된다.
        • 참조 카운트의 증가와 감소가 반드시 원자적 연산이어야 한다. 여러 스레드가 참조 카운트를 동시에 읽고 쓰려 할 수 있기 때문이다. 예를 들어 어떤 자원을 가리키는 어떤 std::shared_ptr의 소멸자가 한 스레드에서 실행되는(그래서 그것이 가리키는 자원의 참조 카운트를 감소하는) 도중에 다른 어떤 스레드에서 같은 자원을 가리키는 std::shared_ptr가 복사될(그래서 같은 참조 카운트가 증가할) 수도 있다. 대체로 원자적 연산은 비원자적 연산보다 느리므로, 비록 참조 카운트가 워드 하나 크기라고 해도 그것을 읽고 쓰는 연산이 비교적 느릴 것이라고 가정해야 마땅하다.
        보통 std::shared_ptr의 생성자는 피지칭 객체의 참조 카운트를 1 만큼 증가시키는데, 그렇지 않은 경우도 있다. 바로 이동 생성이 일어날 때이다.
        
        이것은 이동 대입이 일어날 때에도 마찬가지인데, 참조 카운트를 조작하지 않기 때문에(즉, 원자적 연산을 수행하지 않기 때문에) 복사 연산보다 이동 연산이 더 빠르다.

      • 자원은 기본적으로 delete를 통해 파괴되나, 커스텀 삭제자도 지원된다. 삭제자의 타입은 std::shared_ptr의 타입에 아무런 양향도 미치지 않는다.

        삭제자를 지원하는 구체적인 방식은 std::unique_ptr의 것과 다르다. std::unique_ptr에서는 삭제자의 타입이 스마트 포인터의 타입의 일부였지만, std::shared_ptr에서는 그렇지 않다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. auto loggingDel = [](Widget *pw) // 커스텀 삭제자
        3. { // (항목 18의 것과 같음)
        4. makeLogEntry(pw);
        5. delete pw;
        6. }
        7.  
        8. std::unique_ptr< // 삭제자의 타입이
        9. Widget, decltype(loggingDel) // 포인터 타입의 일부임
        10. > upw(new Widget, loggingDel);
        11.  
        12. std::shared_ptr<Widget> // 삭제자의 타입이
        13. spw(new Widget, loggingDel); // 포인터 타입의 일부가 아님
        14.  
        15.  
        16. //-----------------------------------------------------------------------------
        17. // std::shared_ptr의 설계가 더 유연하다.
        18.  
        19. // 사용하는 커스텀 삭제자의 타입이 서로 다른
        20. // 두 pw1과 pw2는 같은 타입이므로, 그 타입의
        21. // 객체들을 담는 컨테이너 안에 집어넣을 수 있다.
        22.  
        23. std::vector<std::shared_ptr<Widget> > vpw{ pw1, pw2 }
        24.  
        25. // 또한, 하나를 다른 하나에 대입할 수도 있고,
        26. // 둘 다 std::shared_ptr<Widget> 타입의
        27. // 매개변수를 받는 함수에 넘겨줄 수 있다.
        28.  
        29. // 그러나, 커스텀 삭제자 타입이 다른 두
        30. // std::unique_ptr에서는 이런 일이 불가능하다.

        
        
        예제 코드 접기
        
        
        std::unique_ptr와의 또 다른 차이점은, 커스텀 삭제자를 지정해도 std::shared_ptr 객체의 크기가 변하지 않는다는 점이다. 커스텀 삭제자는 std::shared_ptr 객체가 아니라, 제어 블록에 담긴다.
        
        앞에서 std::shared_ptr 객체가 자신이 가리키는 객체에 대한 참조 카운트를 가리키는 포인터도 담는다고 했다. 그 말이 틀린 것은 아니지만, 오해의 소지가 있다. 사실 참조 카운트는 제어 블록(control block)이라고 부르는 더 큰 자료구조의 일부이다.
        
        std::shared_ptr가 관리하는 객체당 하나의 제어 블록이 존재한다. std::shared_ptr 생성 시 커스텀 삭제자를 지정했다면, 참조 카운트와 함께 그 커스텀 삭제자의 복사본이 제어 블록에 담긴다.
        
        커스텀 할당자를 지정했다면 그 할당자의 복사본도 제어 블록에 담긴다. 그 외에도 제어 블록에는 약한 카운트(항목 21 참고)라고 부르는 이차적인 참조 카운트가 포함되며 그밖의 추가 데이터가 포함될 수 있으나, 일단 지금은 그런 추가 데이터의 존재를 무시하기로 한다.

      • 생 포인터 타입의 변수로부터 std::shared_ptr를 생성하는 일은 피해야 한다.

        제어 블록의 생성 여부에 관해 다음과 같은 규칙들을 유추할 수 있다.
        
        
        • std::make_shared(항목 21 참고)는 항상 제어 블록을 생성한다. 이 함수는 공유 포인터가 가리킬 객체를 새로 생성하므로, std::make_shared가 호출되는 시점에서 그 객체에 대한 제어 블록이 이미 존재할 가능성은 전혀 없다.
        • 고유 소유권 포인터(즉, std::unique_ptr나 std::auto_ptr)로부터 std::shared_ptr 객체를 생성하면 제어 블록이 생성된다. 고유 소유권(unique-ownership) 포인터는 제어 블록을 사용하지 않으므로, 피지칭 객체에 대한 제어 블록이 이미 존재할 가능성은 전혀 없다(생성 과정에서 std::shared_ptr 객체는 피지칭 객체의 소유권을 획득하므로, 고유 소유권 포인터는 널로 설정된다).
        • 생 포인터로 std::shared_ptr 생성자를 호출하면 제어 블록이 생성된다. 이미 제어 블록이 있는 객체로부터 std::shared_ptr를 생성하고 싶다면, 생 포인터가 아니라 std::shared_ptr나 std::weak_ptr(항목 20 참고)를 생성자의 인수로 지정하면 된다. std::shared_ptr나 std::weak_ptr를 받는 std::shared_ptr 생성자들은 새 제어 블록을 만들지 않는다. 전달된 스마트 포인터들이 이미 필요한 제어 블록을 가리키고 있을 것이기 때문이다.
        
        
        이 규칙에서 비롯되는 한 가지 결과는, 하나의 생 포인터로 여러 개의 std::shared_ptr를 생성하면 피지칭 객체에 여러 개의 제어 블록이 만들어지므로, 의문의 여지 없이 미정의 행동이 된다는 점이다.
        
        제어 블록이 여러 개라는 것은 참조 카운트가 여러 개라는 뜻이며, 참조 카운트가 여러 개라는 것은 해당 객체가 여러 번 파괴된다는 뜻이다(참조 카운트마다 한 번씩).
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. auto pw = new Widget; // pw는 생 포인터
        3.  
        4. ...
        5.  
        6. std::shared_ptr<Widget> spw1(pw, loggingDel); // *pw에 대한 제어
        7. // 블록이 생성됨
        8. ...
        9.  
        10. std::shared_ptr<Widget> spw2(pw, loggingDel); // *pw에 대한
        11. // 두 번째 제어
        12. // 블록이 생성됨
        13.  
        14. // 이러한 잘못된 용법에서 배울 점이 두 가지 있다.
        15.  
        16. // 첫째로, std::shared_ptr 생성자에 생
        17. // 포인터를 넘겨주는 일은 피하라는 것이다.
        18.  
        19. // 흔히 쓰이는 대안은 std::make_shared
        20. // (항목 21 참고)를 사용하는 것이다.
        21.  
        22. // 하지만 지금 예에서처럼 커스텀 삭제자를
        23. // 사용하는 경우에는 std::make_shared를
        24. // 사용할 수 없다.
        25.  
        26. // 둘째로, std::shared_ptr 생성자를
        27. // 생 포인터로 호출할 수밖에 없는
        28. // 상황이라면, 생 포인터의 변수를
        29. // 거치지 말고 new의 결과를 직접
        30. // 전달하라는 것이다.
        31.  
        32. // 앞의 예제 코드의 첫 부분을
        33. // 다음과 같이 고친다면,
        34.  
        35. std::shared_ptr<Widget> spw1(new Widget, // new를 직접 사용
        36. loggingDel);
        37.  
        38. // 같은 생 포인터로 또 다른 std::shared_ptr를
        39. // 생성하려는 유혹에 빠질 염려가 없다.
        40.  
        41. // spw1이 가리키는 Widget 객체를 가리키는
        42. // std::shared_ptr를 만들고 싶다면 다음과
        43. // 같이 하면 된다.
        44.  
        45. std::shared_ptr<Widget> spw2(spw1); // spw2는 spw1과 동일한
        46. // 제어 블록을 사용한다.
        47.  
        48.  
        49. //-----------------------------------------------------------------------------
        50. // 생 포인터 변수를 std::shared_ptr 생성자의
        51. // 인수로 사용했기 때문에 제어 블록이 여러 개
        52. // 만들어지는 문제에 this 포인터가 관여하면
        53. // 특히나 놀라운 결과가 빚어진다.
        54.  
        55. // std::shared_ptr들을 이용해서 Widget 객체들을
        56. // 관리한다고 하자.
        57.  
        58. // 그리고 처리가 끝난 Widget 들을 다음과 같은
        59. // 자료구조를 이용해서 추적한다고 하자.
        60.  
        61. std::vector<std::shared_ptr<Widget> > processedWidgets;
        62.  
        63. // 더 나아가서, Widget에 어떤 처리 작업을 수행하는
        64. // process라는 멤버 함수가 있다고 하자.
        65.  
        66. class Widget {
        67. public:
        68. ...
        69. void process(void);
        70. ...
        71. };
        72.  
        73. void Widget::process(void)
        74. {
        75. ... // 이 Widget을 처리
        77. processedWidgets.emplace_back(this); // 이 Widget을 처리된
        78. } // Widget들의 목록에 추가
        79. // 잘못된 방식임!
        80.  
        81. // 이 코드는 컴파일 되지만, 생 포인터(this)를
        82. // std::shared_ptr들의 컨테이너에 넘겨준다는
        83. // 문제점이 있다.
        84.  
        85. // 이에 의해 std::shared_ptr 객체가 생성되면서,
        86. // 피지칭 Widget 객체(즉 *this)에 대한
        87. // 새 제어 블록이 만들어진다.
        88.  
        89. // 만일 멤버 함수 바깥에 이미 그 Widget을
        90. // 가리키는 다른 std::shared_ptr들이 있다면,
        91. // 필연적으로 미정의 행동이 발생한다.
        92.  
        93. // 이런 상황들에 대처하기 위해 std::shared_ptr API
        94. // 에는, std::enable_shared_from_this라는 템플릿이
        95. // 포함되어 있다.
        96.  
        97. // std::shared_ptr로 관리하는 클래스를 작성할 때,
        98. // 그 클래스의 this 포인터로부터 std::shared_ptr를
        99. // 안전하게 생성하려면 이 템플릿을 그 클래스의
        100. // 기반 클래스로 삼으면 된다.
        101.  
        102. class Widget: public std::enable_shared_from_this<Widget> {
        103. public:
        104. ...
        105. void process(void);
        106. ...
        107. };
        108.  
        109. // 파생 클래스가 파생 클래스 자신을 타입
        110. // 인수로 해서 인스턴스화한 기반 클래스를
        111. // 상속 받고 있다.
        112.  
        113. // 이러한 방식을 "묘하게 되풀이되는 템플릿 패턴
        114. // (Curiously Recurring Template Pattern, CRTP)"
        115. // 라고 한다(이에 관해 더 알고싶다면 웹을
        116. // 검색해 보길 바란다).
        117.  
        118. // std::enable_shared_from_this는 현재
        119. // 객체를 가리키는 std::shared_ptr를
        120. // 생성하되 제어 블록이 중복되지 않도록
        121. // 하는 멤버 함수 shared_from_this를
        122. // 정의한다.
        123.  
        124. // 다음은 이를 사용한 Widget::process의
        125. // 안전한 구현이다.
        126.  
        127. void Widget::process(void)
        128. {
        129. // 이전과 마찬가지로 Widget을 처리
        130. ...
        132. // 현재 객체를 가리키는 std::shared_ptr를 processedWidgets에 추가
        133. processedWidgets.emplace_back(shared_from_this());
        134. }
        135.  
        136. // 내부적으로 shared_from_this는 현재 객체에
        137. // 대한 제어 블록을 조회하고, 그 제어
        138. // 블록을 지칭하는 새 std::shared_ptr를
        139. // 생성한다.
        140.  
        141. // 이는 곧, 현재 객체를 가리키는 기존의
        142. // std::shared_ptr가 반드시 존재한다는
        143. // 가정에 해당한다.
        144.  
        145. // 그런 std::shared_ptr가 존재하지 않는다면
        146. // 함수의 행동은 정의되지 않는다.
        147.  
        148. // std::shared_ptr가 유효한 객체를 가리키기도
        149. // 전에 클라이언트가 shared_from_this를 호출하는
        150. // 일을 방지하기 위해, std::enable_shared_from_this를
        151. // 상속받은 클래스는 자신의 생성자들을 private로
        152. // 선언한다.
        153.  
        154. // 그리고 클라이언트가 객체를 생성할 수 있도록,
        155. // std::shared_ptr를 돌려주는 팩터리 함수를
        156. // 제공한다.
        157.  
        158. class Widget: public std::enable_shared_from_this<Widget> {
        159. public:
        160. // 팩터리 함수; 인수들을 전용 생성자에
        161. // 완벽하게 전달한다.
        162. template <typename... Ts>
        163. static std::shared_ptr<Widget> create(Ts&&... params);
        165. ...
        166. void process(void); // 이전과 동일
        167. ...
        169. private:
        170. ... // 생성자들
        171. };

        
        
        예제 코드 접기
        
        
        std::unique_ptr에 비해 std::shared_ptr가 더 많은 비용이 들지만, 그리 크지 않은 비용을 치르는 대신, 동적 할당 자원의 수명이 자동으로 관리된다는 이득이 생긴다.
        
        독점 소유권으로도 충분하거나, 심지어는 반드시 충분하지는 않더라도 충분할 가능성이 있다면, std::unique_ptr가 더 나은 선택이다. std::unique_ptr의 성능은 생 포인터의 것에 가까우며, 언제라도 std::unique_ptr를 std::shared_ptr로 '업그레이드'하기도 쉽다.
        
        하지만 반대로, std::shared_ptr를 std::unique_ptr로 바꾸는 것은 불가능하다.

  20. std::shared_ptr처럼 작동하되 대상을 잃을 수도 있는 포인터가 필요하면 std::weak_ptr를 사용하라 / 145

      • std::shared_ptr처럼 작동하되 대상을 잃을 수도 있는 포인터가 필요하면 std::weak_ptr를 사용하라.

        대체로 std::weak_ptr는 std::shared_ptr를 이용해서 생성한다. std::weak_ptr는 자신을 생성하는 데 쓰인 std::shared_ptr가 가리키는 것과 동일한 객체를 가리키나, 그 객체의 참조 카운트에는 영향을 주지 않는다.
        
        대상을 잃은 std::weak_ptr를 가리켜 만료되었다(expired)라고 말한다. std::weak_ptr의 만료 여부는 멤버 함수 expired가 돌려주는 값으로 판단할 수 있다.
        
        만료되지 않은 std::weak_ptr이라고 해도 피지칭 객체에 직접 접근하는 것은 불가능하다. std::weak_ptr에는 역참조 연산이 없기 때문이다.
        
        역참조 연산이 가능하도록 하더라도, 만료 점검과 참조를 분리하면 경쟁 조건이 발생할 수 있다. 즉, expired 호출과 역참조 사이에서 다른 어떤 스레드가 해당 객체를 가리키는 마지막 std::shared_ptr를 재대입 또는 파괴할 수도 있기 때문이다. 그러면 해당 객체가 파괴되며, 포인터를 역참조하면 미정의 행동이 나온다.
        
        제대로 된 용법은, std::weak_ptr로부터 std::shared_ptr를 생성하여 사용하는 것이다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // std::weak_ptr는 std::shared_ptr로부터
        3. // 얻을 수 있다.
        4.  
        5. auto spw = // spw가 생성된 후, 피지칭
        6. std::make_shared<Widget>(); // Widget의 참조 카운트(이하
        7. // 간단히 카운트)는 1이다
        8. // (std::make_shared에
        9. // 관해서는 항목 21을 보라).
        10. ...
        11.  
        12. std::weak_ptr<Widget> wpw(spw); // wpw는 spw와 같은 Widget을
        13. // 가리킨다; 카운트는 여전히 1이다.
        14. ...
        15.  
        16. spw = nullptr; // 카운트가 0이 되고 Widget이
        17. // 파괴된다; 이제 wpw는
        18. // 대상을 잃은 상태이다.
        19.  
        20.  
        21. //-----------------------------------------------------------------------------
        22. // std::weak_ptr가 만료되었는지 알고 싶으면,
        23. // expired 멤버 함수가 돌려주는 값을
        24. // 점검하면 된다.
        25.  
        26. if (wpw.expired()) ... // wpw가 객체를
        27. // 가리키지 않으면...
        28.  
        29.  
        30. //-----------------------------------------------------------------------------
        31. // std::weak_ptr가 가리키는 피지칭 객체를
        32. // 역참조 하려면 std::weak_ptr로부터
        33. // std::shared_ptr를 얻고 그
        34. // std::shared_ptr을 역참조한다.
        35.  
        36. // 방법 1: lock 멤버 함수를 사용한다.
        37.  
        38. std::shared_ptr<Widget> spw1 = wpw.lock(); // wpw가 만료이면
        39. // spw1은 널
        40.  
        41. auto spw2 = wpw.lock(); // 위와 동일하나
        42. // auto를 사용했음
        43.  
        44. // 방법 2: std::shared_ptr의 생성자에
        45. // std::weak_ptr를 넘겨준다.
        46.  
        47. std::shared_ptr<Widget> spw3(wpw); // wpw가 만료이면 std::
        48. // bad_weak_ptr(예외)가 발생
        49.  

        
        
        예제 코드 접기
        
        
        효율성 면에서 std::weak_ptr는 std::shared_ptr와 본질적으로 동일하다.
        
        std::weak_ptr 객체는 그 크기가 std::shared_ptr 객체와 같으며, std::shared_ptr가 사용하는 것과 같은 제어 블록(항목 19 참고)을 사용하며, 생성이나 파괴, 대입 같은 연산에 원자적 참조 카운트 조작이 관여한다.
        
        앞에서 std::weak_ptr가 참조 카운트 관리에 관여하지 않는다고 말한 것과 모순인 것처럼 보일 것이다.사실 앞에서 조금 모호하게 말했는데 정확하게 말하자면 이렇다. std::weak_ptr는 객체의 소유권 공유에 참여하지 않으며, 따라서 피지칭 객체의 참조 카운트에 영향을 미치지 않는다.
        
        앞에서 언급했듯이 제어 블록에는 '두 번째' 참조 카운트가 있으며 그것이 std::weak_ptr가 조작하는 참조 카운트이다.

      • std::weak_ptr의 잠재적인 용도로는 캐싱, 관찰자 목록, 그리고 std::shared_ptr 순환 고리 방지가 있다.

        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 어떤 팩터리 함수가, 주어진 고유 ID에 해당하는
        3. // 읽기 전용 객체를 가리키는 스마트 포인터를
        4. // 돌려준다고 하자.
        5.  
        6. // 팩터리 함수의 반환 타입에 관한 항목 18의
        7. // 조언에 따라, 그 팩터리 함수는 std::unique_ptr를
        8. // 돌려준다.
        9.  
        10. std::unique_ptr<const Widget> loadWidget(WidgetID id);
        11.  
        12. // 이 loadWidget의 비용이 크다고 하자.
        13.  
        14. // 그리고 ID들이 되풀이해서 쓰이는 경우가
        15. // 많다고 하자.
        16.  
        17. // 그렇다면 loadWidget과 같은 일을 하되
        18. // 호출 결과들을 캐싱하는 함수를 작성하여
        19. // 최적화를 할 수 있을 것이다.
        20.  
        21. // 그런데 요청된 모든 Widget을 캐시에
        22. // 담아 둔다면 그 자체로 성능상의 문제가
        23. // 발생할 것이므로, 더 이상 쓰이지 않는
        24. // Widget은 캐시에서 삭제하는 것이
        25. // 자연스럽다.
        26.  
        27. // 이러한 캐시 적용 팩터리 함수의 반환
        28. // 타입을 std::unique_ptr로 두는 것은
        29. // 그리 바람직하지 않다.
        30.  
        31. // 호출자가 캐싱된 객체를 가리키는 스마트
        32. // 포인터를 받아야 한다는 점은 확실하며,
        33. // 그 객체들의 수명을 호출자가 결정할 수
        34. // 있어야 한다는 점도 확실하다.
        35.  
        36. // 캐시에 있는 포인터들은 자신이 대상을
        37. // 잃었음을 검출할 수 있어야 한다.
        38.  
        39. // 따라서 캐시에 저장할 포인터는 자신이
        40. // 대상을 잃었음을 감지할 수 있는 포인터,
        41. // 즉 std::weak_ptr이어야 한다.
        42.  
        43. // 이는 팩터리 함수의 반환 타입이 반드시
        44. // std::shared_ptr이어야 함을 뜻한다.
        45.  
        46. // 다음은 loadWidget의 캐싱 버전이다.
        47.  
        48. std::shared_ptr<const Widget> fastLoadWidget(WidgetID id)
        49. {
        50. static std::unordered_map<WidgetID,
        51. std::weak_ptr<const Widget> > cache;
        53. auto objPtr = cache[id].lock(); // objPtr는 캐시에 있는 객체를
        54. // 가리키는 std::shared_ptr
        55. // (단, 객체가 캐시에 없으면 널)
        57. if (!objPtr) { // 캐시에 없으면
        58. objPtr = loadWidget(id); // 적재하고
        59. cache[id] = objPtr; // 캐시에 저장
        60. }
        62. return objPtr;
        63. }
        64.  
        65. // 이 코드가 제대로 작동하려면 WidgetID를 해싱하는
        66. // 함수와 상등을 비교하는 함수도 지정해야 하지만,
        67. // 그 부분은 생략했다.
        68.  
        69. // 이 fastLoadWidget 구현은 더 이상
        70. // 쓰이지 않는(따라서 파괴된) Widget들에
        71. // 해당하는 만료된 std::weak_ptr들이
        72. // 캐시에 누적될 수 있다는 사실을 무시한다.
        73.  
        74. // 그 부분을 좀 더 개선할 수도 있지만, 지금의
        75. // std::weak_ptr 논의 자체에 도움이 되는 것은
        76. // 아니므로 이 정도로 마무리한다.
        77.  
        78.  
        79. //-----------------------------------------------------------------------------
        80. // std::weak_ptr가 유용하게 쓰이는 두 번째
        81. // 사례는 관찰자(Observer) 설계 패턴이다.
        82.  
        83. // 이 패턴의 주된 구성 요소는 관찰 대상(subject;
        84. // 상태가 변할 수 있는 객체)과 관찰자(observer;
        85. // 상태 변화를 통지받는 객체)이다.
        86.  
        87. // 대부분의 관찰자 패턴 구현에서, 각 관찰
        88. // 대상 객체에는 자신의 관찰자들을 가리키는
        89. // 포인터들을 담은 데이터 멤버가 있다.
        90.  
        91. // 이런 데이터 멤버가 있으면 상태 변화를
        92. // 관찰자들에게 손쉽게 통지할 수 있다.
        93.  
        94. // 관찰 대상은 관찰자들의 수명을 제어하는
        95. // 데에는 관심이 없지만, 자신이 파괴된
        96. // 관찰자에 접근하는 일이 없도록 보장하는
        97. // 데에는 관심이 아주 많다.
        98.  
        99. // 그러한 관찰 대상에 합당한 설계 하나는,
        100. // 관찰자들을 가리키는 std::weak_ptr들의
        101. // 컨테이너를 데이터 멤버로 두는 것이다.
        102.  
        103. // 그러면 먼저 만료 여부를 보고 관찰자가
        104. // 유효한지 점검한 후에 관찰자에 접근할
        105. // 수 있다.
        106.  
        107.  
        108. //-----------------------------------------------------------------------------
        109. // std::weak_ptr가 유용한 마지막 예로,
        110. // 객체 A, B, C로 이루어진 자료구조에서 A와
        111. // C가 B의 소유권을 공유하는, 그래서 B를
        112. // 가리키는 std::shared_ptr를 가지고
        113. // 있는 상황을 생각해 보자.
        114.  
        115.  
        116. // 　　　　　std::shared_ptr　　　　　　　std::shared_ptr
        117. // [ A ]----------------------→[ B ]←----------------------[ C ]
        118.  
        119.  
        120. // 그런데 B에서 다시 A를 가리키는 포인터가
        121. // 필요하게 되었다고 하자.
        122.  
        123. // 그 포인터는 어떤 종류의 포인터이어야 할까?
        124.  
        125.  
        126. // 　　　　　std::shared_ptr　　　　　　　std::shared_ptr
        127. // [ A ]----------------------→[ B ]←----------------------[ C ]
        128. // 　↖__________________________/
        129. // 　　　　　　???
        130.  
        131.  
        132. // 선택은 세 가지이다.
        133.  
        134. // 1. 생 포인터. --------------------------------
        135. // 이 접근방식에는 만일 C가 여전히 B를
        136. // 가리키고 있는 상황에서 A가 파괴되면,
        137. // B가 가진 포인터(A를 가리키는)는 대상을
        138. // 잃게 되나, B는 그 사실을 알지 못한다.
        139.  
        140. // 따라서 B가 대상을 잃은 포인터를 의도치
        141. // 않게 역참조해서 미정의 행동이 발생할 수
        142. // 있다.
        143.  
        144. // 2. std::shared_ptr. --------------------------
        145. // 이 설계에서 A와 B는 서로를 가리키는
        146. // std::shared_ptr들을 가진다.
        147.  
        148. // 그러면 std::shared_ptr들의 순환 고리가
        149. // 생기며, 결과적으로 A와 B 둘 다 파괴되지
        150. // 못한다.
        151.  
        152. // 프로그램의 다른 자료구조에서 A와 B에
        153. // 접근할 수 없게 된다고 해도, 둘의 참조
        154. // 카운트는 여전히 1이다.
        155.  
        156. // 그런 일이 생기면, A와 B는 사실상
        157. // 누수가 일어난 것이라 할 수 있다.
        158.  
        159. // 프로그램이 둘에 접근할 수 없으므로,
        160. // 해당 자원들을 재확보할 수도 없다.
        161.  
        162. // 3. std::weak_ptr. ----------------------------
        163. // 이 경우에는 앞의 두 문제 모두 해결된다.
        164.  
        165. // A가 파괴되면 A를 가리키는 B의 포인터가
        166. // 대상을 잃지만, B는 그 사실을 알 수
        167. // 있다.
        168.  
        169. // 비록 A와 B가 서로를 가리키지만,
        170. // B의 포인터는 A의 참조 카운트에 영향을
        171. // 미치지 않으며, 따라서 std::shared_ptr들이
        172. // 더 이상 A를 가리키지 않게 되면 A가
        173. // 정상적으로 파괴된다.
        174.  
        175.  
        176. // 하지만 이런 상황은 흔히 있는 일은 아니다.

        
        
        예제 코드 접기
        
        
        

  21. new를 직접 사용하는 것보다 std::make_unique와 std::make_shared를 선호하라 / 150

      • new의 직접 사용에 비해, make 함수를 사용하면 소스 코드 중복의 여지가 없어지고, 예외 안전성이 향상되고, std::make_shared와 std::allocate_shared의 경우 더 작고 빠른 코드가 산출된다.

        std::make_shared는 C++11의 일부이지만, std::make_unique는 C++14에서야 표준 라이브러리에 포함되었다. 하지만 C++11 환경에서 make_unique와 같은 일을 하는 함수 템플릿을 만드는 것은 어렵지 않다.
        
        직접 구현한 make_unique 함수 예제 코드 보기
        
        
        

        1. // C++11 환경에서는 std::make_unique가
        2. // 표준에 포함되지 않았지만, 아쉬운 대로
        3. // 직접 만들어 쓸 수 있다.
        4.  
        5. template <typename T, typename... Ts>
        6. std::unique_ptr<T> make_unique(Ts&&... params)
        7. {
        8. return std::unique_ptr<T>(new T(std::forward<Ts>(params)...));
        9. }
        10.  
        11. // 완전한 기능을 갖춘 make_unique를 최대한
        12. // 쉽게 만들어 내는 한 가지 방법은 make_unique의
        13. // 표준화에 쓰인 제안 문서를 찾아서 거기에
        14. // 나온 구현을 복사해 쓰는 것이다.
        15.  
        16. // 그 문서는 스테픈 T. 라와웨이드(Stephan T. Lavavej)
        17. // 가 작성한 N3656(2013년 4월 18일자)이다.
        18.  
        19. // 한 가지 주의할 점은, 직접 만든 구현을 std
        20. // 이름공간에 집어넣지는 말아야 한다.

        
        
        직접 구현한 make_unique 함수 예제 코드 접기
        
        
        std::make_unique와 std::make_shared는 임의의 개수와 타입을 인수들을 받아서 그것들을 생성자로 완벽 전달해서 객체를 동적으로 생성하고, 그 객체를 가리키는 스마트 포인터를 돌려주는 세 가지 make함수 중 둘이다.
        
        나머지 하나는 std::allocate_shared이다. 이 함수는 std::make_shared처럼 작동하되, 첫 인수가 동적 메모리 할당에 쓰일 할당자 객체라는 점이 다르다.
        
        스마트 포인터를 new를 사용해서 생성할때는 생성하려는 객체의 타입을 두 번 입력(즉 코드 중복)해야 하지만, make 함수를 사용하면 한 번만 입력하면 된다.
        
        코드 중복 예제 코드 보기
        
        
        

        1. auto upw1(std::make_unique<Widget>()); // make 함수를 사용
        2.  
        3. std::unique_ptr<Widget> upw2(new Widget); // 사용하지 않음
        4.  
        5. auto spw1(std::make_shared<Widget>()); // make 함수를 사용
        6.  
        7. std::shared_ptr<Widget> spw2(new Widget); // 사용하지 않음
        8.  
        9. // make 함수를 사용하지 않는 경우에는
        10. // 코드에서 Widget이 두 번 등장한다.
        11.  
        12. // 코드가 중복되고 있는 것이다.
        13.  
        14. // 당연히 소스 코드 중복은 피하는 것이 좋다.

        
        
        코드 중복 예제 코드 접기
        
        
        make 함수를 사용하면 그렇지 않을 때보다 예외 안전성이 향상되는 효과도 있다.
        
        예외 안전성 향상 예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 어떤 Widget 객체를 그 객체의 우선순위에
        3. // 따라 적절히 처리하는 함수가 있다고 하자.
        4.  
        5. void processWidget(std::shared_ptr<Widget> spw, int priority);
        6.  
        7. // std::shared_ptr을 값으로 전달하고 있는데
        8. // 이것에 관한 자세한 내용은 항목 41에서 보기 바란다.
        9.  
        10. // 다음으로, 우선순위를 다음과 같은
        11. // 함수로 계산한다고 하자.
        12.  
        13. int computePriority(void);
        14.  
        15. // 그리고 std::make_shared 대신 new를 사용한
        16. // processWidget 호출에서 이 함수를 사용한다고
        17. // 하자.
        18.  
        19. processWidget(std::shared_ptr<Widget>(new Widget), // 자원 누수
        20. computePriority()); // 위험이
        21. // 있음!
        22.  
        23. // 이 경우 processWidget이 실행되기 전에
        24. // 다음 세 가지 작업이 수행된다.
        25.  
        26.  
        27. // 1. 표현식 "new Widget"이 평가된다.
        28. // 즉, Widget이 힙에 생성된다.
        29.  
        30. // 2. new가 산출한 포인터를 관리하는
        31. // std::shared_ptr<Widget>의 생성자가 샐행된다.
        32.  
        33. // 3. computePriority가 실행된다.
        34.  
        35.  
        36. // 문제는 1 이 2 보다 먼저 실행되어야 한다는
        37. // 점을 제외하고, 위 세 작업의 실행 순서가
        38. // 정해져 있지 않아서 컴파일러마다 순서가
        39. // 달라질 수 있다는 것이다.
        40.  
        41. // 즉 다음과 같은 순서로 실행될 수도 있다.
        42.  
        43.  
        44. // 1. 표현식 "new Widget"이 평가된다.
        45.  
        46. // 2. computePriority가 실행된다.
        47.  
        48. // 3. std::shared_ptr<Widget>의 생성자가 호출된다.
        49.  
        50.  
        51. // 이런 순서로 실행되는 경우에 computePriority에서
        52. // 예외가 발생하면 "new Widget"을 통해 할당된
        53. // 메모리가 샌다.
        54.  
        55. // 이제 make 함수를 사용하도록 고쳐 보자.
        56.  
        57. processWidget(std::make_shared<Widget>(), // 자원 누수의
        58. computePriority()); // 위험이 없음
        59.  
        60. // 이 경우 역시 std::make_shared가 먼저
        61. // 호출될 수도 있고 computePriority가 먼저
        62. // 호출될 수도 있다.
        63.  
        64. // std::make_shared가 먼저 호출되더라도
        65. // 생성된 객체는 computePriority가 호출되기
        66. // 전에 std::shared_ptr<Widget>에 담긴다.
        67.  
        68. // 따라서 computePriority 실행되는 도중
        69. // 예외가 발생해도, std::shared_ptr<Widget>의
        70. // 소멸자가 호출되어 피지칭 Widget 객체를
        71. // 안전하게 파괴한다.
        72.  
        73. // computePriority가 먼저 호출되는 경우에는
        74. // computePriority에서 예외가 발생해도
        75. // 아직 Widget 객체를 생성하기도 전이므로
        76. // 누수를 걱정할 자원이 없는 상태이다.
        77.  
        78. // std::shared_ptr와 std::make_shared를
        79. // std::unique_ptr와 std::make_unique로
        80. // 대체해도 정확히 동일한 추론이 적용된다.
        81.  
        82.  
        83. //-----------------------------------------------------------------------------
        84. // 혹시라도 std::make 함수를 사용할 수 없거나
        85. // 사용이 부적합한 상황에 부닥친다면, 이러한
        86. // 예외 안전성 문제들을 세심하게 방지할
        87. // 필요가 있다.
        88.  
        89. // new를 직접 사용하면서도 예외 안전성 문제를
        90. // 겪지 않는 최선의 방책은, new의 결과를 다른 일은
        91. // 전혀 하지 않는 문장에서 스마트 포인터의
        92. // 생성자에 즉시 넘겨주는 것이다.
        93.  
        94. // 위에서 본 예제 코드를 new를 직접 사용하면서도
        95. // 예외 안전성 문제가 없도록, 다음과 같이
        96. // 고칠 수 있다.
        97.  
        98. std::shared_ptr<Widget> spw(new Widget, cusDel);
        99.  
        100. processWidget(spw, computePriority()); // 정확하지만 최적은
        101. // 아님
        102.  
        103. // Effective C++의 항목 17에서도
        104. // 관련된 내용을 찾을 수 있다.
        105.  
        106.  
        107. // 여기서 spw를 좌측값으로 넘겨주고 있다.
        108.  
        109. // processWidget의 std::shared_ptr 매개변수는
        110. // 값 전달 방식이므로 우측값으로 전달하는 것이
        111. // 더 효율적일 것이다.
        112.  
        113. processWidget(std::move(spw), // 예외 안전성과 효율성을
        114. computePriority()); // 모두 갖춘 방식
        115.  
        116. // std::move은 spw를 우측값으로
        117. // 변환해 준다(항목 23 참고).
        118.  

        
        
        예외 안전성 향상 예제 코드 접기
        
        
        std::make_shared 함수를 사용해야 하는 또 다른 이유는 향상된 효율성이다. std::make_shared 함수를 사용하면 컴파일러가 좀 더 간결한 자료구조를 사용하는 더 작고 빠른 코드를 산출할 수 있게 된다.
        
        향상된 효율성 예제 코드 보기
        
        
        

        1. // 다음처럼 new를 직접 사용한다고 하자.
        2.  
        3. std::shared_ptr<Widget> spw(new Widget);
        4.  
        5. // 이 코드가 한 번의 메모리 할당을 실행하는 것
        6. // 처럼 보이지만, 실제로는 두 번의 할당이 일어난다.
        7.  
        8. // 항목 19에서 설명하듯이, 모든 std::shared에는
        9. // 피지칭 객체의 참조 카운트를 비롯한 여러 가지
        10. // 관리 데이터를 담는 제어 블록을 가리키는 포인터가
        11. // 있다.
        12.  
        13. // std::shared_ptr 생성자는 이 제어 블록을
        14. // 위한 메모리를 할당한다.
        15.  
        16. // 즉 new를 직접 사용해서 std::shared_ptr를
        17. // 생성하면 Widget 객체를 위한 메모리 할당과
        18. // 제어 블록을 위한 또 다른 메모리 할당이 일어난다.
        19.  
        20. // 대신 std::make_shared를 사용하면,
        21.  
        22. auto spw = std::make_shared<Widget>();
        23.  
        24. // 한 번의 할당으로 충분하다.
        25.  
        26. // 이는 std::make_shared가 Widget 객체와
        27. // 제어 블록 모두를 담을 수 있는 크기의
        28. // 메모리 조각을 한 번에 할당하기 때문이다.
        29.  
        30. // 동적 할당 횟수가 줄어들 뿐만 아니라,
        31. // 제어 블록에 일정 정도의 내부 관리용
        32. // 정보를 포함할 필요가 없어져서 프로그램의
        33. // 전체적인 메모리 사용량이 줄어들 여지가
        34. // 생긴다.
        35.  
        36. // 방금 살펴본 내용들은 std::allocate_shared에도
        37. // 거의 그대로 적용된다.

        
        
        향상된 효율성 예제 코드 접기
        
        
        

      • make 함수의 사용이 불가능 또는 부적합한 경우로는 커스텀 삭제자를 지정해야 하는 경우와 중괄호 초기치를 전달해야 하는 경우가 있다.

        make 함수에는 커스텀 삭제자를 지정하는 기능이 없다.
        
        항목 7에서 설명하듯이, std::initializer_list를 받는 생성자와 받지 않는 생성자를 모두 가진 타입의 객체를 생성할 때, 생성자 인수들을 중괄호로 감싸면 오버로딩 해소 과정에서 std::initializer_list를 받는 버전이 선택되고, 괄호로 감싸면 std::initializer_list를 받지 않는 버전이 선택된다.
        
        make 함수들은 내부적으로 매개변수들을 완벽 전달할 때 중괄호가 아니라 괄호를 사용한다. 이 때문에, 피지칭 객체를 중괄호 초기치로 생성하려면 반드시 new를 직접 사용해야 한다.
        
        항목 30에서 설명하듯이 중괄호 초기치의 완벽 전달은 불가능하다. 그러나 항목 30에 우회책이 하나 나온다.
        
        auto 타입 추론을 이용해서 중괄호 초기치로부터 std::initializer_list 객체를 생성하고(항목 2 참고), 그것을 make 함수에 넘겨주면 된다.
        
        예제 코드 보기
        
        
        

        1. // 피지칭 객체를 중괄호 초기치로 생성하려면
        2. // new를 직접 사용하거나, 우회책을 사용해야
        3. // 한다.
        4.  
        5. // 다음은 우회책의 예시이다.
        6.  
        7. // std::initializer_list 객체를 생성
        8. auto initList = { 10, 20 };
        9.  
        10. // 그 std::initializer_list 객체를 이용해서 std::vector를 생성
        11. auto spv = std::make_shared<std::vector<int> >(initList);
        12.  

        
        
        예제 코드 접기
        
        
        

      • std::shared_ptr에 대해서는 make 함수가 부적합한 경우가 더 있는데, 두 가지 예를 들자면 (1) 커스텀 메모리 관리 기능을 가진 클래스를 다루는 경우와 (2) 메모리가 넉넉하지 않은 시스템에서 큰 객체를 자주 다루어야 하고 std::weak_ptr들이 해당 std::shared_ptr들보다 더 오래 살아남는 경우이다.

        클래스 중에는 자신만의 operator new와 operator delete를 정의하는 것들이 있다. 이런 클래스 고유(class-specific) 메모리 관리 루틴들은 단지 클래스의 객체와 정확히 같은 크기의 메모리 조각들만 할당, 해제하는 경우가 많다.
        
        그런 루틴들은 커스텀 std::shared_ptr의 커스텀 할당(std::allocate_shared를 통한)과 커스텀 해제(커스텀 삭제자를 통한)에는 잘 맞지 않는다. 왜냐하면, std::allocate_shared가 요구하는 메모리 조각의 크기는 동적으로 할당되는 객체의 크기에 제어 블록의 크기를 더한 것이기 때문이다.
        
        제어 블록의 참조 카운트가 0이 되면 std::shared_ptr이 가리키던 피지칭 객체를 파괴하고, 피지칭 객체가 차지하고 있던 메모리를 해제할 수 있다.
        
        하지만, 같은 피지칭 객체를 가리키는 std::weak_ptr들이 모두 소멸되기 전('두 번째' 참조 카운트가 0이 되기 전)에는 제어 블록을 파괴할 수 없다(std::weak_ptr들이 만료되었는지를 점검하기 위해서 제어 블록을 사용하기 때문이다. 항목 20을 보라).
        
        그런데 std::make_shared를 통해 생성한 std::shared_ptr은, 피지칭 객체와 제어 블록이 하나의 메모리 조각(한 번의 동적할당으로 얻은 메모리)에 있게 된다. 따라서, 이 std::shared_ptr과 같은 피지칭 객체를 가리키는 std::weak_ptr들이 모두 소멸되기 전에는 피지칭 객체를 위해 할당한 메모리를 먼저 해제할 수 없다.
        
        만약 피지칭 객체의 크기가 아주 크다면, 메모리가 부족한 시스템에서는 부담이 될 수 있다.
        
        예제 코드 보기
        
        
        

        1. class ReallyBigType { ... };
        2.  
        3. auto pBigObj = // 아주 큰 객체를
        4. std::make_shared<ReallyBigType>(); // std::make_shared를
        5. // 이용해서 생성
        6.  
        7. ... // 큰 객체를 가리키는 std::shared_ptr들과
        8. // std::weak_ptr들을 생성해서 사용한다.
        9.  
        10. ... // 여기서 객체를 가리키는 마지막 std::shared_ptr가
        11. // 파괴되나, std::weak_ptr들은 여전히 남아 있다.
        12.  
        13. ... // 이 부분에서, 큰 객체가 차지하던 메모리는
        14. // 여전히 할당된 상태이다.
        15.  
        16. ... // 여기서 객체를 가리키는 마지막 std::weak_ptr가 파괴
        17. // 된다; 이제 제어 블록과 객체가 차지하던 메모리가 해제된다.
        18.  
        19. // new를 직접 사용하는 경우에는 ReallyBigType 객체를
        20. // 가리키던 마지막 std::shared_ptr가 파괴되는 즉시
        21. // 그 객체의 메모리가 해제될 수 있다.
        22.  
        23. class ReallyBigType { ... };
        24.  
        25. std::shared_ptr<ReallyBigType> pBigObj(new ReallyBigType);
        26. // 아주 큰 객체를
        27. // new를 이용해서 생성
        28.  
        29. ... // 이전처럼 객체를 가리키는 std::shared_ptr들과
        30. // std::weak_ptr들을 생성해서 사용한다.
        31.  
        32. ... // 여기서 객체를 가리키는 마지막 std::shared_ptr가
        33. // 파괴되나, std::weak_ptr들은 여전히 남아 있다.
        34. // 객체의 메모리는 해제된다.
        35.  
        36. ... // 이 부분에서, 제어 블록을 위한 메모리만
        37. // 할당된 상태이다.
        38.  
        39. ... // 여기서 객체를 가리키는 마지막 std::weak_ptr가 파괴
        40. // 된다; 이제 제어 블록이 차지하던 메모리가 해제된다.
        41.  

        
        
        예제 코드 접기
        
        
        지금까지 살펴본, make 함수들을 사용할 수 없는 상황은 흔치 않다. 이처럼 make 함수를 사용하지 않을 특별히 강력한 이유가 없는 한, make 함수를 사용하는 것이 옳은 선택이다.

  22. Pimpl 관용구를 사용할 때에는 특수 멤버 함수들을 구현 파일에서 정의하라 / 160

      • Pimpl 관용구는 클래스 구현과 클래스 클라이언트 사이의 컴파일 의존성을 줄임으로써 빌드 시간을 감소한다.

        Pimpl 관용구 예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 예를 들어 다음과 같은 모습의 Widget
        3. // 클래스가 있다고 하자.
        4.  
        5. class Widget { // "Widget.h" 헤더 파일 안에서
        6. public:
        7. Widget(void);
        8. ...
        9.  
        10. private:
        11. std::string name;
        12. std::vector<double> data;
        13. Gadget g1, g2, g3; // Gadget은 어떤 사용자 정의
        14. }; // 타입
        15.  
        16. // Widget의 데이터 멤버들이 std::string,
        17. // std::vector, Gadget 타입이므로,
        18. // Widget을 컴파일하려면 그 타입들의
        19. // 헤더가 있어야 한다.
        20.  
        21. // 즉 Widget의 클라이언트는 반드시
        22. // #include를 이용해서 <string>, <vector>,
        23. // gadget.h 를 포함해야 한다.
        24.  
        25. // 이 헤더들 때문에 컴파일 시간이 증가하며,
        26. // 한 헤더의 내용이 변하면 Widget 클라이언트도
        27. // 반드시 다시 컴파일해야 한다.
        28.  
        29. // 표준 헤더인 <string>과 <vector>는 자주
        30. // 바뀌지 않지만, gadget.h는 자주 바뀔 수 있다.
        31.  
        32. // C++98에서는 Pimpl 관용구를 Widget에
        33. // 다음과 같이 적용했을 것이다.
        34.  
        35. class Widget { // 여전히 "Widget.h" 헤더 안
        36. public:
        37. Widget(void);
        38. ~Widget(void); // 소멸자가 필요함
        39. ...
        41. private:
        42. struct Impl; // 구현용 구조체와 그것을
        43. Impl *pImpl; // 가리키는 포인터를 선언
        44. };
        45.  
        46. // 이제는 Widget이 std::string이나 std::vector,
        47. // Gadget 타입을 언급하지 않으므로, Widget의
        48. // 클라이언트는 그 타입들의 헤더를 #include로
        49. // 포함시킬 필요가 없다.
        50.  
        51. // 이 덕분에 위에서 언급한 문제들이 해소된다.
        52.  
        53. // 선언만 하고 정의는 하지 않은 Widget::Impl과
        54. // 같은 타입을 불완전 타입(incomplete type)이라고
        55. // 부르기도 한다.
        56.  
        57. // 불완전 타입을 가리키는 포인터를 선언하는 것은
        58. // 불완전 타입으로 할 수 있는 몇 안 되는 일 중
        59. // 하나이고, Pimpl 관용구는 바로 그러한 능력을
        60. // 활용한다.
        61.  
        62. // 둘째 단계는 원래의 클래스에서 사용하던 데이터
        63. // 멤버들을 담는 객체를 동적으로 할당, 해제하는
        64. // 코드를 추가하는 것이다.
        65.  
        66. // 이런 코드들은 클래스를 구현하는 소스 코드
        67. // 파일에 둔다.
        68.  
        69. #include "widget.h" // 구현 파일 "widget.cpp" 안에서
        70. #include "gadget.h"
        71. #include <string>
        72. #include <vector>
        73.  
        74. struct Widget::Impl { // 전에 Widget에 있던
        75. std::string name; // 데이터 멤버들을 담은
        76. std::vector<double> data; // Widget::Impl의 정의
        77. Gadget g1, g2, g3;
        78. };
        79.  
        80. Widget::Widget(void) // 이 Widget 객체를 위한
        81. : pImpl(new Impl()) // 데이터 멤버들을 할당
        82. {}
        83.  
        84. Widget::~Widget(void) // 이 객체를 위한 데이터
        85. { delete pImpl; } // 멤버들을 파괴
        86.  
        87. // Widget이 파괴될 때 Widget::Impl객체도
        88. // 파괴되어야 하므로 Widget의 소멸자가
        89. // 꼭 필요하다.
        90.  
        91. // 하지만 이는 C++98용 코드이며,
        92. // 지난 세기의 악취 나는 유산이
        93. // 그대로 남아 있다.
        94.  
        95.  
        96. //-----------------------------------------------------------------------------
        97. // 이러한 상황에서 스마트 포인터를 사용하는 것이다.
        98.  
        99. // 지금 상황에서 가장 필요한 수단은 std::unique_ptr
        100. // (항목 18 참고)임이 분명해 보인다.
        101.  
        102. // 다음은 위의 예제를 std::unique_ptr을 사용하도록
        103. // 고친 예이다.
        104.  
        105. class Widget { // 헤더 "widget.h" 안에서
        106. public:
        107. Widget(void);
        108. ...
        110. private:
        111. struct Impl;
        112. std::unique_ptr<Impl> pImpl; // 생 포인터 대신 스마트
        113. }; // 포인터를 사용한다.
        114.  
        115. // 다음은 이에 맞게 수정된 구현 파일이다.
        116.  
        117. #include "widget.h" // "widget.cpp" 파일 안에서
        118. #include "gadget.h"
        119. #include <string>
        120. #include <vector>
        121.  
        122. struct Widget::Impl { // 이전과 동일
        123. std::string name;
        124. std::vector<double> data;
        125. Gadget g1, g2, g3;
        126. };
        127.  
        128. Widget::Widget(void) // 항목 21의 조언을 따라,
        129. : pImpl(std::make_unique<Impl>()) // std::make_unique를
        130. {} // 이용해서 std::unique_
        131. // ptr를 만든다.
        132.  
        133. // 이제는 Widget 클래스에 소멸자가 없다.
        134.  
        135. // pImpl의 파괴를 std::unique_ptr의 소멸자가
        136. // 대신 해주기 때문이다.
        137.  
        138. // 문제는 이 코드 자체는 잘 컴파일되지만,
        139. // 다음과 같이 자명한 클라이언트 쪽 용법은
        140. // 컴파일되지 않는다.
        141.  
        142. #include "widget.h"
        143.  
        144. Widget w; // 오류!
        145.  

        
        
        Pimpl 관용구 예제 코드 접기
        
        
        

      • std::unique_ptr 타입의 Pimpl 포인터를 사용할 때에는 특수 멤버 함수들을 클래스 헤더에 선언하고 구현 파일에서 구현해야 한다. 컴파일러가 기본적으로 작성하는 함수 구현들이 사용하기에 적합한 경우에도 그렇게 해야 한다.

        Pimpl 관용구 예제 코드에서, std::unique_ptr을 이용하여 Pimpl 관용구를 구현한 Widget 객체를 클라이언트 쪽에서 생성하려고 하면 컴파일이 되지 않는다는 것을 보았을 것이다. 지금부터 그 이유를 알아보도록 하자.
        
        구체적인 컴파일 오류 메시지는 컴파일러마다 다르겠지만, 대부분 불완전한 타입에 sizeof나 delete를 적용하는 것과 관련된 불평이 메시지에 포함되어 있을 것이다. 그런 연산들은 불완전한 타입으로 할 수 있는 몇 안 되는 일에 포함되지 않는다.
        
        이 문제는 클라이언트 쪽에서 선언한 Widget 객체 w가 파괴되는 시점에 대해 컴파일러가 작성하는 코드에서 기인한다.
        
        그 지점에서 w의 소멸자가 호출되는데, std::unique_ptr를 이용하는 Widget 클래스에 따로 소멸자를 선언하지 않았다. 이 경우, 컴파일러가 대신 소멸자를 작성해 준다(항목 17 참고).
        
        컴파일러는 그 소멸자 안에 Widget의 데이터 멤버 pImpl의 소멸자를 호출하는 코드를 삽입한다. pImpl은 std::unique_ptr<Widget::Impl>, 즉 기본 삭제자를 사용하는 std::unique_ptr이고, 그 기본 삭제자는 std::unique_ptr안에 있는 생 포인터에 대해 delete를 적용하는 함수이다.
        
        그런데 대부분의 표준 라이브러리 구현들에서 그 삭제자 함수는 delete를 적용하기 전에, 혹시 생 포인터가 불완전한 타입을 가리키지 않는지를 C++11의 static_assert를 이용해서 점검한다.
        
        컴파일러가 w의 파괴를 위한 코드를 산출하는 과정에서 일반적으로 그 static_assert가 참이 아닌 것으로 판명되며, 그러면 앞에서 언급한 오류 메시지가 나타난다.
        
        그 메시지는 w가 파괴되는 시점과 연관되는데, 이는 컴파일러가 자동 작성하는 다른 모든 특수 멤버 함수처럼 Widget의 소멸자는 암묵적으로 inline이기 때문이다.
        
        오류 메시지 자체는 소스 코드에서 w가 생성되는 행 번호를 가리키는 경우가 많다. 이후의 암묵적 파괴로 이어지는 객체를 명시적으로 생성하는 부분이 바로 그 행이기 때문이다.
        
        std::unique_ptr<Widget::Impl>을 파괴하는 코드가 만들어지는 지점에서 Widget::Impl이 완전한 타입이 되게 하면 문제가 바로 해결된다. 컴파일러는 타입의 정의를 보게 되면 그 타입을 완전한 타입으로 간주한다. 그리고 Widget::Impl의 정의는 widget.cpp에 있다.
        
        따라서, Widget::Impl의 정의 이후에 컴파일러가 그 소스 파일에만 있는 Widget의 소멸자의 본문(즉, 컴파일러가 std::unique_ptr 데이터 멤버를 파괴하는 코드를 작성하는 곳)을 보게 한다면 클라이언트 코드가 문제없이 컴파일된다.
        
        항목 17에 나오듯이, Widget에 소멸자를 선언하면 컴파일러는 이동 연산들을 작성하지 않는다. 따라서 이동 연산들을 지원하려면 해당 이동 연산들을 직접 선언해야 한다. 그러나 이동 연산들 역시 소멸자와 마찬가지 이유로, 이동 연산들의 정의가 구현 파일에 있어야 한다.
        
        복사 연산이 필요하다면 복사 연산도 직접 작성해야 한다.
        
        왜냐하면 (1) std::unique_ptr 같은 이동 전용 타입이 있는 클래스에 대해서는 컴파일러가 복사 연산들을 작성해 주지 않으며, (2) 작성한다고 해도, 작성된 함수들은 std::unique_ptr 자체만 복사하는 얕은 복사(shallow copy)를 수행하기 때문이다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // std::unique_ptr을 사용해서 Pimpl을 구현한다면
        3. // 특수 멤버 함수들을 직접, 그리고 구현 파일에
        4. // 작성해야 한다.
        5.  
        6. // 앞에서 보았던 예제를 이에 맞게 고쳐 보았다.
        7.  
        8. class Widget { // 이전처럼 "widget.h" 안에서
        9. public:
        10. Widget(void);
        11. ~Widget(void); // 선언만 해준다.
        12. ...
        14. private: // 이전과 동일
        15. struct Impl;
        16. std::unique_ptr<Impl> pImpl;
        17. };
        18.  
        19. // widget.cpp에서는, Widget::Impl정의 다음에서
        20. // Widget의 소멸자를 정의한다.
        21.  
        22. #include "widget.h" // 이전처럼 "widget.cpp" 안에서
        23. #include "gadget.h"
        24. #include <string>
        25. #include <vector>
        26.  
        27. struct Widget::Impl { // Widget::Impl의 정의
        28. std::string name; // (이전과 동일)
        29. std::vector<double> data;
        30. Gadget g1, g2, g3;
        31. };
        32.  
        33. Widget::Widget(void) // 이전과 동일
        34. : pImpl(std::make_unique<Impl>())
        35. {}
        36.  
        37. Widget::~Widget(void) // ~Widget의 정의
        38. {}
        39.  
        40. // 컴파일러가 자동 작성한 소멸자 자체에
        41. // 딱히 문제가 있는 것이 아니라는 점을
        42. // 강조하고 싶다면, 다음과 같이 소멸자를
        43. // 정의할 수 있다.
        44.  
        45. Widget::~Widget(void) = default; // 앞에서와 같은 효과
        46.  
        47.  
        48. //-----------------------------------------------------------------------------
        49. // 컴파일러가 자동으로 작성하는 이동 연산들은
        50. // std::unique_ptr의 이동 연산들을 호출해 준다.
        51.  
        52. // 하지만 소멸자를 명시적으로 선언하면,
        53. // 컴파일러는 이동 연산들을 작성하지 않는다.
        54.  
        55. // 따라서 이동을 지원하려면 해당 이동 연산들을
        56. // 직접 선언해야 한다.
        57.  
        58. class Widget { // 여전히
        59. public: // "widget.h"
        60. Widget(void);
        61. ~Widget(void);
        63. Widget(Widget&& rhs) = default; // 발상은 좋았지만
        64. Widget& operator=(Widget&& rhs) = default; // 코드는 틀렸음!
        66. ...
        68. private: // 이전과 동일
        69. struct Impl;
        70. std::unique_ptr<Impl> pImpl;
        71. };
        72.  
        73. // 그러나 소멸자에서 발생했던 문제가 동일하게
        74. // 이동 연산들에서도 발생한다.
        75.  
        76. // 이동 생성자에서는 상황이 좀 다르다.
        77.  
        78. // 이 경우 문제는, 일반적으로 컴파일러는
        79. // 이동 생성자 안에서 예외가 발생했을 때
        80. // pImpl을 파괴하기 위한 코드를 작성하는데,
        81. // pImpl을 파괴하려면 Impl이 완전한 타입이어야
        82. // 한다는 것이다.
        83.  
        84. // 문제가 이전과 동일하므로 그 해결책도 동일하다.
        85. // 즉 이동 연산들의 정의를 구현 파일로 옮기면 된다.
        86.  
        87. class Widget { // 여전히 "widget.h"
        88. public:
        89. Widget(void);
        90. ~Widget(void);
        92. Widget(Widget&& rhs); // 선언만 하고
        93. Widget& operator=(Widget&& rhs); // 정의는 하지 않는다.
        95. ...
        97. private: // 이전과 동일
        98. struct Impl;
        99. std::unique_ptr<Impl> pImpl;
        100. };
        101.  
        102.  
        103. #include <string> // 이전처럼
        104. ... // "widget.cpp" 안에서
        105.  
        106. struct Widget::Impl { ... }; // 이전과 동일
        107.  
        108. Widget::Widget(void) // 이전과 동일
        109. : pImpl(std::make_unique<Impl>())
        110. {}
        111.  
        112. Widget::~Widget(void) = default; // 이전과 동일
        113.  
        114. Widget::Widget(Widget&& rhs) = default; // 여기서
        115. Widget& Widget::operator=(Widget&& rhs) = default; // 정의
        116.  
        117.  
        118. //-----------------------------------------------------------------------------
        119. // 복사 생성자도 필요하다면 마찬가지로, 헤더 파일에는
        120. // 선언만 하고 구현 파일에서 구현한다.
        121.  
        122. class Widget { // 여전히 "widget.h" 안에서
        123. public:
        124. ... // 다른 함수들은 이전과 동일
        126. Widget(const Widget& rhs); // 이 함수들은
        127. Widget& operator=(const Widget& rhs); // 선언만 해둔다.
        129. private: // 이전과 동일
        130. struct Impl;
        131. std::unique_ptr<Impl> pImpl;
        132. };
        133.  
        134.  
        135. #include "widget.h" // 이전처럼
        136. ... // "widget.cpp" 안에서
        137.  
        138. struct Widget::Impl { ... }; // 이전과 동일
        139.  
        140. Widget::~Widget(void) = default; // 다른 함수들은 이전과 동일
        141.  
        142. Widget::Widget(const Widget& rhs) // 복사 생성자
        143. : pImpl(nullptr)
        144. { if (rhs.pImpl) pImpl = std::make_unique<Impl>(*rhs.pImpl); }
        145.  
        146. Widget& Widget::operator=(const Widget& rhs) // 복사 대입 연산자
        147. {
        148. if (!rhs.pImpl) pImpl.reset();
        149. else if (!pImpl) pImpl = std::make_unique<Impl>(*rhs.pImpl);
        150. else *pImpl = *rhs.pImpl;
        152. return *this;
        153. }
        154.  
        155. // pImpl이 이미 이동되어서 널인지 점검하는 부분만
        156. // 주의하면 구현이 그리 어렵지는 않을 것이다.
        157.  

        
        
        예제 코드 접기
        
        
        

      • 위의 조언은 std::unique_ptr에 적용될 뿐, std::shared_ptr에는 적용되지 않는다.

        std::unique_ptr과 달리 std::shared_ptr은, 특수 멤버 함수들을 구현 파일에 구현하지 않아도 전혀 문제가 되지 않는다. 컴파일러가 알아서 만들어 주는 특수 멤버 함수만으로도 충분하다. 이 차이는 커스텀 삭제자를 지원하는 방식의 차이에서 비롯된 것이다.
        
        std::unique_ptr에서 삭제자의 타입은 해당 스마트 포인터 타입의 일부이며, 이 덕분에 컴파일러는 더 작은 실행시점 자료구조와 더 빠른 실행시점 코드를 만들어 낼 수 있다. 그 대신 컴파일러가 작성한 특수 멤버함수가 쓰이는 시점에서 피지칭 타입들이 완전한 타입들이어야 한다.
        
        반면 std::shared_ptr에서는 삭제자의 타입이 스마트 포인터 타입의 일부가 아니다. 이 때문에 실행시점 자료구조가 더 커지고 실행 코드가 다소 더 느려지지만, 컴파일러가 작성한 특수 멤버 함수들이 쓰이는 시점에서 피지칭 타입들이 완전한 타입이어야 한다는 요구 조건이 사라진다.
        
        예제 코드 보기
        
        
        

        1. // std::unique_ptr과는 달리 std::shared_ptr의
        2. // 경우에는 특수 멤버 함수들을 반드시
        3. // 구현 파일에서 구현하지 않아도 된다.
        4.  
        5. class Widget { // "widget.h" 안에서
        6. public:
        7. Widget(void);
        8. ... // 소멸자나 이동 연산들의
        9. // 선언이 전혀 없음
        10. private:
        11. struct Impl;
        12. std::shared_ptr<Impl> pImpl; // std::unique_ptr 대신
        13. }; // std::shared_ptr를 사용
        14.  
        15. // 이 widget.h를 #include로 포함하는 클라이언트
        16. // 코드가 다음과 같다고 할 때,
        17.  
        18. Widget w1;
        19.  
        20. auto w2(std::move(w1)); // w2를 이동 생성
        21.  
        22. w1 = std::move(w2); // w1을 이동 대입
        23.  
        24. // 모든 것이 제대로 컴파일되고,
        25. // 우리가 기대한 대로 실행된다.
        26.  
        27. // w1은 기본 생성되고, 그 값이 w2로
        28. // 이동하고, 그 값이 다시 w1로 이동하고,
        29. // w1과 w2 둘다 파괴된다(따라서 피지칭
        30. // Widget::Impl 객체도 파괴된다).

        
        
        예제 코드 접기
        
        
        

• Chapter 5   우측값 참조, 이동 의미론, 완벽 전달

  이번 장의 항목들에서는 매개변수가 항상 좌측값이라는 점을 명심하는 것이 중요하다. 매개변수의 타입이 우측값 참조인 경우에도 매개변수 자체는 좌측값이다. 예를 들어 다음과 같은 선언에서
  
  void f(Widget&& w);
  
  매개변수 w는 좌측값이다. 비록 그 타입은 Widget에 대한 우측값 참조이지만, w는 여전히 좌측값이다.

  23. std::move와 std::forward를 숙지하라 / 170

      • std::move는 우측값으로의 무조건 캐스팅을 수행한다. std::move 자체는 아무것도 이동하지 않는다.

        std::move 예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // C++11의 std::move를 구현한 예를 보자.
        3.  
        4. // 표준의 세부사항들을 완전히 준수하는 구현은
        5. // 아니지만, 그런 완전한 구현에 아주 가깝다.
        6.  
        7. template <typename T> // std 이름공간 안에서
        8. typename remove_reference<T>::type&&
        9. move(T&& param)
        10. {
        11. using ReturnType = // 별칭 선언
        12. typename remove_reference<T>::type&&; // 항목 9 참고
        14. return static_cast<ReturnType>(param);
        15. }
        16.  
        17. // 항목 28에서 설명하듯이, 타입 T가 하필 좌측값 참조이면
        18. // T&&는 좌측값 참조가 된다.
        19.  
        20. // 이를 방지하기 위해, 이 구현은 T에 타입 특성
        21. // (항목 9 참고) std::remove_reference를 적용한다.
        22.  
        23. // 그러면 반환 타입의 "&&"는 항상 참조가 아닌
        24. // 타입에 적용된다.
        25.  
        26. // 결과적으로 std::move는 반드시 우측값 참조를 돌려준다.
        27.  
        28. // 이처럼 std::move가 하는 일은, 자신의 인수를
        29. // 우측값으로 캐스팅하는 것 뿐이다.
        30.  
        31.  
        32. //-----------------------------------------------------------------------------
        33. // 참고로 C++14에서는 std::move를 더 간결하게
        34. // 구현할 수 있다.
        35.  
        36. // 함수 반환 타입 추론(항목 3 참고)과
        37. // 표준 라이브러리의 별칭 템플릿 중 하나인
        38. // std::remove_reference_t(항목 9 참고)
        39. // 덕분에 std::move를 다음과 같이 작성할 수 있다.
        40.  
        41. template <typename T>
        42. decltype(auto) move(T&& param)
        43. {
        44. using ReturnType = remove_reference_t<T>&&;
        45. return static_cast<ReturnType>(param);
        46. }

        
        
        std::move 예제 코드 접기
        
        
        사실 우측값이 이동의 후보가 아닌 경우도 있다. 바로 const T 타입의 우측값이다. 이동 생성자는 const가 아닌 T에 대한 우측값 참조를 받기 때문에 const T 타입의 우측값을 받을 수 없다. 그러나 const에 대한 좌측값 참조를 const 우측값에 묶는 것이 허용되기 때문에, 복사 생성자에 전달할 수는 있다.
        
        일반적으로 한 객체의 값을 바깥으로 이동하면 그 객체는 수정되며, 따라서 전달된 객체를 수정할 수도 있는 함수(이동 생성자가 그런 함수에 속한다)에 const 객체를 전달하는 일을 C++ 언어가 방지하는 것은 당연한 일이다.
        
        예제 코드 보기
        
        
        

        1. // 주석(annotation)을 나타내는 어떤 클래스의
        2. // 생성자가 주석의 내용을 구성하는 std::string
        3. // 매개변수 하나를 받아서 그 매개변수를
        4. // 데이터 멤버에 복사한다고 하자.
        5.  
        6. // 항목 41에 나온 정보에 기초해서, 그 매개변수를
        7. // 값 전달 방식으로 선언하기로 하자.
        8.  
        9. class Annotation {
        10. public:
        11. explicit Annotation(std::string text); // 복사할 매개변수
        12. ... // 항목 41에 따라
        13. }; // 값 전달로 선언하기로
        14.  
        15. // 그런데 이 Annotation의 생성자는
        16. // text의 값을 읽기만 한다.
        17.  
        18. // 따라서 매개변수 text가 const가 되도록
        19. // 선언문을 수정하자.
        20.  
        21. class Annotation {
        22. public:
        23. explicit Annotation(const std::string text);
        24. ...
        25. };
        26.  
        27. // text를 데이터 멤버로 복사할 때 복사 연산의
        28. // 비용을 치르지 않으려면, 그러면서도
        29. // 항목 41의 조언을 계속 지키려면 어떻게
        30. // 해야 할까?
        31.  
        32. // 다음처럼 std::move를 text에 적용해서
        33. // 우측값을 얻으면 어떨까?
        34.  
        35. class Annotation {
        36. public:
        37. explicit Annotation(const std::string text)
        38. : value(std::move(text))
        39. { ... }
        41. ...
        43. private:
        44. std::string value;
        45. };
        46.  
        47. // 이 코드의 컴파일과 링크에는 아무
        48. // 문제가 없으며, 실행도 잘 된다.
        49.  
        50. // 그런데 text가 value로 이동하는 것이
        51. // 아니라 복사된다는 점이 문제이다.
        52.  
        53. // text는 const std::string으로 선언되었으므로,
        54. // 캐스팅 이전에는 좌측값 const std::string이고,
        55. // 캐스팅한 결과는 우측값 const std::string이다.
        56.  
        57. // 즉, 전체 과정에서 const가 그대로 유지된다.
        58.  
        59. // std::string 클래스는 다음과 같이 생겼을 것이다.
        60.  
        61. class string { // std::string은 사실
        62. public: // std::basic_string<char>의
        63. ... // typedef임
        64. string(const string& rhs); // 복사 생성자
        65. string(string&& rhs); // 이동 생성자
        66. ...
        67. };
        68.  
        69. // 이런 상황에서 우측값 const std::string을
        70. // 생성자로 전달하면, const 때문에 이동 생성자가
        71. // 아닌 복사 생성자가 호출되게 된다.

        
        
        예제 코드 접기
        
        
        이 예에서 배울 점이 두 가지 있다. 첫째로, 이동을 지원할 객체는 const로 선언하지 말아야 한다. const 객체에 대한 이동 요청은 소리 없이 복사 연산으로 변환된다. 둘째로, std::move는 아무것도 실제로 이동하지 않을 뿐만 아니라, 캐스팅되는 객체가 이동 자격을 갖추게 된다는 보장도 제공하지 않는다.

      • std::forward는 주어진 인수가 우측값에 묶인 경우에만 그것을 우측값으로 캐스팅한다.

        std::forward 예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // std::forward는 주어진 인수가 우측값에 묶인
        3. // 경우에만 그것을 우측값으로 캐스팅한다.
        4.  
        5. void process(const Widget& lvalArg); // 좌측값들을 처리하는 함수
        6. void process(Widget&& rvalArg); // 우측값들을 처리하는 함수
        7.  
        8. template <typename T> // param을 process에
        9. void logAndProcess(T&& param) // 넘겨주는 템플릿
        10. {
        11. auto now = // 현재 시간을 얻는다.
        12. std::chrono::system_clock::now();
        14. makeLogEntry("Calling 'process'", now);
        15. process(std::forward<T>(param));
        16. }
        17.  
        18. // 이제 logAndProcess를 한 번은 좌측값으로,
        19. // 또 한 번은 우측값으로 호출해보자.
        20.  
        21. Widget w;
        22.  
        23. logAndProcess(w); // 좌측값으로 호출
        24. logAndProcess(std::move(w)); // 우측값으로 호출
        25.  
        26. // 좌측값으로 호출한 경우, logAndProcess는
        27. // 좌측값들을 처리하는 process 함수를 호출하고,
        28. // 우측값으로 호출한 경우, logAndProcess는
        29. // 우측값들을 처리하는 process 함수를 호출한다.
        30.  
        31. // param은 좌측값이므로 std::forward를 사용하지
        32. // 않는다면, 항상 좌측값들을 처리하는 process
        33. // 함수가 호출될 것이다.
        34.  
        35. // std::forward는 param을 초기화하는데
        36. // 쓰인 인수가 우측값이면, 그리고 오직 그럴
        37. // 때에만, param을 우측값으로 캐스팅한다.
        38.  
        39. // std::forward는 param을 초기화하는데
        40. // 쓰인 인수가 우측값인지를 어떻게 알까?
        41.  
        42. // 간단한 답은, 그 정보가 logAndProcess의
        43. // 템플릿 매개변수 T에 부호화(encoding)되어
        44. // 있다는 것이다.
        45.  
        46. // 그 매개변수는 std::forward로 전달되며,
        47. // std::forward는 거기서 해당 정보를
        48. // 복원한다(구체적인 방법은 항목 28을
        49. // 보기 바란다).
        50.  
        51.  
        52. //-----------------------------------------------------------------------------
        53. // std::move 대신 항상 std::forward만
        54. // 쓰면 되지 않을까? 라고 생각할지도 모른다.
        55.  
        56. // std::move의 매력은 사용하기 편하고,
        57. // 오류의 여지가 줄어들고, 코드의 명확성이
        58. // 높아진다는 것이다.
        59.  
        60. // 어떤 클래스의 이동 생성자가 호출된 횟수를
        61. // 추척하고 싶다고 하자.
        62.  
        63. // 그러러면 그냥 이동 생성 도중에 클래스
        64. // 정적(static) 카운터 변수를 증가하면 된다.
        65.  
        66. // 클래스의 비정적 데이터 멤버가 std::string
        67. // 하나뿐이라 할 때, 다음은 이동 생성자를
        68. // 구현하는 통상적인 방식을 보여준다.
        69.  
        70. class Widget {
        71. public:
        72. Widget(Widget&& rhs)
        73. : s(std::move(rhs.s))
        74. { ++moveCtorCalls; }
        76. ...
        78. private:
        79. static std::size_t moveCtorCalls;
        80. std::string s;
        81. };
        82.  
        83. // std::move 대신 std::forward를
        84. // 쓰면 다음과 같은 코드가 될 것이다.
        85.  
        86. class Widget {
        87. public:
        88. Widget(Widget&& rhs) // 관례에서 벗어난,
        89. : s(std::forward<std::string>(rhs.s)) // 바람직하지 않은
        90. { ++moveCtorCalls; } // 구현
        92. ...
        94. };
        95.  
        96. // 첫번째 버전의 std::move에서는 함수 인수
        97. // (rhs.s)만 지정하면 되었지만 둘째 버전의
        98. // std::forward에서는 함수 인수(rhs.s)와
        99. // 템플릿 타입 인수(std::string) 둘 다
        100. // 지정해야 했음을 주목하기 바란다(번거롭다).
        101.  
        102. // 그리고 std::forward에 전달하는 타입이
        103. // 반드시 참조가 아니어야 한다는 점도
        104. // 주목하기 바란다(실수로 std::string&을
        105. // 전달하면 이동이 아닌 복사가 일어난다).
        106.  
        107. // 그것이 전달되는 인수가 우측값임을 부호화하는
        108. // 데 쓰이는 관례이기 때문이다(항목 28 참고).

        
        
        std::forward 예제 코드 접기
        
        
        

      • std::move와 std::forward 둘 다, 실행시점에서는 아무 일도 하지 않는다.

  24. 보편 참조(universal reference)와 우측값 참조를 구별하라 / 176

      • 함수 템플릿 매개변수의 타입이 T&& 형태이고 T가 추론된다면, 또는 객체를 auto&&로 선언한다면, 그 매개변수나 객체는 보편 참조(universal reference)이다.

        보편 참조(universal reference)는 우측값, 좌측값은 물론 const 객체, 비const 객체, volatile 객체, 비volatile 객체, 심지어 const이자 volatile인 객체에도 묶을 수 있다.

      • 타입 선언의 형태가 정확히 타입&&가 아니면, 또는 타입 추론이 일어나지 않으면, 타입&&는 우측값 참조를 뜻한다.

        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 어떤 타입 T에 대한 우측값 참조를 선언할 때에는
        3. // T&&라는 표기를 사용한다.
        4.  
        5. // 하지만, 소스 코드에서 "T&&"를 발견했다고 해서
        6. // 그것이 항상 우측값 참조라고 가정하면 안 된다.
        7.  
        8. void f(Widget&& param); // 우측값 참조
        9.  
        10. Widget&& var1 = Widget(); // 우측값 참조
        11.  
        12. auto&& var2 = var1; // 우측값 참조 아님
        13.  
        14. template <typename T>
        15. void f(std::vector<T>&& param); // 우측값 참조
        16.  
        17. template <typename T>
        18. void f(T&& param); // 우측값 참조 아님
        19.  
        20. // 형태가 T&& 이고(타입이름 T는 바뀌어도 상관없다)
        21. // T가 추론되는 경우와, auto&&로 객체를 선언하는
        22. // 경우에, 그 매개변수나 객체는 보편 참조(universal reference)이다.
        23.  
        24.  
        25. //-----------------------------------------------------------------------------
        26. // 보편 참조(universal reference)는 두 가지 문맥에서 나타난다.
        27.  
        28. // 가장 흔한 것은 함수 템플릿 매개변수이다.
        29.  
        30. template <typename T>
        31. void f(T&& param); // param은 보편 참조(universal reference)
        32.  
        33. // 다른 한 문맥은 auto 선언이다.
        34.  
        35. auto&& var2 = var1; // var2는 보편 참조(universal reference)
        36.  
        37. // 이 두 문맥의 공통점은 타입 추론이
        38. // 일어난다는 점이다.
        39.  
        40. // 템플릿 f에서는 param의 타입이,
        41. // var2의 선언에서는 var2의 타입이
        42. // 추론된다.
        43.  
        44. // 타입 추론이 일어나지 않는 문맥에서 "T&&"를
        45. // 발견했다면, 그것은 우측값 참조이다.
        46.  
        47. void f(Widget&& param); // 타입 추론 없음
        48. // param은 우측값 참조
        49.  
        50. Widget&& var1 = Widget(); // 타입 추론 없음
        51. // var1은 우측값 참조
        52.  
        53.  
        54. //-----------------------------------------------------------------------------
        55. // 하나의 참조가 보편 참조(universal reference)이려면
        56. // 반드시 타입 추론이 관여해야 한다.
        57.  
        58. // 그런데 이는 필요조건일 뿐 충분조건은 아니다.
        59.  
        60. // 참조 선언의 형태도 정확해야 한다.
        61.  
        62. // 구체적으로 말해서, 딱 "T&&"의
        63. // 형태이어야 한다.
        64.  
        65. template <typename T>
        66. void f(std::vector<T>&& param); // param은 우측값 참조
        67.  
        68. // f 호출 시 타입 T가 추론된다.
        69.  
        70. // 그러나 param의 타입 추론의 형태가
        71. // "T&&"가 아니라 "std::vector<T>&&"이다.
        72.  
        73. // 이 때문에 param은 보편 참조(universal reference)가
        74. // 될 수 없다(우측값 참조이다).
        75.  
        76. std::vector<int> v;
        77. f(v); // 오류! 좌측값을 우측값
        78. // 참조에 묶을 수 없음
        79.  
        80. // 그냥 const 한정사 하나만 붙여도
        81. // 참조는 보편 참조(universal reference)가 되지 못한다.
        82.  
        83. template <typename T>
        84. void f(const T&& param); // param은 우측값 참조
        85.  
        86.  
        87. //-----------------------------------------------------------------------------
        88. // 그런데 "T&&"라고 다 보편 참조(universal reference)는 아니다.
        89.  
        90. // 예를 들어 템플릿 안에서 타입이 "T&&"인
        91. // 함수 매개변수를 발견했을 때, 그것이
        92. // 반드시 보편 참조(universal reference)라고 확신할 수는 없다.
        93.  
        94. // 템플릿 안에서는 타입 추론이 반드시
        95. // 일어난다는 보장이 없기 때문이다.
        96.  
        97. template <class T, class Allocator = allocator<T> > // C++ 표준에서
        98. class vector { // 발췌
        99. public:
        100. void push_back(T&& x);
        101. ...
        102. };
        103.  
        104. // push_back의 매개변수는 확실히 보편 참조(universal reference)가
        105. // 요구하는 형태이지만, 이 경우에는 타입 추론이
        106. // 전혀 일어나지 않는다.
        107.  
        108. // push_back은 반드시 구체적으로 인스턴스화
        109. // 된 vector의 일부이어야 하며, 그 인스턴스의
        110. // 타입은 push_back의 선언을 완전하게
        111. // 결정하기 때문이다.
        112.  
        113. // 예를 들어,
        114.  
        115. std::vector<Widget> v;
        116.  
        117. // 라는 선언에 의해 std::vector 템플릿은
        118. // 다음과 같이 인스턴스화된다.
        119.  
        120. class vector<Widget, allocator<Widget> > {
        121. public:
        122. void push_back(Widget&& x); // 우측값 참조
        123. ...
        124. };
        125.  
        126.  
        127. //-----------------------------------------------------------------------------
        128. // 반면, std::vector의 멤버 함수들 중
        129. // 이와 개념적으로 비슷한 emplace_back
        130. // 멤버 함수는 실제로 타입 추론을 사용한다.
        131.  
        132. template <class T, class Allocator = allocator<T> > // 역시 C++
        133. class vector { // 표준에서
        134. public: // 발췌
        135. template <class... Args>
        136. void emplace_back(Args&&... args);
        137. ...
        138. };
        139.  
        140. // 이 경우 타입 매개변수 Args는 vector의
        141. // 타입 매개변수 T와 독립적이다.
        142.  
        143. // 따라서 Args는 emplace_back이
        144. // 호출될 때마다 추론되어야 한다.
        145.  
        146. // 즉, args는 보편 참조(universal reference)이다.
        147.  
        148. // 이 예를 보면, 보편 참조(universal reference)의 형태가 "T&&"라는
        149. // 말에서, 타입이름 T가 꼭 "T"이어야 할
        150. // 필요는 없다는 것을 알 수 있다.
        151.  
        152. // 즉 다음과 같은 경우도 보편 참조(universal reference)이다.
        153.  
        154. template <typename MyTemplateType>
        155. void someFunc(MyTemplateType&& param); // param은 보편 참조(universal reference)
        156.  
        157.  
        158. //-----------------------------------------------------------------------------
        159. // 앞에서 auto&&를 타입으로 해서 선언된
        160. // 변수도 보편 참조(universal reference)라고 했었다.
        161.  
        162. // 타입 추론이 일어났고 형태도 "T&&"이기 때문이다.
        163.  
        164. // auto 보편 참조(universal reference)는 C++11보다 C++14에서
        165. // 더 자주 볼 수 있다.
        166.  
        167. // C++14의 람다 표현식에서 auto&& 매개변수를
        168. // 사용할 수 있기 때문이다.
        169.  
        170. auto timeFuncInvocation = // C++14
        171. [](auto&& func, auto&&... params)
        172. {
        173. 타이머를 시작한다;
        174. std::forward<decltype(func)>(func)( // params로
        175. std::forward<decltype(params)>(params)... // func를 호출
        176. );
        177. 타이머를 정지하고 경과 시간을 기록한다;
        178. }
        179.  
        180. // "std::forward<decltype(어쩌구 저쩌구)>"가 사용된
        181. // 이유는 항목 33에서 찾을 수 있다.
        182.  
        183. // timeFuncInvocation을 이용하면 거의 모든
        184. // 함수의 실행 시간을 측정할 수 있다.
        185.  
        186. // "모든" 함수가 아니라 "거의 모든" 함수인
        187. // 이유는 항목 30에서 찾을 수 있다.

        
        
        예제 코드 접기
        
        
        

      • 우측값으로 초기화되는 보편 참조(universal reference)는 우측값 참조에 해당한다. 좌측값으로 초기화되는 보편 참조(universal reference)는 좌측값 참조에 해당한다.

        예제 코드 보기
        
        
        

        1. template <typename T>
        2. void f(T&& param); // param은 보편 참조(universal reference)
        3.  
        4. Widget w;
        5. f(w); // f에 좌측값이 전달됨; param의 타입은
        6. // Widget&(즉, 좌측값 참조)
        7.  
        8. f(std::move(w)); // f에 우측값이 전달됨; param의 타입은
        9. // Widget&&(즉, 우측값 참조)
        10.  

        
        
        예제 코드 접기
        
        
        

  25. 우측값 참조에는 std::move를, 보편 참조(universal reference)에는 std::forward를 사용하라 / 181

      • 우측값 참조나 보편 참조(universal reference)가 마지막으로 쓰이는 지점에서, 우측값 참조에는 std::move를, 보편 참조(universal reference)에는 std::forward를 적용하라.

        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 우측값 객체를 다른 함수에 넘겨주되 그 함수가
        3. // 객체의 우측값 성질을 활용할 수 있도록
        4. // 넘겨주어야 하는 경우도 흔히 생긴다.
        5.  
        6. // 이를 위해서는 그런 객체에 묶이는 매개변수를
        7. // 우측값으로 캐스팅해야 한다.
        8.  
        9. // 항목 23에서 설명하듯이, std::move가
        10. // 하는 일이 바로 그것이다.
        11.  
        12. class Widget {
        13. public:
        14. Widget(Widget&& rhs) // rhs는 우측값 참조
        15. : name(std::move(rhs.name)),
        16. p(std::move(rhs.p))
        17. { ... }
        18. ...
        20. private:
        21. std::string name;
        22. std::shared_ptr<SomeDataStructure> p;
        23. };
        24.  
        25.  
        26. //-----------------------------------------------------------------------------
        27. // 반면 보편 참조(universal reference)는 이동에 적합한 객체에
        28. // 묶일 수도 있고 아닐 수도 있다(항목 24 참고).
        29.  
        30. // 보편 참조(universal reference)는 우측값으로 초기화되는 경우에만
        31. // 우측값으로 캐스팅되어야 한다.
        32.  
        33. // 항목 23에서 설명하듯이, std::forward가
        34. // 하는 일이 바로 그것이다.
        35.  
        36. class Widget {
        37. public:
        38. template <typename T>
        39. void setName(T&& newName) // newName은
        40. { name = std::forward<T>(newName); } // 보편 참조(universal reference)
        42. ...
        43. };
        44.  
        45.  
        46. //-----------------------------------------------------------------------------
        47. // 항목 23에서 설명하듯이 우측값 참조에
        48. // std::forward를 사용해도 되지만, 소스
        49. // 코드가 장황하고 실수의 여지가 있으며
        50. // 관용구에서 벗어난 모습이 된다.
        51.  
        52. // 따라서 우측값 참조에 std::forward를
        53. // 사용하는 것은 피해야 한다.
        54.  
        55. // 보편 참조(universal reference)에 std::move를 사용하는
        56. // 것은 더 나쁘다.
        57.  
        58. // 그러면 좌측값이 의도치 않게 수정되는
        59. // 결과가 빚어질 수 있기 때문이다.
        60.  
        61. class Widget {
        62. public:
        63. template <typename T>
        64. void setName(T&& newName) // 보편 참조(universal reference)
        65. { name = std::move(newName); } // 컴파일되긴 하지만
        66. ... // 아주 아주 나쁘다!
        68. private:
        69. std::string name;
        70. std::shared_ptr<SomeDataStructure> p;
        71. };
        72.  
        73. std::string getWidgetName(void); // 팩터리 함수
        74.  
        75. Widget w;
        76.  
        77. auto n = getWidgetName(); // n은 지역 변수
        78.  
        79. w.setName(n); // n을 w로 이동한다.
        80.  
        81. ... // 이제 n의 값은 알 수 없다.
        82.  
        83. // 이러면 n의 값이 w로 이동하고,
        84. // setName이 복귀한 후에 n은 미지정 값
        85. // (unspecified value)을 가진다.
        86.  
        87. // 미지정 값이란 미정의 행동의 '값 버전'
        88. // 이라고 할 수 있다.
        89.  
        90. // 즉 어떤 값을 가질 지 모르는 상태이다.
        91.  
        92. // 보편 참조(universal reference)는 const일 수 없기 때문에
        93. // (항목 24 참고) 이런 일이 생긴다고
        94. // 생각할 수 있다.
        95.  
        96. // 이 때문에 setName을 const 좌측값에 대한
        97. // 버전과 우측값에 대한 버전 두 가지로
        98. // 오버로딩하면 모든 문제가 사라진다는 점을
        99. // 지적하는 사람도 있을 것이다.
        100.  
        101. class Widget {
        102. public:
        103. void setName(const std::string& newName) // const 좌측값으로
        104. { name = newName; } // name을 설정
        106. void setName(std::string&& newName) // 우측값으로
        107. { name = std::move(newName); } // name을 설정
        109. ...
        110. };
        111.  
        112. // 이것이 하나의 해결책이 될 수 있지만,
        113. // 몇 가지 단점이 있다.
        114.  
        115. // 첫째로, 작성하고 유지보수해야 할 소스
        116. // 코드의 양이 늘어났다.
        117.  
        118. // 둘째로, 효율성이 떨어질 수 있다.
        119.  
        120. // 예를 들어 setName을 이런 식으로
        121. // 사용한다고 하자.
        122.  
        123. w.setName("Adela Novak");
        124.  
        125. // 보편 참조(universal reference)를 받는 버전의 setName에서는
        126. // 문자열 리터럴 "Adela Novak"이
        127. // 그대로 setName으로 넘어가서 w
        128. // 안의 std::string 데이터 멤버에
        129. // 대한 대입 연산자의 인수로 쓰인다.
        130.  
        131. // 즉, 그 문자열 리터럴이 w의 데이터 멤버
        132. // name에 직접 대입되며, 임시 std::string
        133. // 객체는 생성되지 않는다.
        134.  
        135. // 그러나 오버로딩된 setName 버전들에서는
        136. // 문자열 리터럴로부터 임시 std::string
        137. // 객체가 생성되어서 setName의 매개변수에
        138. // 묶이고, 그 임시 std::string이 w의
        139. // 데이터 멤버로 이동한다.
        140.  
        141. // 즉 생성자 한 번, 이동 대입 연산자 한 번,
        142. // 소멸자 한 번이 호출된다.
        143.  
        144. // 좌측값과 우측값에 대한 오버로딩의 가장 심각한 문제는
        145. // 설계의 확장성(scalability)이 나쁘다는 것이다.
        146.  
        147. // Widget::setName은 매개변수를 하나만
        148. // 받으므로 오버로딩된 함수가 두 개면 되었다.
        149.  
        150. // 그러나 매개변수가 더 많고 각 매개변수가
        151. // 좌측값일 수도 있고 우측값일 수도 있다면
        152. // 오버로딩된 함수의 수가 기하급수적으로 증가한다.
        153.  
        154. // 그보다 더 큰 문제는, 함수 템플릿들 중에는
        155. // 좌측값일 수도 있고 우측값일 수도 있는 매개변수를
        156. // 무제한으로 받는 것들이 있다는 점이다.
        157.  
        158. // 좋은 예가 std::make_shared와
        159. // C++14의 std::make_unique
        160. // (항목 21 참고) 이다.
        161.  
        162. template <class T, class... Args> // C++11 표준에서
        163. shared_ptr<T> make_shared(Args&&... args); // 발췌
        164.  
        165. template <class T, class... Args> // C++14 표준에서
        166. unique_ptr<T> make_unique(Args&&... args); // 발췌
        167.  
        168. // 이런 함수들에 대해서는 좌측값과 우측값에 대한
        169. // 오버로딩이 현실적으로 불가능하다.
        170.  
        171. // 유일한 방안은 보편 참조(universal reference)이고, 보편 참조(universal reference)
        172. // 매개변수를 다른 함수에 전달할 때에는
        173. // 다름 아닌 std::forward를 사용해야 한다.
        174.  
        175.  
        176. //-----------------------------------------------------------------------------
        177. // 경우에 따라서는, 우측값 참조나 보편 참조(universal reference)에
        178. // 묶인 객체를 한 함수 안에서 여러 번
        179. // 사용하기도 한다.
        180.  
        181. // 그런 경우, 그 객체를 다 사용하기 전에
        182. // 다른 객체로 이동하는 일은 피해야 한다.
        183.  
        184. // 즉, std::move나 std::forward를 적용하는
        185. // 것은 해당 참조의 마지막 사용이어야 한다.
        186.  
        187. template <typename T>
        188. void setSignText(T&& text) // text는 보편 참조(universal reference)
        189. {
        190. sign.setText(text); // text를 사용하되
        191. // 수정하지는 않는다.
        193. auto now = // 현재 시간을 얻는다.
        194. std::chrono::system_clock::now();
        196. signHistory.add(now,
        197. std::forward<T>(text)); // text를 우측값으로
        198. } // 조건부 캐스팅
        199.  
        200. // 이 코드에서 중요한 것은, sign.setText가
        201. // text의 값을 변경하지 않게 하는 것이다.
        202.  
        203. // 나중에 signHistory.add를 호출할 때 그 값을
        204. // 사용해야 하기 때문이다.
        205.  
        206. // std::move에 대해서도 같은 논리가 적용된다.

        
        
        예제 코드 접기
        
        
        드문 경우이긴 하지만 std::move 대신 std::move_if_noexcept를 사용하는 게 바람직한 경우도 있다는 점도 알아두는 것이 좋다. 왜, 언제 그런지는 항목 14를 보기 바란다.

      • 결과를 값 전달 방식으로 돌려주는 함수가 우측값 참조나 보편 참조(universal reference)를 돌려줄 때에도 각각 std::move나 std::forward를 적용하라.

        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 함수가 결과를 값으로 돌려준다면(return by value),
        3. // 그리고 그것이 우측값 참조나 보편 참조(universal reference)에
        4. // 묶인 객체라면, 해당 참조를 돌려주는 return
        5. // 문에서 std::move나 std::forward를 사용하는
        6. // 것이 바람직하다.
        7.  
        8. Matrix // 결과를 값으로
        9. operator+(Matrix&& lhs, const Matrix& rhs) // 반환
        10. {
        11. lhs += rhs;
        12. return std::move(lhs); // lhs를 반환값으로
        13. } // 이동한다.
        14.  
        15. // return 문에서 lhs를 우측값으로 캐스팅한
        16. // 덕분에, 컴파일러는 lhs를 함수의 반환값
        17. // 장소로 이동한다.
        18.  
        19. // 다음처럼 std::move 호출이 없다면,
        20.  
        21. Matrix
        22. operator+(Matrix&& lhs, const Matrix& rhs)
        23. {
        24. lhs += rhs;
        25. return lhs; // lhs를 반환값으로
        26. } // 복사한다.
        27.  
        28. // lhs가 좌측값이므로, 컴파일러는 그것을
        29. // 반환값 장소로 복사해야 한다.
        30.  
        31. // Matrix 타입이 복사 생성보다 효율적인
        32. // 이동 생성을 지원한다고 할 때, return
        33. // 문에서 std::move를 사용하면 좀 더
        34. // 효율적인 코드가 만들어진다.
        35.  
        36. // Matrix가 이동을 지원하지 않는다고
        37. // 해도, 우측값으로의 캐스팅이 해가 되지는
        38. // 않는다.
        39.  
        40. // 이 경우 그냥 복사가 일어난다(항목 23 참고).
        41.  
        42. // 오히려 나중에 Matrix에 이동 지원이 추가되면,
        43. // 다음번에 operator+를 재컴파일 했을 때
        44. // 효율성이 저절로 향상된다(얻을 것이 많다).
        45.  
        46.  
        47. //-----------------------------------------------------------------------------
        48. // 보편 참조(universal reference)와 std::forward에 대한
        49. // 상황도 이와 비슷하다.
        50.  
        51. // 기약분수가 아닐 수도 있는 분수를 나타내는
        52. // Fraction 객체를 받아서 그것을
        53. // 약분한 결과의 복사본을 돌려주는 함수
        54. // 템플릿 reduceAndCopy가 있다고 하자.
        55.  
        56. // 만일 원래의 객체가 우측값이라면, 그 객체의
        57. // 값을 반환값으로 이동하는 것이 바람직하다.
        58.  
        59. // 그러나 원래의 객체가 좌측값이라면 실제로
        60. // 복사본을 생성해야 한다.
        61.  
        62. template <typename T>
        63. Function // 값 전달 방식의 반환값
        64. reduceAndCopy(T&& frac) // 보편 참조(universal reference) 매개변수를 받는다.
        65. {
        66. frac.reduce();
        67. return std::forward<T>(frac); // 우측값은 반환값으로
        68. } // 이동하고 좌측값은 복사한다.
        69.  

        
        
        예제 코드 접기
        
        
        

      • 반환값 최적화의 대상이 될 수 있는 지역 객체에는 절대로 std::move나 std::forward를 적용하지 말아야 한다.

        반환값 최적화(return value optimization, RVO - More Effective C++의 항목 20에서 관련 내용을 찾을 수 있다)가 적용되면, 지역 객체를 반환하는 함수에서 반환값이 복사되는 것을 피할 수 있다.
        
        그런데 반환값 최적화가 적용되려면 두 가지 조건을 만족해야 한다. (1) 그 지역 객체의 타입이 함수의 반환 타입과 같아야 하고 (2) 그 지역 객체가 바로 함수의 반환값이어야 한다(반환값 최적화를 적용할 수 있는 지역 객체는 지역 변수는 물론 return 문의 일부로 생성된 임시 객체도 포함된다. 함수 매개변수는 포함되지 않는다).
        
        하지만 반환값 최적화의 대상이 될 수 있는 지역 객체를 std::move나 std::forward를 적용하여 반환하면, (2) 번의 조건을 불만족하여 반환값 최적화의 혜택을 받을 수 없다. std::move나 std::forward를 적용한 후에는, 그 지역 객체 자체가 아니라 지역 객체의 참조자를 반환하게 되기 때문이다.
        
        이렇게 되면 컴파일러는 반드시 지역 객체를 반환값 장소로 옮겨야 한다.
        
        컴파일러는 반환값 최적화를 적용할 수 있는 상황임에도 적용하지 않을 수도 있다. 그러나 이런 상황이라도, 돌려줄 지역 객체에 std::move나 std::forward를 적용하여 돌려주는 것은 여전히 나쁜 선택이다. 이런 상황에서는 컴파일러가 반환되는 객체에 암묵적으로 std::move를 적용하기 때문이다.
        
        표준에 따르면 반환값 최적화가 허용되는 경우 복사 제거가 일어나거나, 아니면 반환되는 객체에 암묵적으로 std::move가 적용되어야 한다.
        
        정리하자면, 함수가 지역 객체를 값으로 반환하는 경우, 그 지역 객체에 std::move를 적용한다고 해서 컴파일러에게 도움이 되지는 않는다(복사 제거를 할 수 없는 상황이라면 어차피 그 지역 객체를 우측값으로 취급하므로). 오히려 컴파일러를 방해할 수 있다(반환값 최적화를 무효화해서).
        
        지역 객체에 std::move를 적용하는 것이 합당한 상황도 있지만(구체적으로 말하면, 더 이상 사용하지 않을 변수를 다른 함수에 넘겨주는 경우), 반환값 최적화가 적용될 수 있는 return 문이나 반환값 최적화의 대상이 아닌 값 전달 방식의 매개변수를 돌려주는 return 문에서 std::move를 적용하는 것은 그런 상황에 해당하지 않는다.
        
        예제 코드 보기
        
        
        

        1. Widget makeWidget(void)
        2. {
        3. Widget w;
        4. ...
        5. return w;
        6. }
        7.  
        8. // 이 경우 컴파일러는 반드시 w의 복사 제거를
        9. // 수행하거나, 아니면 함수를 애초에 다음과 같이
        10. // 작성된 것처럼 취급해야 한다.
        11.  
        12. Widget makeWidget(void)
        13. {
        14. Widget w;
        15. ...
        16. return std::move(w); // 복사 제거를 수행하지 않을 때에는
        17. } // w를 우측값으로 취급한다.
        18.  
        19. // 이는 값 전달 방식의 함수
        20. // 매개변수의 경우와 비슷하다.
        21.  
        22. // 그런 매개변수는 함수의 반환값
        23. // 최적화를 위한 복사 제거의
        24. // 대상이 아니지만, 함수가 그런
        25. // 매개변수를 반환하는 경우
        26. // 컴파일러는 그것을 반드시
        27. // 우측값으로 취급해야 한다.
        28.  
        29. // 즉, 다음과 같은 함수가 있을 때
        30.  
        31. Widget makeWidget(Widget w) // 함수의 반환값과 타입이 같은,
        32. { // 값 전달 방식의 매개변수
        33. ...
        34. return w;
        35. }
        36.  
        37. // 컴파일러는 이를 마치 다음과 같이
        38. // 작성된 것처럼 취급해야 한다.
        39.  
        40. Widget makeWidget(Widget w)
        41. {
        42. ...
        43. return std::move(w); // w를 우측값으로 취급한다.
        44. }

        
        
        예제 코드 접기
        
        
        

  26. 보편 참조(universal reference)에 대한 오버로딩을 피하라 / 191

      • 보편 참조(universal reference)에 대한 오버로딩은 거의 항상 보편 참조(universal reference) 오버로딩 버전이 예상보다 자주 호출되는 상황으로 이어진다.

        보편 참조(universal reference)를 받는 템플릿 함수는 C++에서 가장 욕심이 많은 함수이다. 그런 템플릿의 인스턴스는 거의 모든 타입의 인수와 정확히 부합한다. 보편 참조(universal reference) 오버로딩은 오버로딩을 시도한 개발자가 일반적으로 예상한 것보다 훨씬 많은 인수 타입들을 빨아들인다는 점에서, 보편 참조(universal reference)와 오버로딩을 결합하는 것은 거의 항상 나쁜 선택이다.
        
        예제 코드 보기
        
        
        

        1. // 사람 이름 하나를 매개변수로 받고,
        2. // 현재 날짜와 시간을 기록하고, 그
        3. // 이름을 전역 자료구조에 추가하는
        4. // 함수를 작성한다고 하자.
        5.  
        6. std::multiset<std::string> names; // 전역 자료구조
        7.  
        8. void logAndAdd(const std::string& name)
        9. {
        10. auto now = // 현재 시간을 얻는다.
        11. std::chrono::system_clock::now();
        13. log(now, "logAndAdd"); // 로그에 기록한다.
        15. name.emplace(name); // 이름을 전역 자료구조에
        16. } // 추가한다.
        17.  
        18. // 잘 작동하지만 비효율적인 부분이 남아 있다.
        19.  
        20. std::string petName("Darla");
        21.  
        22. logAndAdd(petName); // 좌측값 std::string을 넘겨줌
        23.  
        24. logAndAdd(std::string("Persephone")); // 우측값 std::string을 넘겨줌
        25.  
        26. logAndAdd("Patty Dog"); // 문자열 리터럴을 넘겨줌
        27.  
        28. // 좌측값 std::string을 넘겨줄 때는 어차피
        29. // 복사가 일어나야 하므로 별 문제가 없다.
        30.  
        31. // 우측값 std::string을 넘겨줄 때는
        32. // 복사 대신 이동을 할 수 있지만,
        33. // 지금 구현에서는 복사가 일어난다.
        34.  
        35. // 문자열 리터럴을 넘겨주는 경우에는,
        36. // 문자열 리터럴로부터 임시 std::string
        37. // 객체(우측값)가 생성되고, 그 임시
        38. // 객체가 복사된다.
        39.  
        40. // 만일, 문자열 리터럴을 emplace에 그대로
        41. // 전달했다면, 임시 객체도 생성되지 않고
        42. // std::multiset 안에서 직접 std::string
        43. // 객체를 생성했을 것이다.
        44.  
        45. // 이 문제를 해결하려면 logAndAdd가 보편 참조(universal reference)
        46. // (항목 24 참고)를 받게 하고,
        47. // 항목 25의 조언을 따라 그 참조를
        48. // std::forward를 이용해서 emplace에
        49. // 전달하면 된다.
        50.  
        51. template <typename T>
        52. void logAndAdd(T&& name)
        53. {
        54. auto now = std::chrono::system_clock::now();
        55. log(now, "logAndAdd");
        56. names.emplace(std::forward<T>(name));
        57. }
        58.  
        59. std::string petName("Darla"); // 이전과 동일
        60.  
        61. logAndAdd(petName); // 이전처럼 좌측값이
        62. // multiset으로 복사됨
        63.  
        64. logAndAdd(std::string("Persephone")); // 우측값을 이동한다
        65. // (복사가 아니라).
        66.  
        67.  
        68. logAndAdd("Patty Dog"); // 임시 std::string 객체를
        69. // 복사하는 대신, multiset
        70. // 안에 std::string을
        71. // 생성한다.
        72.  
        73. // 이제 최적의 효율을 달성했다.
        74.  
        75. // logAndAdd의 클라이언트 중에는
        76. // logAndAdd가 요구하는 문자열
        77. // 형태의 이름을 가리키는 색인만
        78. // 알고 있으며, logAndAdd는
        79. // 그 색인을 이용해서 이름
        80. // 테이블에서 이름을 조회해야 한다.
        81.  
        82. // 이런 클라이언트들을 위해
        83. // logAndAdd를 오버로딩한다고
        84. // 하자.
        85.  
        86. void logAndAdd(int idx)
        87. {
        88. auto now = std::chrono::system_clock::now();
        89. log(now, "logAndAdd");
        90. names.emplace(nameFromIdx(idx));
        91. }
        92.  
        93. // 두 오버로딩된 함수에 대한 호출들은
        94. // 예상대로 적절히 해소된다.
        95.  
        96. std::string petName("Darla"); // 이전과 동일
        97.  
        98. logAndAdd(petName); // 이전과 동일, 이들은
        99. logAndAdd(std::string("Persephone")); // 모두 T&&를 받는
        100. logAndAdd("Patty Dog"); // 오버로딩된 함수를 호출한다.
        101.  
        102. logAndAdd(22); // int 버전을 호출한다.
        103.  
        104. // 그런데 다음의 경우에는 예상대로
        105. // 작동하지 않는다.
        106.  
        107. short nameIdx;
        108. ... // nameIdx에 값을 대입
        109.  
        110. logAndAdd(nameIdx); // 오류!
        111.  
        112. // 보편 참조(universal reference)를 받는 버전은 T를 short&로
        113. // 추론할 수 있으며, 그러면 주어진
        114. // 인수와 정확히 부합하는 형태가 된다.
        115.  
        116. // int를 받는 버전은 short 인수를 int로
        117. // 승격(promotion)해야 호출과 부합한다.
        118.  
        119. // 보통의 오버로딩 해소 규칙에 따라,
        120. // 정확한 부합이 승격을 통한 부합보다.
        121. // 우선시된다.
        122.  
        123. // 결국 보편 참조(universal reference)를 받는 오버로딩된 함수가
        124. // 호출된다.
        125.  
        126. // 따라서 emplace에 short값이 전달되지만,
        127. // std::string의 생성자 중에 short를
        128. // 받는 버전이 없으므로, 오류가
        129. // 발생한다.

        
        
        예제 코드 접기
        
        
        

      • 완벽 전달 생성자들은 특히나 문제가 많다. 그런 생성자는 대체로 비const 좌측값들에 대한 복사 생성자보다 더 나은 부합이며, 기반 클래스 복사 및 이동 생성자들에 대한 파생 클래스의 호출들을 가로챌 수 있기 때문이다.

        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 다음과 같은 클래스가 있다고 하자.
        3.  
        4. class Person {
        5. public:
        6. template <typename T>
        7. explicit Person(T&& n) // 완벽 전달 생성자
        8. : name(std::forward<T>(n)) {} // 데이터 멤버를 초기화한다.
        10. explicit Person(int idx) // int를 받는 생성자
        11. : name(nameFromIdx(idx)) {}
        12. ...
        14. private:
        15. std::string name;
        16. };
        17.  
        18. // 항목 17에서 설명하듯이, 특정 조건에서
        19. // C++은 복사 생성자와 이동 생성자를
        20. // 자동으로 작성하며, 심지어 템플릿화된
        21. // 생성자가 복사 생성자나 이동 생성자에
        22. // 해당하는 시그니처로 인스턴스화되는 경우에도
        23. // 그러한 자동 작성이 일어난다.
        24.  
        25. // 따라서, Person은 사실상 다음과 같은
        26. // 모습이 된다.
        27.  
        28. class Person {
        29. public:
        30. template <typename T> // 완벽 전달 생성자
        31. explicit Person(T&& n)
        32. : name(std::forward<T>(n)) {}
        34. explicit Person(int idx); // int를 받는 생성자
        36. Person(const Person& rhs); // 복사 생성자
        37. // (컴파일러가 작성함)
        39. Person(Person&& rhs); // 이동 생성자
        40. // (컴파일러가 작성함)
        41. ...
        43. };
        44.  
        45. // 이런 상황에서 다음의 코드는
        46. // 이해할 수 없는 행동을 보인다.
        47.  
        48. Person p("Nancy");
        49.  
        50. auto cloneOfP(p); // p로부터 새 Person을 생성
        51. // 컴파일에 실패한다!
        52.  
        53. // 이 코드를 보면, 복사 생성자를 호출할 것
        54. // 같지만 사실 복사 생성자를 호출하지 않는다.
        55.  
        56. // 실제로는 완벽 전달 생성자가 호출되며,
        57. // std::string에는 Person을 받는 생성자가
        58. // 없으므로 오류가 발생한다.
        59.  
        60. // 컴파일러의 추론은 다음과 같다.
        61.  
        62. // cloneOfP는 const가 아닌 좌측값(p)로
        63. // 초기화되며, 따라서 템플릿화된 생성자를
        64. // Person 타입의 비const 좌측값을 받는 형태로
        65. // 인스턴스화 할 수 있다.
        66.  
        67. // 그러한 인스턴스화가 끝나면 Person 클래스는
        68. // 다음과 같은 모습이 된다.
        69.  
        70. class Person {
        71. public:
        72. explicit Person(Person& n) // 완벽 전달 템플릿에서
        73. : name(std::forward<Person&>(n)) {} // 인스턴스화됨
        75. explicit Person(int idx); // 이전과 동일
        77. Person(const Person& rhs); // 복사 생성자
        78. // (컴파일러가 생성함)
        79. ...
        81. };
        82.  
        83. // 이제 다음과 같은 문장을 생각해 보자.
        84.  
        85. auto cloneOfP(p);
        86.  
        87. // 이 경우 p는 복사 생성자에 전달될 수도 있고
        88. // 인스턴스화된 템플릿에 전달될 수도 있다.
        89.  
        90. // 그런데 복사 생성자를 호출하려면 p에 const를
        91. // 추가해서 인수를 복사 생성자의 매개변수 타입과
        92. // 부합시켜야 한다.
        93.  
        94. // 그러나 인스턴스화된 템플릿은 아무것도
        95. // 추가하지 않아도 이미 정확히 부합한다.
        96.  
        97. // 즉 템플릿에서 인스턴스화된, 오버로딩된 함수가
        98. // 더 나은 부합이다.
        99.  
        100. // 그 결과 컴파일러는 템플릿에서 인스턴스화된
        101. // 생성자를 호출하는 코드를 산출한다.
        102.  
        103. // 복사할 객체가 const가 되도록 예제를
        104. // 조금만 바꾸면 상황이 완전히 달라진다.
        105.  
        106. const Person cp("Nancy"); // 객체가 이제는 const
        107.  
        108. auto cloneOfP(cp); // 복사 생성자를 호출한다!
        109.  
        110. // 물론 템플릿화된 생성자 역시 복사 생성자와
        111. // 동일한 시그니처로 인스턴스화될 수 있다.
        112.  
        113. class Person {
        114. public:
        115. explicit Person(const Person& n); // 템플릿에서
        116. // 인스턴스화됨
        118. Person(const Person& rhs); // 복사 생성자
        119. // (컴파일러가 생성함)
        120. ...
        121. };
        122.  
        123. // 그러나 C++의 오버로딩 해소 규칙 중에는,
        124. // 어떤 함수 호출이 템플릿 인스턴스와
        125. // 비템플릿 함수에 똑같이 부합한다면
        126. // 보통 함수를 우선시한다는 규칙이 있어서
        127. // 이런 경우에는 복사 생성자가 호출된다.
        128.  
        129.  
        130. //-----------------------------------------------------------------------------
        131. // 상속이 관여하는 클래스에는 완벽 전달 생성자와
        132. // 컴파일러가 작성한 복사 및 이동 연산들 사이의
        133. // 상호작용이 미치는 여파가 더욱 크다.
        134.  
        135. // 특히, 파생 클래스에서 통상적인 방식으로
        136. // 구현한 복사 및 이동 연산들이 상당히 놀라운
        137. // 행동을 보인다.
        138.  
        139. class SpecialPerson: public Person {
        140. public:
        141. SpecialPerson(const SpecialPerson& rhs) // 복사 생성자;
        142. : Person(rhs); // 기반 클래스의 완벽
        143. { ... } // 전달 생성자를 호출
        145. SpecialPerson(SpecialPerson&& rhs) // 이동 생성자;
        146. : Person(std::move(rhs)) // 기반 클래스의 완벽
        147. { ... } // 전달 생성자를 호출
        148. };
        149.  
        150. // 파생 클래스의 복사, 이동 생성자들은 해당 기반
        151. // 클래스의 복사, 이동 생성자를 호출하지 않고
        152. // 기반 클래스의 완벽 전달 생성자를 호출한다.
        153.  
        154. // 왜 그런지는 파생 클래스 함수들이 SpecialPerson
        155. // 타입의 인수를 기반 클래스에 넘겨준다는 점에
        156. // 주목해서 Person 클래스 안에서의 템플릿
        157. // 인스턴스화 오버로딩 해소 과정을 짚어 보면
        158. // 이해할 수 있다.
        159.  
        160. // 결과적으로, SpecialPerson을 받는 std::string
        161. // 생성자가 없어서 컴파일되지 않는다.

        
        
        예제 코드 접기
        
        
        그러면, 대부분의 인수 타입들을 전달하되 일부 인수 타입들은 특별한 방식으로 처리하는 함수는 어떻게 만들어야 할까? 해결책은 여러 가지인데, 이것에 관한 자세한 내용은 항목 27(바로 다음 항목)을 보기 바란다.

  27. 보편 참조(universal reference)에 대한 오버로딩 대신 사용할 수 있는 기법들을 알아 두라 / 197

      이번 항목의 논의는 항목 26에 나온 예제들에 기초한다. 그 항목을 아직 읽지 않았다면, 먼저 읽고 돌아오는 것이 좋을 것이다.

      • 보편 참조(universal reference)와 오버로딩의 조합에 대한 대안으로는 구별되는 함수 이름 사용, 매개변수를 const에 대한 좌측값 참조로 전달, 매개변수를 값으로 전달, 꼬리표 배분 사용 등이 있다.

        오버로딩을 포기한다.
        단순히 오버로딩을 포기하고 보편 참조(universal reference)를 매개변수로 받는 함수와 그렇지 않은 함수의 이름을 다르게 만드는 것이다. 하지만 생성자의 경우, 이름이 고정되어 있어서 이 방법을 적용할 수 없다.
        
        
        
        const T& 매개변수를 사용한다.
        보편 참조(universal reference)를 매개변수로 받는 대신, const T&를 매개변수로 받도록 하고 오버로딩을 하는 것이다. 즉 효율성을 포기하는 대신, 예상치 않은 문제를 피하는 것이다.
        
        
        
        값 전달 방식의 매개변수를 사용한다.
        이 설계는 항목 41의 조언, 즉 복사될 것이 확실한 객체는 값으로 전달하는 것을 고려하라는 조언과 일치한다.
        
        값 전달 방식의 매개변수를 사용하는 예제 코드 보기
        
        
        

        1. class Person {
        2. public:
        3. explicit Person(std::string n) // T&& 생성자를 대체한다;
        4. : name(std::move(n)) {} // std::move의 용법은
        5. // 항목 41을 보라
        7. explicit Person(int idx) // 이전과 동일
        8. : name(nameFromIdx(idx)) {}
        10. private:
        11. std::string name;
        12. };
        13.  
        14. // 이 방법도 const T& 매개변수를 사용하는
        15. // 방법과 마찬가지로 보편 참조(universal reference)에 대한 오버로딩의
        16. // 예상치 못한 문제를 피할 수 있게 해 준다.
        17.  
        18. // 이 경우 널 포인터를 뜻하는 0이나 NULL을
        19. // 사용했을 때 int 를 받는 오버로딩된 함수가 호출되는 문제가
        20. // 있지만, 0이나 NULL을 사용하려던 사람들은
        21. // 항목 8을 읽고 또 읽어야 할 것이다.

        
        
        값 전달 방식의 매개변수를 사용하는 예제 코드 접기
        
        
        
        
        꼬리표 배분을 사용한다.
        const 좌측값 참조 전달이나 값 전달은 완벽 전달을 지원하지 않는다. 보편 참조(universal reference)를 사용하려는 이유가 완벽 전달이라면, 보편 참조(universal reference) 말고는 다른 대안이 없다. 이런 경우에는 꼬리표 배분을 사용할 수 있다.
        
        일반적으로 보편 참조(universal reference) 매개변수는 전달된 인수에 대해 정확히 부합하지만, 매개변수 목록에 보편 참조(universal reference) 매개변수뿐만 아니라 보편 참조(universal reference)가 아닌 매개변수들도 포함되어 있으면, 보편 참조(universal reference)가 아닌 매개변수들에 대한 충분히 나쁜 부합이 보편 참조(universal reference) 매개변수가 있는 오버로딩된 함수를 제치고 선택될 가능성이 있다. 이것이 꼬리표 배분(tag dispatch) 접근방식에 깔린 기본 착안이다.
        
        꼬리표 배분(tag dispatch) 예제 코드 보기
        
        
        

        1. // 항목 26의 예제에 등장했던 logAndAdd 함수에
        2. // 꼬리표 배분 기법을 적용해 보자.
        3.  
        4. // 편의를 위해 해당 예제 코드를 다시 제시하겠다.
        5.  
        6. std::multiset<std::string> names; // 전역 자료구조
        7.  
        8. template <typename T> // 로그를 기록하고, 이름을
        9. void logAndAdd(T&& name) // 자료구조에 추가하는 함수
        10. {
        11. auto now = std::chrono::system_clock::now();
        12. log(now, "logAndAdd");
        13. names.emplace(std::forward<T>(name));
        14. }
        15.  
        16. // 이 함수는 그 자체로는 잘 작동하지만, 이름 조회에 사용할
        17. // int 타입의 색인 값을 받는 함수를 오버로딩하면 추가하면 항목 26에서
        18. // 말한 골치 아픈 문제들이 발생한다.
        19.  
        20. // 이번 항목의 목표는 그런 문제들을 피하는 것이다.
        21.  
        22. // 이를 위해 int를 받는 버전을 오버로딩하는 대신,
        23. // logAndAdd가 호출을 다른 두 함수로 위임하게 한다.
        24.  
        25. // 하나는 정수 값을 위한 함수이고 다른 하나는 그 외의
        26. // 모든 것을 위한 함수이다.
        27.  
        28. // logAndAdd 자체는 모든 인수 타입을 받는다.
        29.  
        30. // 실제 작업을 수행하는 두 함수의
        31. // 이름은 logAndAddImpl로 한다.
        32.  
        33. // logAndAddImpl은 애초에 전달된 인수가
        34. // 정수 타입인지 아닌지를 뜻하는 또 다른
        35. // 매개변수를 받는다.
        36.  
        37. // 이 둘째 매개변수는 두 오버로딩 중 어떤 것이
        38. // 선택되었는지를 우리가 원하는 방식으로 제어하는
        39. // 용도로 쓰인다.
        40.  
        41. template <typename T>
        42. void logAndAdd(T&& name)
        43. {
        44. logAndAddImpl(std::forward<T>(name),
        45. std::is_integral<T>()); // 아주 정확하지는 않음
        46. }
        47.  
        48. // std::is_integral<T>는 T가 정수 타입일 때에는
        49. // 참이 되고, 그렇지 않으면 거짓이 된다.
        50.  
        51. // 문제는 int 타입의 좌측값이 logAndAdd에 전달되면
        52. // T는 int&로 추론된다는 점이다.
        53.  
        54. // 참조는 정수 타입이 아니므로, std::is_integral<int&>는
        55. // 거짓이 된다.
        56.  
        57. // 이 문제는, 항목 9에서 보았던 std::remove_reference라는
        58. // 타입 특성을 사용하여 모든 참조 한정사를 제거하면 해결된다.
        59.  
        60. template <typename T>
        61. void logAndAdd(T&& name)
        62. {
        63. logAndAddImpl(
        64. std::forward<T>(name),
        65. std::is_integral<typename std::remove_reference<T>::type>()
        66. );
        67. }
        68.  
        69. // C++14에서는 std::remove_reference_t<T>를
        70. // 사용해서 타자량을 더 줄일 수 있다(항목 9를 보라).
        71.  
        72. // 이제 logAndAddImpl로 주의를 돌리자.
        73.  
        74. // 이 함수는 보편 참조(universal reference)를 받는 버전과 정수
        75. // 타입을 받는 버전의 오버로딩이 있다.
        76.  
        77. // 우선 보편 참조(universal reference)를 받는 버전을 보자.
        78.  
        79. template <typename T> // 비정수 인수를
        80. void logAndAddImpl(T&& name, std::false_type) // 받는 버전:
        81. { // 그 인수를 전역
        82. auto now = std::chrono::system_clock::now(); // 자료구조에 추가
        83. log(now, "logAndAdd"); // 한다.
        84. names.emplace(std::forward<T>(name));
        85. }
        86.  
        87. // true와 false는 실행 시점 값이다.
        88.  
        89. // 하지만 logAndAddImpl의 오버로딩 버전들은
        90. // 컴파일 시점에 선택되어야 하므로 컴파일
        91. // 시점 값이 필요하다.
        92.  
        93. // 이러한 컴파일 시점 논리값(타입)이 바로
        94. // std::true_type과 std::false_type 이다.
        95.  
        96. // logAndAdd가 logAndAddImpl에 전달하는 인수는,
        97. // 만일 T가 정수 타입이면 std::true_type을 상속하는
        98. // 어떤 타입의 객체이고 만일 T가 정수 타입이 아니면
        99. // std::false_type을 상속하는 어떤 타입의 객체이다.
        100.  
        101. // 결과적으로, 이 logAndAddImpl 오버로딩은
        102. // 정수 타입이 아닌 T로 logAndAdd를 호출했을
        103. // 때에만 적법한 후보가 된다.
        104.  
        105. // T가 정수 타입일 때 호출되는 logAndAddImpl의
        106. // 오버로딩 버전은 다음과 같다.
        107.  
        108. std::string nameFromIdx(int idx); // 항목 26에 나옴
        109.  
        110. void logAndAddImpl(int idx, std::true_type) // 정수 인수를
        111. { // 받는 버전:
        112. logAndAdd(nameFromIdx(idx)); // 조회한 이름으로
        113. } // logAndAdd를
        114. // 호춣한다.
        115.  
        116. // std::true_type과 std::false_type 타입의
        117. // 매개변수는 실제로 사용되는 매개변수는 아니므로
        118. // 매개변수의 이름을 생략할 수 있다.

        
        
        꼬리표 배분(tag dispatch) 예제 코드 접기
        
        
        이 방법에도 한계는 있다. 보편 참조(universal reference)를 받는 함수가 logAndAdd처럼 일반 함수가 아니라 생성자인 경우에는, 컴파일러가 자동으로 생성한 복사생성자가 문제가 될 수 있다(항목 26 참고). 이런 문제까지 해결하려면, 템플릿을 제한하는 방법을 써야 한다.

      • std::enable_if를 이용해서 템플릿의 인스턴스화를 제한함으로써 보편 참조(universal reference)와 오버로딩을 함께 사용할 수 있다. std::enable_if는 컴파일러가 보편 참조(universal reference) 오버로딩을 사용하는 조건을 프로그래머가 직접 제어하는 용도로 쓰인다.

        보편 참조(universal reference)를 받는 템플릿을 제한한다.
        std::enable_if를 이용하면 컴파일러가 마치 특정 템플릿이 존재하지 않는 것처럼 행동하게 만들 수 있다. 그런 템플릿을 비활성화된(disabled) 템플릿이라고 부른다.
        
        기본적으로 모든 템플릿은 활성화된(enabled) 상태이나, std::enable_if를 사용하는 템플릿은 오직 그 std::enable_if에 지정된 조건이 만족될 때에만 활성화된다.
        
        보편 참조(universal reference)를 받는 템플릿을 제한하는 예제 코드 보기
        
        
        

        1. // 다음은 Person 클래스의 완벽 전달 생성자
        2. // 선언인데, std::enable_if는 전반적인 틀만
        3. // 표시했다.
        4.  
        5. // 그리고 std::enable_if는 함수의 구현에 아무런
        6. // 영향도 미치지 않으므로, 완벽 전달 생성자의
        7. // 구현은 생략했다.
        8.  
        9. // 구현은 항목 26에 나온 것과 동일하다.
        10.  
        11. class Person {
        12. public:
        13. template <typename T,
        14. typename = typename std::enable_if<조건>::type>
        15. explicit Person(T&& n);
        17. ...
        18. };
        19.  
        20. // 함수 템플릿의 두 번째 타입인수에서 일어나는 일을
        21. // 설명하기에는 시간이 너무 걸린다.
        22.  
        23. // 따라서 그 원리가 궁금하다면 다른 책이나 자료를
        24. // 찾아보기 바란다.
        25.  
        26. // 참고로 std::enable_if 뿐만 아니라 "SFINAE"도
        27. // 살펴보기 바란다. std::enable_if가 작동하는 것은
        28. // 바로 이 "SFINAE" 덕분이기 때문이다.
        29.  
        30. // 여기서는 std::enable_if의 "조건" 부분에 중점을
        31. // 두도록 할것이다.
        32.  
        33. // 위의 완벅 전달 생성자와 복사 생성자가 충돌하지 않으려면
        34. // 완벽 전달 생성자에 넘겨진 타입이 Person인 경우에는 템플릿을
        35. // 비활성화 시켜야 한다.
        36.  
        37. // 이 때, 두 타입이 같은지를 비교하는 std::is_same을 사용한다.
        38.  
        39. // !std::is_same<Person, T>::value는 Person과
        40. // T가 다른 경우 참이 된다.
        41.  
        42. // 여기서도 꼬리표 배분에서 만났던 문제와 비슷한 문제가 생긴다.
        43. // 다음을 보자.
        44.  
        45. Person p("Nancy");
        46.  
        47. auto cloneOfP(p); // 좌측값으로 초기화됨
        48.  
        49. // 이 때, 보편(universal) 생성자의 타입 T는 Person&로 추론된다.
        50.  
        51. // Person이라는 타입과 Person&라는 타입은 같지 않으므로,
        52. // std::is_same은 둘이 다르다고 판정한다.
        53.  
        54. // 이 경우 외에도 const성이나 volatile성도
        55. // 영향을 줄 수 있다.
        56.  
        57. // 따라서 참조 한정사와 const, volatile을 모두
        58. // 무시하고 타입을 비교해야 한다.
        59.  
        60. // 이런 용도로 쓰는 것이 std::decay이다.
        61.  
        62. // std::decay는 모든 참조와 모든 cv-한정사
        63. // (const 한정사나 volatile 한정사)를 제거한다
        64. // (그 외에도 std::decay는 배열과 함수 타입을
        65. // 포인터로 바꾸지만, 지금 논의에서는 중요하지 않다).
        66.  
        67. // 따라서, 생성자의 활성화를 제어하는 바람직한
        68. // 조건 표현식은 다음과 같이 쓸 수 있다.
        69.  
        70. !std::is_same<Person, typename std::decay<T>::type>::value
        71.  
        72. // 이를 적용해서 앞에서 본 예제 코드를 고쳐 보았다.
        73.  
        74. class Person {
        75. public:
        76. template <
        77. typename T,
        78. typename = typename std::enable_if<
        79. !is_same<Person,
        80. typename std::decay<T>::type
        81. >::value
        82. >::type
        83. >
        84. explicit Person(T&& n);
        86. ...
        87. };
        88.  
        89. // 하지만 아직도 문제가 있다. 바로 상속이 관여하는 경우이다.
        90.  
        91. // 다음 예제는 항목 26에서 보았던 예제 중의 하나이다.
        92.  
        93. class SpecialPerson: public Person {
        94. public:
        95. SpecialPerson(const SpecialPerson& rhs) // 복사 생성자; 기반
        96. : Person(rhs) // 클래스의 완벽 전달
        97. { ... } // 생성자를 호출한다!
        99. SpecialPerson(SpecialPerson&& rhs) // 이동 생성자; 기반
        100. : Person(std::move(rhs)) // 클래스의 완벽 전달
        101. { ... } // 생성자를 호출한다!
        103. ...
        104. };
        105.  
        106. // SpecialPerson 객체를 복사하거나 이동할 때
        107. // 해당 객체의 기반 클래스 부분은 기반 클래스의
        108. // 이동, 복사 생성자들이 처리할 것이라고 기대하는
        109. // 것이 자연스럽다.
        110.  
        111. // 그러나 위의 복사, 이동 생성자들은 SpecialPerson
        112. // 객체를 기반 클래스의 생성자들에 넘겨주는데,
        113. // SpecialPerson은 Person과 같지 않으므로
        114. // (std::decay를 적용한 후에도 마찬가지) 기반
        115. // 클래스의 보편 참조(universal reference) 생성자 템플릿이 활성화되며,
        116. // 그 템플릿으로부터 SpecialPerson 인수와 정확히
        117. // 부합하는 인스턴스가 만들어진다.
        118.  
        119. // 즉 이는, 항목 26에서 본 문제점이
        120. // 그대로 재현되는 것이다.
        121.  
        122. // 인수 타입이 단지 Person이 아니면 템플릿화된
        123. // 생성자를 활성화하는 것이 아니라, Person도 아니고
        124. // Person에서 파생된 타입도 아닐 때에만 활성화
        125. // 해야 한다.
        126.  
        127. // 이럴 때 쓸 수 있는 것이 std::is_base_of이다.
        128.  
        129. // std::is_base_of<T1, T2>::value는 만일 T2가
        130. // T1에서 파생된 타입이면 참이다.
        131.  
        132. // 사용자 정의 타입은 자기 자신으로부터
        133. // 파생된 것으로 간주된다.
        134.  
        135. // 즉, std::is_base_of<T, T>::value는 만일 T가 사용자
        136. // 정의 타입이면 참이다(T가 내장 타입일 때에는 거짓이다).
        137.  
        138. // 따라서 std::is_same을 std::is_base_of로
        139. // 바꾸기만 하면 목적을 달성할 수 있다.
        140.  
        141. class Person {
        142. public:
        143. template <
        144. typename T,
        145. typename = typename std::enable_if<
        146. !std::is_base_of<Person,
        147. typename std::decay<T>::type
        148. >::value
        149. >::type
        150. >
        151. explicit Person(T&& n);
        153. ...
        154. };
        155.  
        156. // C++11에서는 이것이 최종적인 해답이지만,
        157. // C++14에서는 좀 더 타자량을 줄일 수 있다.
        158.  
        159. class Person { // C++14
        160. public:
        161. template <
        162. typename T,
        163. typename = std::enable_if_t< // 코드가 더 짧다.
        164. !std::is_base_of<Person,
        165. std::decay_t<T> // 여기와
        166. >::value
        167. > // 여기도 더 짧다.
        168. >
        169. explicit Person(T&& n);
        171. ...
        172. };
        173.  
        174. // 만일 정수 타입을 받는 생성자도 있다면,
        175. // 정수 타입의 인수에 대해서도 보편(universal) 생성자
        176. // 템플릿을 비활성화 시켜야 한다.
        177.  
        178. // 그것 역시 앞에서 배운 내용들을 활용하면
        179. // 어렵지 않게 구현할 수 있다.
        180.  
        181. class Person {
        182. public:
        183. template <
        184. typename T,
        185. typename = std::enable_if_t<
        186. !std::is_base_of<Person, std::decay_t<T> >::value
        187. &&
        188. !std::is_integral<std::remove_reference_t<T> >::value
        189. >
        190. >
        191. explicit Person(T&& n) // std::string이나
        192. : name(std::forward<T>(n)) // std::string으로 변환되는
        193. { ... } // 인수를 위한 생성자
        195. explicit Person(int idx) // 정수 인수를 위한 생성자
        196. : name(nameFromIdx(idx))
        197. { ... }
        199. ... // 기타 복사, 이동 연산자들
        201. private:
        202. std::string name;
        203. };

        
        
        보편 참조(universal reference)를 받는 템플릿을 제한하는 예제 코드 접기
        
        
        

      • 보편 참조(universal reference) 매개변수는 효율성 면에서 장점인 경우가 많지만, 대체로 사용성 면에서는 단점이 된다.

        절충점들
        완벽 전달에도 단점은 있다. 그중 하나는, 완벽 전달이 불가능한 인수들이 있다는 점이다. 구체적인 타입을 받는 함수에는 전달할 수 있어도 완벽 전달은 불가능할 수 있다. 이처럼 완벽 전달이 실패하는 경우들을 항목 30에서 살펴본다.
        
        완벽 전달의 또 다른 단점은, 클라이언트가 유효하지 않은 인수를 전달했을 때 나오는 오류 메시지가 난해하다는 점이다. 예를 들어 char(std::string을 구성하는) 가 아니라 char16_t(C++11에서 도입된, 16비트 문자를 표현하는 타입)들로 이루어진 문자열 리터럴을 전달해서 Person 객체를 생성한다고 하자.
        
        Person p(u"Konrad Zuse");
        // "Konrad Zuse"는 const char16_t
        // 타입의 문자들로 이루어짐
        
        이번 항목에서 살펴본 처음 세 접근방식에서 컴파일러는 int나 std::string을 받는 생성자들이 있음을 인식하며, const char16_t[12]를 int나 std::string으로 변환할 수 없음을 뜻하는 다소 직접적인 오류 메시지를 출력한다.
        
        그러나 완벽 전달에 기초한 접근방식에서는 컴파일러가 const char16_t들의 배열을 아무 불평 없이 생성자의 매개변수에 묶는다. 생성자는 그 매개변수를 Person의 std::string 데이터 멤버의 생성자에 전달하며, 그때야 호출자가 전달한 것과 필요한 것 사이의 불일치가 발견된다.
        
        이런 상황에서 어떤 한 컴파일러는 160줄 이상의 오류 메시지를 출력했다.
        
        이 예에서는 보편 참조(universal reference)가 한 번만 전달되지만, 시스템이 복잡할수록 보편 참조(universal reference)가 여러 층의 함수 호출들을 거쳐서 최종적인 지점에 도달한 후 인수 타입(들)의 허용 여부 판정이 일어날 가능성도 커진다. 보편 참조(universal reference)가 전달되는 횟수가 많을수록, 오류 메시지도 장황해진다.
        
        이러한 이유로 인해, 보편 참조(universal reference)를 성능이 최우선적인 관심사인 인터페이스에만 사용하는 것이 좋다고 생각하는 개발자들이 많다.
        
        Person의 경우 전달 함수의 보편 참조(universal reference) 매개변수가 std::string에 대한 초기치로 쓰일 것을 알고 있으므로, 그런 초기치로 사용하는 것이 가능한지를 미리 static_assert를 이용해서 점검하는 방법도 있다.
        
        std::is_constructible이라는 타입 특성은 한 타입의 객체를 다른 한 타입(또는 타입들의 집합)의 객체(또는 객체들의 집합)로부터 생성할 수 있는지를 컴파일 시점에서 판정한다.
        
        이를 이용하면 그러한 단언(assertion)을 손쉽게 작성할 수 있다.
        
        static_assert 예제 코드 보기
        
        
        

        1. class Person {
        2. public:
        3. template < // 이전과 동일
        4. typename T,
        5. typename = std::enable_if_t<
        6. !std::is_base_of<Person, std::decay_t<T> >::value
        7. &&
        8. !std::is_integral<std::remove_reference_t<T> >::value
        9. >
        10. >
        11. explicit Person(T&& n)
        12. : name(std::forward<T>(n))
        13. {
        14. // T 객체로부터 std::string을 생성할 수 있는지 점검한다.
        15. static_assert(
        16. std::is_constructible<std::string, T>::value,
        17. "Parameter n can't be used to construct a std::string"
        18. );
        20. ... // 여기서 통상적인 생성자 작업을 수행한다.
        22. }
        24. ... // Person 클래스의 나머지 부분(이전과 동일)
        26. };
        27.  
        28. // 이렇게 하면, 클라이언트가 std::string의 생성에
        29. // 사용할 수 없는 타입의 인수로 Person 객체를
        30. // 생성하려 할 때 그 점을 구체적으로 지적하는
        31. // 오류 메시지가 출력된다.

        
        
        static_assert 예제 코드 접기
        
        
        안타깝게도, 이 예에서 static_assert는 생성자의 본문에 있지만, 매개변수를 전달하는 코드는 그보다 앞에 나오는 멤버 초기화 리스트에 있다. 어떤 컴파일러의 경우, static_assert에서 비롯된 깔끔하고 읽기 좋은 메시지는 통상적인 오류 메시지 (160줄 이상의)가 출력된 이후에야 출력된다.

  28. 참조 축약(collapse)을 숙지하라 / 211

      • 참조 축약(collapse)은 템플릿 인스턴스화, auto 타입 추론, typedef와 별칭 선언의 지정 및 사용, decltype의 지정 및 사용이라는 네 가지 문맥에서 일어난다.

        우선, C++에서 참조에 대한 참조는 위법임을 짚고 넘어갈 필요가 있겠다. 그런 참조를 선언하려 하면 컴파일러의 질책을 받게 된다.
        
        int x;
        ...
        auto& & rx = x;
        // 오류! 참조에 대한 참조는
        // 선언할 수 없음
        
        그런데 보편 참조(universal reference)를 받는 함수 템플릿에 좌측값을 넘겨주면 어떤 일이 생기는지 생각해 보자.
        
        template <typename T>
        void func(T&& param);
        
        Widget w;
        
        func(w);
        // func를 좌측값으로 호출한다;
        // T는 Widget&로 추론된다.
        
        T에 대해 추론된 타입으로 템플릿을 인스턴스화한 결과는 다음과 같은 모습일 것이다.
        
        void func(Widget& && param);
        
        이는 참조에 대한 참조이지만, 그래도 컴파일러는 불평하지 않는다. 보편 참조(universal reference) param은 좌측값으로 초기화되므로, param의 타입은 좌측값 참조가 된다(항목 24 참고).
        
        따라서 컴파일러가 T에 대해 추론된 타입을 템플릿에 대입하면 위와 같은 시그니처가 나온다. 그러나 실제로 만들어지는 최종적인 함수 시그니처는 다음과 같다.
        
        void func(Widget& param);
        
        어떻게 이런 일이 일어난 것일까? 답은 바로 참조 축약(reference collapsing)이다. 참조에 대한 참조가 위법인 것은 사실이지만, 특정 문맥에서는 컴파일러가 참조에 대한 참조를 산출하는 것이 허용된다. 템플릿 인스턴스화가 그런 문맥 중 하나이다.
        
        참조 축약(collapse)이 일어나는 문맥은 네 가지이다. 첫째이자 가장 흔한 것은 템플릿 인스턴스화이다. 나머지 경우는 다음의 예제에서 찾길 바란다.
        
        참조 축약(collapse) 예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 참조 축약(collapse)이 일어나는 둘째 문맥은 auto
        3. // 변수에 대한 타입 추론이다.
        4.  
        5. Widget w;
        6.  
        7. auto&& w1 = w;
        8.  
        9. // 이 선언은 w1을 좌측값으로 초기화하며, 따라서
        10. // auto의 타입은 Widget&로 추론된다.
        11.  
        12. // Widget&를 w1 선언의 auto에 대입하면
        13. // 다음과 같이 참조 대 참조가 나타난다.
        14.  
        15. Widget& && w1 = w;
        16.  
        17. // 참조 축약(collapse)에 의해 이는 다음과
        18. // 같은 코드로 바뀐다.
        19.  
        20. Widget& w1 = w;
        21.  
        22. // 결과적으로, w1은 좌측값 참조이다.
        23.  
        24. // 반면 다음 선언은
        25.  
        26. auto&& w2 = widgetFactory();
        27.  
        28. // w2를 우측값으로 초기화하며, 따라서 auto는
        29. // 비참조 타입 Widget으로 추론된다.
        30.  
        31. // Widget을 auto에 대입하면
        32.  
        33. Widget&& w2 = widgetFactory();
        34.  
        35. // 이 나오는데, 여기에는 참조 대 참조가 없으므로
        36. // 이것으로 끝이다. w2는 우측값 참조이다.
        37.  
        38.  
        39. //-----------------------------------------------------------------------------
        40. // 참조 축약(collapse)이 일어나는 셋째 문맥은
        41. // typedef와 별칭 선언(항목 9)의
        42. // 지정 및 사용이다.
        43.  
        44. // typedef가 지정 또는 평가되는 도중에
        45. // 참조에 대한 참조가 발생하면 참조 축약(collapse)이
        46. // 끼어들어서 참조에 대한 참조를 제거한다.
        47.  
        48. // 예를 들어 다음처럼 Widget 클래스 템플릿 안에
        49. // 우측값 참조 타입에 대한 typedef가 포함되어
        50. // 있다고 하자.
        51.  
        52. template <typename T>
        53. class Widget {
        54. public:
        55. typedef T&& RvalueRefToT;
        56. ...
        57. };
        58.  
        59. // 그리고 Widget을 좌측값 참조 타입으로
        60. // 인스턴스화한다고 하자.
        61.  
        62. Widget<int&> w;
        63.  
        64. // Widget의 T를 int&로 대체하면
        65. // typedef는 다음과 같은 모습이 된다.
        66.  
        67. typedef int& && RvalueRefToT;
        68.  
        69. // 참조 축약(collapse)에 의해 이는 다음으로
        70. // 줄어든다.
        71.  
        72. typedef int& RvalueRefToT;
        73.  
        74. // typedef에 붙인 이름이 오히려 혼란을
        75. // 줄 수 있음이 명백해졌다.
        76.  
        77. // Widget을 좌측값 참조 타입으로 인스턴스화하면,
        78. // RvalueRefToT는 우측값 참조가 아니라 좌측값 참조에
        79. // 대한 typedef가 된다.
        80.  
        81.  
        82. //-----------------------------------------------------------------------------
        83. // 참조 축약(collapse)이 일어나는 마지막 문맥은
        84. // decltype 사용이다.
        85.  
        86. // decltype에 관여하는 타입을 분석하는 도중에
        87. // 참조에 대한 참조가 발생하면 참조 축약(collapse)이
        88. // 등장해서 그것을 제거한다.
        89.  
        90. // decltype에 대해서는 항목 3을 보라.

        
        
        참조 축약(collapse) 예제 코드 접기
        
        
        

      • 컴파일러가 참조 축약(collapse) 문맥에서 참조에 대한 참조를 만들어 내면, 그 결과는 하나의 참조가 된다. 원래의 두 참조 중 하나라도 좌측값 참조이면 결과는 좌측값 참조이고, 그렇지 않으면 우측값 참조이다.

        참조는 두 종류(좌측값과 우측값)이므로, 참조에 대한 참조로 가능한 조합은 총 네 가지이다(좌측값에 대한 좌측값, 우측값에 대한 좌측값, 좌측값에 대한 우측값, 우측값에 대한 우측값). 참조에 대한 참조가 허용되는 문맥에서 참조에 대한 참조는 다음 규칙에 따라 하나의 참조로 축약된다(collapse).
        
        
        만일 두 참조 중 하나라도 좌측값 참조이면 결과는 좌측값 참조이다. 그렇지 않으면(즉, 둘 다 우측값 참조이면) 결과는 우측값 참조이다.

      • 타입 추론이 좌측값과 우측값을 구분하는 문맥과 참조 축약(collapse)이 일어나는 문맥에서 보편 참조(universal reference)는 우측값 참조이다.

        보편 참조(universal reference)와 좌측값·우측값 부호화에 대한 사실들을 다음과 같은 템플릿에 적용한다면,
        
        template <typename T>
        void func(T&& param);
        
        템플릿 매개변수 T에 대해 추론된 타입에는 param으로 전달된 인수가 좌측값이었는지 아니면 우측값이었는지에 대한 정보가 부호화될 것이라는 결론을 이끌어 낼 수 있다.
        
        이러한 부호화의 메커니즘은 간단하다. 좌측값 인수가 전달되면 T는 좌측값 참조로 추론된다. 우측값이 전달되면 T는 비참조(non-reference) 타입으로 추론된다.
        
        다음 예를 보자.
        
        Widget widgetFactory();
        // 우측값을 돌려주는 함수
        
        Widget w;
        // 변수(좌측값)
        
        func(w);
        // func를 좌측값으로 호출한다;
        // T는 Widget&로 추론된다.
        
        func(widgetFactory());
        // func를 우측값으로 호출한다;
        // T는 Widget으로 추론된다.
        
        기본적으로, std::forward가 작동하는 것은 참조 축약(collapse) 덕분이다. 항목 25에서 설명하듯이 std::forward는 보편 참조(universal reference) 매개변수에 적용된다.
        
        std::forward 예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // std::forward 함수의 일반적인 용례는
        3. // 다음과 같은 모습이다.
        4.  
        5. template <typename T>
        6. void f(T&& fParam)
        7. {
        8. ... // 어떤 작업을 수행
        10. someFunc(std::forward<T>(fParam)); // fParam을
        11. } // someFunc로 전달
        12.  
        13. // std::forward는 대략 다음과 같이 생겼을
        14. // 것이다. 이것은 완벽히 정확한 구현은 아니지만,
        15. // std::forward의 작동 방식을 이해하는
        16. // 목적으로는 충분하다.
        17.  
        18. template <typename T> // 이름공간
        19. T&& forward(typename remove_reference<T>::type& param) // std 안에서
        20. {
        21. return static_cast<T&&>(param);
        22. }
        23.  
        24.  
        25. //-----------------------------------------------------------------------------
        26. // f에 전달된 인수가 Widget
        27. // 타입의 좌측값이라고 하자.
        28.  
        29. // 그러면 T는 Widget&로 추론되며,
        30. // std::forward 호출은 std::forward<Widget&>
        31. // 형태로 인스턴스화된다.
        32.  
        33. // Widget&를 std::forward의 구현에 대입하면
        34. // 다음과 같은 코드가 나온다.
        35.  
        36. Widget& && forward(typename remove_reference<Widget&>::type& param)
        37. {
        38. return static_cast<Widget& &&>(param);
        39. }
        40.  
        41. // 타입 특성 std::remove_reference<Widget&>::type은
        42. // Widget을 산출하므로, std::forward는 다음이 된다.
        43.  
        44. Widget& && forward(Widget& param)
        45. {
        46. return static_cast<Widget& &&>(param);
        47. }
        48.  
        49. // 참조 축약(collapse)은 반환 타입과 캐스팅에도 적용된다.
        50. // 참조 축약(collapse)까지 적용한 최종 버전은 다음과 같이 된다.
        51.  
        52. Widget& forward(Widget& param) // 여전히 이름공간
        53. { // std 안에서
        54. return static_cast<Widget&>(param);
        55. }
        56.  
        57. // 이 예에서 보듯이, 좌측값 인수가 전달되면
        58. // std::forward는 좌측값 참조를 돌려준다.
        59.  
        60.  
        61. //-----------------------------------------------------------------------------
        62. // f에 전달된 인수가 Widget 타입의 우측값일
        63. // 때에는 어떻게 될까?
        64.  
        65. // 이 경우 f의 타입 매개변수 T에 대해 추론되는
        66. // 타입은 그냥 Widget이다.
        67.  
        68. // 따라서 f 내부의 std::forward 호출은
        69. // std::forward<Widget>으로 인스턴스화된다.
        70.  
        71. // std::forward의 구현에서 T를 Widget으로
        72. // 대체하면 다음과 같은 모습이 된다.
        73.  
        74. Widget&& forward(typename remove_reference<Widget>::type& param)
        75. {
        76. return static_cast<Widget&&>(param);
        77. }
        78.  
        79. // std::remove_reference를 비참조 타입 Widget에
        80. // 적용하면 애초의 타입(Widget)이 산출되므로, std::forward는
        81. // 다음이 된다.
        82.  
        83. Widget&& forward(Widget& param)
        84. {
        85. return static_cast<Widget&&>(param);
        86. }
        87.  
        88. // 여기에는 참조에 대한 참조가 없으므로 참조 축약(collapse)도 없다.
        89. // 이것이 이 호출에 대한 std::forward 인스턴스의 최종
        90. // 버전이다.
        91.  
        92. // 정리하자면, f에 전달된 우측값 인수는 하나의
        93. // 우측값으로써 someFunc에 전달되며, 이 역시 마땅히
        94. // 그래야 하는 결과이다.
        95.  
        96.  
        97. //-----------------------------------------------------------------------------
        98. // C++14에서는 std::remove_reference_t 덕분에
        99. // std::forward를 좀 더 간결하게 구현할 수 있다.
        100.  
        101. template <typename T> // C++14; 역시
        102. T&& forward(remove_reference_t<T>& param) // 이름공간 std
        103. { // 안에서
        104. return static_cast<T&&>(param);
        105. }

        
        
        std::forward 예제 코드 접기
        
        
        다음 두 조건이 만족되는 문맥에서 보편 참조(universal reference)는 사실상 오른쪽 참조이다.
        
        
        • 타입 추론에서 좌측값과 우측값이 구분된다. T 타입의 좌측값은 타입 T&로 추론되고, T 타입의 우측값은 타입 T로 추론된다.
        • 참조 축약(collapse)이 적용된다.

  29. 이동 연산이 존재하지 않고, 저렴하지 않고, 적용되지 않는다고 가정하라 / 217

      • 이동 연산들이 존재하지 않고, 저렴하지 않고, 적용되지 않을 것이라고 가정하라.

        우선 이동 의미론을 지원하지 않는 타입들이 많다는 점부터 살펴보자.
        
        C++11은 C++98 표준 라이브러리를 전체적으로 개정했는데, 특히 이동을 복사보다 빠르게 구현할 수 있는 타입들에는 이동 연산들을 추가했다. 또한 라이브러리 구성요소들의 구현을 그런 연산들의 장점을 취하도록 개정했다.
        
        그러나 여러분이 다루는 코드 기반은 C++11의 장점을 취하도록 완전히 개정되지 않았을 가능성이 있다. 여러분의 응용 프로그램(또는 여러분이 사용하는 라이브러리)에 있는 타입들이 C++11에 맞게 완전히 수정되지 않았다면, 컴파일러가 이동을 지원한다고 해도 응용 프로그램의 성능이 저절로 높아지지는 않을 것이다.
        
        이동 연산을 명시적으로 지원하지 않는 타입에 대해 C++11이 자동으로 이동 연산들을 작성해 주긴 하지만, 타입에 복사 연산자나 이동 연산, 소멸자가 하나라도 있으면 그러한 자동 작성은 일어나지 않는다(항목 17 참고).
        
        타입의 데이터 멤버나 기반 클래스에 이동이 비활성화되어 있으면, 역시 컴파일러의 이동 연산 작성은 일어나지 않는다. 이동을 명시적으로 지원하지 않으며 컴파일러의 이동 연산 작성의 대상이 아닌 타입에 대해서는, C++98에 비해 C++11이 어떤 형태로든 성능을 향상해 주리라고 기대할 이유가 없다.
        
        이동을 명시적으로 지원하는 타입에서도, 성능상의 이득이 생각만큼 크지 않을 수 있다.
        
        예를 들어 C++11 표준 라이브러리의 모든 컨테이너는 이동을 지원하지만, 모든 컨테이너의 이동이 저렴하다고 가정하는 것은 실수이다. 그 이유는, 이동을 저렴하게 만들 방법이 없는 컨테이너들도 있고, 컨테이너가 제공하는 진정으로 저렴한 이동 연산이 요구하는 까다로운 조건을 컨테이너 요소들이 만족할 수 없는 경우도 있기 때문이다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // C++11에 새로 도입된 컨테이너인
        3. // std::array를 생각해 보자.
        4.  
        5. // std::array는 내장 배열에 STL 인터페이스를
        6. // 씌운 것이다.
        7.  
        8. // 이 컨테이너는 자신의 내용을 힙에 저장하는
        9. // 다른 표준 컨테이너들과는 근본적으로 다르다.
        10.  
        11. // 개념적으로, 그런 컨테이너 타입의 객체는
        12. // 컨테이너의 내용이 저장된 힙 메모리를
        13. // 가리키는 포인터만 담는다.
        14.  
        15. // 컨테이너 전체 내용을 상수 시간으로 이동할 수
        16. // 있는 것은 바로 이 포인터 덕분이다.
        17.  
        18. // 그런데 std::array 객체에는 그런 포인터가 없다.
        19.  
        20. // std::array의 내용은 std::array 객체
        21. // 자체에 직접 저장되기 때문이다.
        22.  
        23. // std::array에 담긴 원소의 타입이 복사보다 빠른
        24. // 이동 연산을 지원한다면, 그 std::array는
        25. // 복사하는 것보다 이동하는 것이 더 빠르다.
        26.  
        27. std::array<Widget, 10000> aw1;
        28.  
        29. // aw1에 데이터를 채운다.
        30.  
        31. ...
        32.  
        33. // aw1을 aw2로 이동한다. 이 이동은
        34. // 선형 시간으로 실행된다. aw1의
        35. // 모든 원소가 aw2로 이동된다.
        36. auto aw2 = std::move(aw1);
        37.  
        38. // 만일 Widget의 이동 연산이 복사 연산보다
        39. // 빠르다면 aw1을 aw2로 복사하는 것 보다
        40. // 이동하는 것이 더 빠르다.
        41.  
        42. // 하지만, 더 빠르다고 해도 여전히 선형
        43. // 시간이 걸린다는 사실은 변함이 없다.
        44.  
        45. // aw1의 모든 요소를 일일히 이동해야
        46. // 하기 때문이다.
        47.  
        48.  
        49. //-----------------------------------------------------------------------------
        50. // std::string은 어떨까?
        51.  
        52. // 항상 이동이 복사보다 빠를것 같지만,
        53. // 그렇지 않을 수도 있다.
        54.  
        55. // 문자열 구현 중에는 작은 문자열 최적화
        56. // (small string optimization, SSO)를
        57. // 사용하는 것들이 많다.
        58.  
        59. // 그런 구현은 '작은' 문자열(이를테면 용량이 15자 이하인)
        60. // 을 std::string 객체 안의 버퍼에 저장하고,
        61. // 힙에 할당한 저장소는 사용하지 않는다.
        62.  
        63. // 이런 구현을 사용하는 std::string 객체는,
        64. // 작은 문자열의 경우 이동이 복사보다 빠르지 않다.

        
        
        예제 코드 접기
        
        
        빠른 이동을 지원하는 타입에서도, 겉으로 보기에 이동이 일어날 만한 상황에서 사실은 복사가 일어나는 경우가 생기기도 한다.
        
        항목 14에서 설명하듯이, 표준 라이브러리의 일부 컨테이너 연산들은 강한 예외 안전성을 보장한다. 이를 위해 이동 연산들이 예외를 던지지 않음이 확실한 경우에만 바탕 복사 연산들을 이동 연산들로 대체한다.
        
        이 때문에, 해당 복사 연산보다 효율적인 이동 연산을 제공하는 타입이라고 해도, 그리고 코드의 특성 지점에서 일반적으로 이동 연산이 적합하다고 해도, 해당 이동 연산이 noexcept로 선언되어 있지 않으면 컴파일러는 여전히 복사 연산을 호출할 수 있다.
        
        다음은 C++11의 이동 의미론이 도움이 되지 않는 몇 가지 시나리오이다.
        
        
        • 이동 연산이 없다: 이동할 객체가 이동 연산들을 제공하지 않는다. 이 경우 이동 요청은 복사 요청이 된다.
        • 이동이 더 빠르지 않다: 이동할 객체의 이동 연산이 해당 복사 연산보다 빠르지 않다.
        • 이동을 사용할 수 없다: 이동이 일어나려면 이동 연산이 예외를 방출하지 않아야 하는 문맥에서, 해당 연산이 noexcept로 선언되어 있지 않다.
        
        
        이동 의미론이 효율성에 이득이 되지 않는 또 다른 시나리오 하나도 언급할 필요가 있겠다.
        
        
        • 원본 객체가 좌측값이다: 아주 드문 경우(이를테면 항목 25)이지만, 오직 우측값만 이동 연산의 원본이 될 수 있는 경우도 있다.

      • 타입들과 이동 의미론 지원 여부를 미리 알 수 있는 경우에는 그런 가정을 둘 필요가 없다.

        일반적 코드에서는, 이를테면 템플릿을 작성할 때에는 대체로 이동 연산들이 존재하지 않고, 저렴하지 않고, 적용되지 않는다는 가정이 사실이다. 이런 경우 코드에 쓰이는 모든 타입을 알 수 없기 때문이다. 이 점은 "안정적이지 않은 코드" 즉, 코드가 사용하는 타입의 특징들이 비교적 자주 바뀌는 코드에도 적용된다.
        
        그런데 코드가 사용하는 구체적인 타입들을 미리 알 수 있는, 그리고 그 타입들의 특징이 바뀌지 않으리라고 확신할 수 있는 경우에는 이번 항목의 가정들을 둘 필요가 없다.

  30. 완벽 전달이 실패하는 경우들을 잘 알아두라 / 221

      • 완벽 전달은 템플릿 타입 추론이 실패하거나 틀린 타입을 추론했을 때 실패한다.

        완벽 전달 예제 코드 보기
        
        
        

        1. // f라는 함수에 인수들을 전달하는 함수 템플릿을
        2. // 작성한다고 하자. 다음은 그런 함수의 가장
        3. // 기초적인 형태이다.
        4.  
        5. template <typename T>
        6. void fwd(T&& param) // 임의의 인수를 받는다.
        7. {
        8. f(std::forward<T>(param)); // 그 인수를 f에 전달한다.
        9. }
        10.  
        11. // 위의 fwd 템플릿은 임의의 타입의 인수를 받아서
        12. // 그대로 전달한다. 이러한 일반성을 논리적으로
        13. // 연장하면, 전달 함수는 그냥 템플릿 함수가 아니라
        14. // 가변 인수 템플릿(variadic template), 즉 임의의
        15. // 타입과 개수의 인수들을 받는 템플릿이어야 한다는
        16. // 결론에 도달한다.
        17.  
        18. // 다음은 fwd의 가변 인수 버전이다.
        19.  
        20. template <typename... Ts>
        21. void fwd(Ts&&... params) // 임의의 인수들을 받는다.
        22. {
        23. f(std::forward<Ts>(params)...); // 그것들을 f에 전달한다.
        24. }
        25.  
        26. // 이것이 전달 함수의 공통적인 형태이다.
        27.  
        28. // 표준 컨테이너의 emplace류 함수들(항목 42 참고)
        29. // 과 스마트 포인터 팩터리 함수 std::make_shared,
        30. // std::make_unique(항목 21 참고)에서 이런
        31. // 형태를 볼 수 있다.
        32.  
        33. // 위의 함수 템플릿을 사용하면 대부분의 경우
        34. // 다음의 두 식은 같지만,
        35.  
        36. f( 표현식 );
        37. fwd( 표현식 );
        38.  
        39. // 특정한 경우 둘의 결과가 달라지는 경우가 있다.
        40. // 이번 항목에서는 이 둘의 결과가 달라지는,
        41. // 즉 완벽 전달에 실패하는 경우와 우회 방법에
        42. // 대해 알아본다.

        
        
        완벽 전달 예제 코드 접기
        
        
        다음 두 조건중 하나라도 만족되면 완벽 전달이 실패한다(fwd는 자신이 받은 인수들을 함수 f에 완벽 전달하는 함수 템플릿이다).
        • fwd의 매개변수들 중 하나 이상에 대해 컴파일러가 타입을 추론하지 못한다. 이 경우 코드는 컴파일되지 않는다.
        • fwd의 매개변수들 중 하나 이상에 대해 컴파일러가 타입을 잘못 추론한다. "잘못" 추론한 타입들에서 나올 수 있는 결과는 두 가지인데, 하나는 그 타입으로는 fwd의 인스턴스를 컴파일할 수 없는 것이고, 또 하나는 컴파일된다고 해도 fwd의 추론된 타입들을 이용해서 호출한 f가 fwd에 전달된 인수들로 f를 직접 호출했을 때와는 다르게 행동하는 것이다. 예를 들어 f가 오버로딩된 함수 이름이고, "잘못된" 타입 추론 때문에 fwd에서 호출되는 f의 오버로딩된 함수가 f를 직접 호출했을 때 선택되는 오버로딩된 함수와 다른 경우에는 그처럼 서로 다른 행동이 나올 수 있다.

      • 인수가 중괄호 초기치이거나 0 또는 NULL로 표현된 널 포인터, 선언만 된 정수 static const 및 constexpr 데이터 멤버, 템플릿 및 오버로딩된 함수 이름, 비트필드이면 완벽 전달이 실패한다.

        중괄호 초기치
        항목 2에서 설명하듯이, 템플릿 타입 추론은 중괄호 초기치를 추론하지 못한다. 중괄호 초기치의 타입 추론이 실패하므로 중괄호 초기치의 완벽 전달도 실패한다.
        
        반면 auto의 타입 추론은, 템플릿 타입 추론과는 달리 중괄호 초기치를 std::initializer_list로 추론한다(항목 2 참고). 이를 이용하면 중괄호 초기치를 완벽하게 전달할 수 있다.
        
        auto il = { 1, 2, 3 };
        // il의 타입 추론 결과는
        // std::initializer_lis<int>이다.
        
        fwd(il);
        // OK; il이 f로 완벽하게
        // 전달된다.
        
        
        
        널 포인터를 뜻하는 0 또는 NULL
        항목 8에서 설명하듯이, 0이나 NULL은 널 포인터로서 템플릿에 넘겨주려 하면 컴파일러가 그것을 포인터 타입이 아니라 정수 타입(보통은 int)으로 추론하기 때문에 문제가 된다. 결과적으로 0과 NULL은 널 포인터로서 완벽하게 전달되지 못한다.
        
        해결책은 간단하다. 0이나 NULL 대신 nullptr를 사용하면 된다. 자세한 사항은 항목 8을 보기 바란다.
        
        
        
        선언만 된 정수 static const 및 constexpr 데이터 멤버
        일반적인 규칙으로, 정수 static const 데이터 멤버와 정수 static constexpr 데이터 멤버는 클래스 안에서 정의할 필요가 없다. 선언만 하면 된다. 이는 그런 멤버의 값에 대해 컴파일러가 const 전파(const propagation)를 적용해서, 그런 멤버의 값을 위한 메모리를 따로 마련할 필요가 없어지기 때문이다.
        
        하지만, 만일 그런 멤버들의 주소를 취하는 코드(이를테면 그런 멤버를 가리키는 포인터를 만든다면)를 만든다면, 그런 멤버를 위한 저장소가 필요해지며, 그러면 이 코드는 컴파일되긴 하지만 링크에 실패한다.
        
        컴파일러가 산출한 코드에서 참조는 포인터처럼 취급되는 것이 보통이다(즉, 주소를 취한다). 따라서 그런 멤버들을 보편 참조(universal reference)에 묶으려 하면 링크에 실패하는 코드가 만들어질 가능성이 크다. 설령 링크가 된다고 하더라도 표준이 아니므로 이식성이 떨어진다.
        
        따라서, 그러한 멤버들을 완벽하게 전달하려면 그런 멤버들의 정의를 만들어 주면 된다.
        
        예제 코드 보기
        
        
        

        1. class Widget {
        2. public:
        3. static constexpr std::size_t MinVals = 28; // MinVals의 선언
        4. ...
        5. };
        6. ... // MinVals의 정의는 없음
        7.  
        8. std::vector<int> widgetData;
        9. widgetData.reserve(Widget::MinVals); // MinVals의 사용
        10.  
        11. // 위 코드는 아무런 문제가 없다.
        12.  
        13. // 하지만 어떤 코드가 MinVals의 주소를 취한다면
        14. // (이를테면 MinVals를 가리키는 포인터를 만든다면)
        15. // 컴파일은 되지만 링크에 실패한다.
        16.  
        17. // 컴파일러가 산출한 코드에서 참조는 포인터처럼
        18. // 취급되는(즉, 주소를 취하는) 것이 보통이므로,
        19. // MinVals가 보편 참조(universal reference)에 묶이면 링크에 실패한다.
        20.  
        21. // 즉 다음의 코드는 문제가 없지만,
        22.  
        23. void f(std::size_t val);
        24.  
        25. f(Widget::MinVals); // OK; 그냥 f(28)로 처리됨
        26.  
        27. // 다음의 코드는 링크에 실패한다.
        28.  
        29. template <typename T>
        30. void fwd(T&& param)
        31. {
        32. f(std::forward<T>(param));
        33. }
        34.  
        35. fwd(Widget::MinVals); // 오류! 링크에 실패한다.
        36.  
        37. // 이것을 이식성 있게 해결하려면, 구현 파일에
        38. // MinVals의 정의를 만들어 줘야 한다.
        39.  
        40. constexpr std::size_t Widget::MinVals; // Widget의 .cpp 파일에서
        41.  

        
        
        예제 코드 접기
        
        
        
        
        오버로딩된 함수 이름과 템플릿 이름
        오버로딩된 함수 이름이나 함수 템플릿의 이름은 그 자체로 타입을 갖지 않는다. 따라서 완벽하게 전달하려고 하면, 타입 추론에 실패해서 컴파일되지 않는다.
        
        이것을 우회하려면 함수 포인터를 하나 만들고, 명시적으로 오버로딩된 함수나 함수 템플릿 인스턴스를 가리키게 한 뒤 전달하면 된다.
        
        예제 코드 보기
        
        
        

        1. void f(int (*pf)(int)); // pf는 processing function
        2. // (처리 함수)를 뜻한다.
        3.  
        4. // f를 더 간단히 비 포인터 구문으로
        5. // 선언할 수도 있다.
        6.  
        7. void f(int pf(int)); // 위와 동일한 f를 선언한다.
        8.  
        9. // 이제 오버로딩된 processVal 함수가
        10. // 있다고 하자.
        11.  
        12. int processVal(int value);
        13. int processVal(int value, int priority);
        14.  
        15. // 다음처럼 processVal을 f에 넘겨주는
        16. // 것이 가능하다.
        17.  
        18. f(processVal); // OK
        19.  
        20. // f가 요구하는 함수의 타입을 미리 알 수
        21. // 있기 때문이다.
        22.  
        23. // 하지만 다음은 컴파일되지 않는다.
        24.  
        25. template <typename T>
        26. void fwd(T&& param)
        27. {
        28. f(std::forward<T>(param));
        29. }
        30.  
        31. fwd(processVal); // 오류! 어떤 processVal 인지?
        32.  
        33. // 왜냐하면 fwd는 어떤 타입도 받을 수
        34. // 있기 때문에 오버로딩된 두 함수 중에
        35. // 어느 것을 전달해야 할 지 모호하기
        36. // 때문이다.
        37.  
        38. // 마찬가지의 이유로, 다음 코드도
        39. // 컴파일되지 않는다.
        40.  
        41. template <typename T>
        42. T workOnVal(T param) // 값들을 처리하는 템플릿 함수
        43. { ... }
        44.  
        45. fwd(workOnVal); // 오류! workOnVal의
        46. // 어떤 인스턴스인지?
        47.  
        48. // 이를 해결하려면, 전달하고자 하는 오버로딩된 함수나
        49. // 템플릿 인스턴스를 명시적으로 지정해야 한다.
        50.  
        51. using ProcessFuncType = // typedef들을 만든다;
        52. int (*)(int); // 항목 9 참고
        53.  
        54. ProcessFuncType processValPtr = processVal; // processVal에
        55. // 필요한 시그니처를
        56. // 명시한다.
        57.  
        58. fwd(processValPtr); // OK
        59.  
        60. fwd(static_cast<ProcessFuncType>(workOnVal)); // 역시 OK
        61.  
        62. // 물론 이를 위해서는 fwd가 전달하는
        63. // 함수 포인터의 타입을 알고 있어야 한다.
        64.  
        65. // 다행히, 완벽 전달 함수의 문서화에
        66. // 그 타입에 대한 정보가 나와 있으리라고
        67. // 가정하는 것이 비합리적인 생각은 아니다.

        
        
        예제 코드 접기
        
        
        
        
        비트필드
        메모리의 주소는 바이트 단위로 할당된다. 따라서 임의의 바이트를 가리키는 포인터를 만들 수 있지만, 임의의 비트를 가리키는 포인터는 만들 수 없다. 위에서도 언급했지만, 컴파일러가 산출한 코드에서 참조는 포인터처럼 취급되는 것이 보통이다. 이 때문에, 비트 필드는 보편 참조(universal reference)에 묶일 수가 없어서 완벽 전달에 실패한다.
        
        비트필드를 매개변수에 전달하는 방법은 단 두 가지로, 하나는 값으로 전달하는 것이고, 또 하나는, 흥미롭게도 const에 대한 참조로 전달하는 것이다.
        
        값 전달 매개변수의 경우 호출된 함수가 비트필드 값의 복사본을 받는다. 그리고 const 참조 매개변수의 경우, 표준에 따르면 그 참조는 실제로 어떤 표준 정수 타입(이를테면 int)의 객체에 저장된 비트필드 값의 복사본에 묶여야 한다. 즉, 그 const 참조는 비트필드 자체가 아닌, 비트필드 값이 복사된 '보통'객체에 묶인다.
        
        따라서 비트필드를 완벽 전달 함수에 넘겨주려면, 비트필드 값의 복사본을 직접 생성해서 그 복사본을 전달하면 된다.
        
        예제 코드 보기
        
        
        

        1. // 다음은 IPv4 헤더를 나타내는 구조체이다.
        2.  
        3. struct IPv4Header {
        4. std::uint32_t version:4,
        5. IHL:4,
        6. DSCP:6,
        7. ECN:2,
        8. totalLength:16;
        9. ...
        10. };
        11.  
        12. void f(std::size_t sz); // 호출할 함수
        13.  
        14. IPv4Header h;
        15. ...
        16. f(h.totalLength); // OK
        17.  
        18. // 그러나 다음은 컴파일되지 않는다.
        19.  
        20. template <typename T>
        21. void fwd(T&& param)
        22. {
        23. f(std::forward<T>(param));
        24. }
        25.  
        26. fwd(h.totalLength); // 오류!
        27.  
        28. // 이를 해결하려면, 비트필드 값의 복사본을
        29. // 직접 생성해서 그 복사본을 전달해야 한다.
        30.  
        31. // 비트필드 값을 복사한다; 이런 초기화 구문에 관해서는 항목 6을 보라
        32. auto length = static_cast<std::uint16_t>(h.totalLength);
        33.  
        34. fwd(length); // 복사본을 전달한다.
        35.  

        
        
        예제 코드 접기
        
        
        

• Chapter 6   람다 표현식

  람다와 관련된 용어에 익숙하지 않은 분들을 위해 간단히 정리하자면:
  
  
  • 람다 표현식(lambda expression)은 이름 그대로 하나의 표현식으로, 소스 코드의 일부이다.
    
    람다 표현식 예제 코드 보기
    
    
    

    1. std::find_if(container.begin(), container.end(),
    2. [](int val) { return 0 < val && val < 10; });
    3.  
    4. // 위에서 강조된 부분이 람다 표현식이다.

    
    
    람다 표현식 예제 코드 접기
    
    
    
  • 클로저(closure)는 람다에 의해 만들어진 실행시점 객체이다. 갈무리 모드(capture mode)에 따라, 클로저가 갈무리된 데이터의 복사본을 가질 수도 있고 그 데이터에 대한 참조를 가질 수도 있다. 위 예제 코드의 std::find_if 호출에서 클로저는 실행시점에서 std::find_if의 셋째 인수로 전달되는 객체이다.
  • 클로저 클래스는 클로저를 만드는 데 쓰인 클래스를 말한다. 각각의 람다에 대해 컴파일러는 고유한 클로저 클래스를 만들어 낸다. 람다 안의 문장들은 해당 클로저 클래스의 멤버 함수들 안의 실행 가능한 명령들이 된다.
  
  
  람다는 함수의 인수로만 쓰이는 클로저를 생성하는 데 자주 쓰인다. 그러나 일반적으로 클로저를 복사하는 것도 가능하므로, 하나의 람다에 대응되는 하나의 클로저 타입으로부터 여러 개의 클로저를 만들어 내는 것도 일반적으로 가능하다.
  
  예제 코드 보기
  
  
  

  1. {
  3. int x; // x는 지역 변수
  4. ...
  6. auto c1 = // c1은 람다에 의해
  7. [x](int y) { return x * y > 55; }; // 만들어진 클로저의
  8. // 복사본
  10. auto c2 = c1; // c2는 c1의 복사본
  12. auto c3 = c2; // c3는 c2의 복사본
  14. ...
  16. }
  17.  
  18. // 이 코드에서 c1과 c2, c3은 모두 람다가
  19. // 산출한 클로저의 복사본이다.

  
  
  예제 코드 접기
  
  
  

  31. 기본 갈무리 모드를 피하라 / 233

      • 기본 참조 갈무리는 참조가 대상을 잃을 위험이 있다.

        기본 참조 갈무리를 사용한 람다에 의해 생성된 클로저의 수명이, 갈무리된 지역 변수나 매개변수의 수명보다 오래 지속되면, 클로저 안의 참조는 대상을 잃는다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 예를 들어 int 하나를 받아서 그 값이 필터를
        3. // 만족하는지를 뜻하는 bool 하나를 돌려주는
        4. // 필터링 함수들을 담는 컨테이너가 있다고 하자.
        5.  
        6. using FilterContainer = // using에 관해서는 항목 9를,
        7. std::vector<std::function<bool(int)> >; // std::function에 관해서는
        8. // 항목 5를 보라
        9.  
        10. FilterContainer filters; // 필터링 함수들
        11.  
        12. // 다음은 이 컨테이너에 5의 배수를 선별하는
        13. // 필터 함수를 추가하는 예이다.
        14.  
        15. filters.emplace_back( // emplace_back에
        16. [](int value) { return value % 5 == 0; } // 관해서는 항목 42를
        17. ); // 보라
        18.  
        19. // 그런데 제수(divisor; 나누는 수)를
        20. // 실행시점에서 계산해야 할 수도 있다.
        21.  
        22. // 다음은 실행시점에서 계산한 제수를 사용하는
        23. // 필터를 컨테이너에 추가하는 예이다.
        24.  
        25. void addDivisorFilter(void)
        26. {
        27. auto calc1 = computeSomeValue1();
        28. auto calc2 = computeSomeValue2();
        30. auto divisor = computeDivisor(calc1, calc2);
        32. filters.emplace_back( // 위험!
        33. [&](int value) { return value % divisor == 0; } // divisor에
        34. ); // 대한 참조가
        35. } // 대상을 잃을
        36. // 수 있음!
        37.  
        38. // 이 코드는 문제의 소지가 있다. 람다는 지역 변수
        39. // divisor를 참조하는데, 그 변수는 addDivisorFilter가
        40. // 반환되면 더 이상 존재하지 않게 된다.
        41.  
        42. // addDivisorFilter는 filters.emplace_back이
        43. // 반환된 직후에 반환되므로, filters에 추가되는
        44. // 필터 함수는 사실상 이미 "사망 상태로 도착"
        45. // 하는 셈이다.
        46.  
        47. // 그러한 필터는 거의 생성 직후부터
        48. // 미정의 행동을 유발한다.
        49.  
        50.  
        51. //-----------------------------------------------------------------------------
        52. // divisor의 참조 갈무리를 명시적으로 지정해도
        53. // 여전히 같은 문제가 발생한다.
        54.  
        55. filters.emplace_back(
        56. [&divisor](int value) // 위험! 이번에도
        57. { return value % divisor == 0; } // divisor 참조는
        58. ); // 대상을 잃는다!
        59.  
        60. // 그러나, 이러한 명시적 갈무리에는 이 람다
        61. // 표현식의 유효성이 divisor의 수명에 의존한다는
        62. // 점이 명확히 나타난다는 장점이 있다.
        63.  
        64. // 또한, 프로그래머가 "divisor"라는 이름을
        65. // 명시적으로 타자하다 보면 divisor가 적어도
        66. // 람다의 클로저만큼은 살아 있어야 한다는
        67. // 점을 깨닫게 될 가능성이 크다.
        68.  
        69.  
        70. //-----------------------------------------------------------------------------
        71. // 클로저가 즉시 사용되며 복사되지는 않을 것을
        72. // 알고 있다면, 클로저가 가진 참조가 해당 람다가
        73. // 생성된 환경 안의 지역 변수나 매개변수보다
        74. // 오래 살아남을 위험은 없다.
        75.  
        76. // 이런 경우에는 기본 참조 갈무리 모드를 피할
        77. // 필요가 없지 않을까?
        78.  
        79. // 다음을 보자.
        80.  
        81. template <typename C>
        82. void workWithContainer(const C& container)
        83. {
        84. auto calc1 = computeSomeValue1(); // 이전과 동일
        85. auto calc2 = computeSomeValue2(); // 이전과 동일
        87. auto divisor = computeDivisor(calc1, calc2); // 이전과 동일
        89. using ContElemT = typename C::value_type; // 컨테이너에
        90. // 담긴 요소들의
        91. // 타입
        93. using std::begin; // 일반성을 위해;
        94. using std::end; // 항목 13을
        95. // 보라
        97. if (std::all_of( // 컨테이너의 모든
        98. begin(container), end(container), // 값이 divisor의
        99. [&](const ContElemT& value) // 배수인가?
        100. { return value % divisor == 0; })
        101. ) {
        102. ... // 그런 경우
        103. } else {
        104. ... // 적어도 하나는
        105. } // 아닌 경우
        106. }
        107.  
        108. // 이 코드가 안전한 것은 사실이나,
        109. // 그 안전성은 깨지기 쉽다.
        110.  
        111. // 이 람다가 다른 문맥에서도 유용할 것으로 생각한
        112. // 어떤 프로그래머가 람다를 복사해서 그 문맥에
        113. // 붙여넣을 수도 있다.
        114.  
        115. // 그런데 그 문맥에서 divisor가 클로저보다
        116. // 먼저 소멸한다면, 앞에서 살펴본 문제가
        117. // 그대로 재현된다.
        118.  
        119. // 람다의 갈무리 절에 divisor의 수명을
        120. // 분석해 봐야 한다는 점을 알려주는 힌트가
        121. // 전혀 없으므로, 프로그래머로서는 그런
        122. // 문제를 인식하기가 쉽지 않다.
        123.  
        124.  
        125. //-----------------------------------------------------------------------------
        126. // 한편, C++14에서는 람다의 매개변수를 지정할 때
        127. // auto를 사용할 수 있으므로 앞에 나온 코드를
        128. // 좀 더 간단하게 표현하는 것이 가능하다.
        129.  
        130. // typedef ContElemT를 생략할 수 있으며,
        131. // if 조건을 다음과 같이 고칠 수 있다.
        132.  
        133. if (std::all_of(begin(container), end(container),
        134. [&](const auto& value) // C++14
        135. { return value % divisor == 0; }))
        136.  

        
        
        예제 코드 접기
        
        
        

      • 기본 값 갈무리는 포인터(특히 this)가 대상을 잃을 수 있으며, 람다가 자기 완결적이라는 오해를 부를 수 있다.

        기본 값 갈무리를 사용하면 문제가 없을 것 같지만, 포인터를 갈무리한 경우 기본 참조 갈무리와 동일한 문제가 발생한다. 특히 this포인터나 정적 저장소 수명 기간(static storage duration)을 가진 객체가 관여하면, 오해를 부르기 쉬워 오류의 원인이 될 수 있다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 좀 전의 예제에서 divisor와 관련된 문제를
        3. // 해결하는 한 가지 방법은 기본 값 갈무리 모드를
        4. // 사용하는 것이다.
        5.  
        6. // filters에 람다를 다음과 같이 추가하면 된다.
        7.  
        8. using FilterContainer =
        9. std::vector<std::function<bool(int)> >;
        10.  
        11. FilterContainer filters;
        12.  
        13. filters.emplace_back( // 이제는
        14. [=](int value) { return value % divisor == 0; } // divisor가
        15. ); // 대상을 잃지
        16. // 않음
        17.  
        18. // 이 예제에서는 이것으로 충분하다.
        19.  
        20. // 하지만 기대와는 달리, 일반적으로는 기본 값 갈무리가
        21. // 대상을 잃은 문제에 대한 특효약이 아니다.
        22.  
        23. // 이런 문제가 있기 때문이다: 포인터를 값으로
        24. // 갈무리하면 그 포인터는 람다에 의해 생성된
        25. // 클로저 안으로 복사되는데, 람다 바깥의
        26. // 어떤 코드가 그 포인터를 delete로 삭제하면
        27. // 포인터 복사본은 지칭 대상을 잃게 된다.
        28.  
        29. // 제4장을 감명깊게 읽은 후, 스마트 포인터만을
        30. // 사용한다고 하더라도 사실은 생 포인터를 사용하는
        31. // 경우가 있으며, 여전히 다른 어떤 코드가 여러분도
        32. // 모르게 그 생 포인터를 delete로 삭제할 수
        33. // 있다는 점에는 변함이 없다.
        34.  
        35. // 현대적인 C++ 프로그래밍 스타일에서는
        36. // 그러한 생 포인터의 존재가 소스코드에
        37. // 잘 드러나지 않는 경우가 많다.
        38.  
        39. // 다음을 보자.
        40.  
        41. class Widget {
        42. public:
        43. ... // 생성자 등등
        44. void addFilter(void) const; // 필터를 filters에 추가
        46. private:
        47. int divisor; // Widget의 필터에 쓰인다.
        48. };
        49.  
        50. // 다음은 Widget::addFilter의 구현 예이다.
        51.  
        52. void Widget::addFilter(void) const
        53. {
        54. filters.emplace_back(
        55. [=](int value) { return value % divisor == 0; }
        56. );
        57. }
        58.  
        59. // 언뜻 보기에 이 코드에는 아무런 문제가 없어 보인다.
        60.  
        61. // 람다는 divisor에 의존하는데, 값 갈무리 모드에서는
        62. // divisor의 값이 람다가 생성하는 클로저 안으로
        63. // 복사되므로 안전하지 않을까?
        64.  
        65. // 이 생각은 완전히, 철저히, 치명적으로 틀렸다.
        66.  
        67. // 갈무리는 오직 람다가 생성된 범위 안에서 보이는,
        68. // static이 아닌 지역 변수(매개변수 포함)에만
        69. // 적용된다.
        70.  
        71. // Widget::addFilter의 본문에서 divisor는
        72. // 지역 변수가 아니라 클래스의 한 데이터 멤버이므로
        73. // 갈무리될 수 없다.
        74.  
        75. // 그렇지만, 만일 기본 갈무리 모드를 뜻하는 =를
        76. // 제거하면 코드는 컴파일되지 않는다.
        77.  
        78. void Widget::addFilter(void) const
        79. {
        80. filters.emplace_back( // 오류!
        81. [](int value) { return value % divisor == 0; } // divisor를
        82. ); // 사용할 수
        83. } // 없음
        84.  
        85. // 더 나아가서, divisor를 명시적으로 갈무리하려는
        86. // (값이든 참조이든) 갈무리 절은 컴파일되지 않는다.
        87.  
        88. // divisor가 지역 변수도 아니고 매개변수도
        89. // 아니기 때문이다.
        90.  
        91. void Widget::addFilter(void) const
        92. {
        93. filters.emplace_back(
        94. [divisor](int value) // 오류! 갈무리할 지역
        95. { return value % divisor == 0; } // divisor가 없음
        96. );
        97. }
        98.  
        99. // 왜 이러한 현상이 생기는 것일까?
        100.  
        101. // 그 이유는 암묵적으로 어떤 생 포인터가
        102. // 쓰이기 때문이다. 바로 this이다.
        103.  
        104. // 다음처럼 기본 값 갈무리를 사용하는
        105. // Widget::addFilter 버전에서,
        106.  
        107. void Widget::addFilter(void) const
        108. {
        109. filters.emplace_back(
        110. [=](int value) { return value % divisor == 0; }
        111. );
        112. }
        113.  
        114. // 람다가 클로저 안에 갈무리하는 것은 divisor가
        115. // 아니라 Widget의 this 포인터이다.
        116.  
        117. // 즉, 컴파일러는 방금의 코드를 다음처럼 취급한다.
        118.  
        119. void Widget::addFilter(void) const
        120. {
        121. auto currentObjectPtr = this;
        123. filters.emplace_back(
        124. [currentObjectPtr](int value)
        125. { return value % currentObjectPtr->divisor == 0; }
        126. );
        127. }
        128.  
        129. // 자 이제, 쥐도새도 모르게 this 포인터가 소멸되어
        130. // 미정의 동작을 유발하는 예제를 보자.
        131.  
        132. using FilterContainer = // 이전과 동일
        133. std::vector<std::function<bool(int)> >;
        134.  
        135. FilterContainer filters; // 이전과 동일
        136.  
        137. void doSomeWork(void)
        138. {
        139. auto pw = // Widget을 생성한다;
        140. std::make_unique<Widget>(); // std::make_unique에
        141. // 관해서는 항목 21을 보라
        143. pw->addFilter(); // Widget::divisor를
        144. // 사용하는 필터를 추가한다.
        146. ...
        147. } // 여기서 Widget이 파괴된다;
        148. // 이제 filters에는 대상을
        149. // 잃은 포인터(this)가 존재한다.
        150.  
        151.  
        152. //-----------------------------------------------------------------------------
        153. // 지금 이 문제는 갈무리하려는 데이터 멤버의
        154. // 지역 복사본을 만들어서 그 복사본을
        155. // 갈무리하면 해결된다.
        156.  
        157. void Widget::addFilter(void) const
        158. {
        159. auto divisorCopy = divisor; // 데이터 멤버를 복사한다.
        161. filters.emplace_back(
        162. [divisorCopy](int value) // 복사본을 갈무리한다.
        163. { return value % divisorCopy == 0; } // 복사본을 사용한다.
        164. );
        165. }
        166.  
        167. // 사실 이 접근방식은 기본 값
        168. // 갈무리 모드에도 통한다.
        169.  
        170. void Widget::addFilter(void) const
        171. {
        172. auto divisorCopy = divisor; // 데이터 멤버를 복사한다.
        174. filters.emplace_back(
        175. [=](int value) // 복사본을 갈무리한다.
        176. { return value % divisorCopy == 0; } // 복사본을 사용한다.
        177. );
        178. }
        179.  
        180. // 그러나 위험을 자초할 필요는 없다.
        181.  
        182. // 애초에 divisor를 갈무리하려 했는데 사실은
        183. // this가 갈무리되게 한 장본인이 바로 기본
        184. // 갈무리 모드이다.
        185.  
        186.  
        187. //-----------------------------------------------------------------------------
        188. // C++14에는 데이터 멤버를 갈무리하는
        189. // 더 나은 방법이 있다.
        190.  
        191. // 바로 일반화된 람다 갈무리(항목 32 참고)
        192. // 를 사용하는 것이다.
        193.  
        194. void Widget::addFilter(void) const
        195. {
        196. filters.emplace_back( // C++14
        197. [divisor = divisor](int value) // divisor를 클로저에 복사한다.
        198. { return value % divisor == 0; } // 복사본을 사용한다.
        199. );
        200. }
        201.  
        202. // 그런데 일반화된 람다 갈무리에는 기본 갈무리
        203. // 모드라는 것이 없으므로 C++14에서도 기본
        204. // 갈무리 모드를 피하라는 조언은 유효하다.
        205.  
        206.  
        207. //-----------------------------------------------------------------------------
        208. // 값에 의한 기본 갈무리 모드의 또 다른
        209. // 단점은, 해당 클로저가 자기 완결적이고
        210. // 클로저 바깥에서 일어나는 데이터의 변화로부터
        211. // 격리되어 있다는 오해를 부를 수 있다는
        212. // 점이다.
        213.  
        214. // 왜냐하면 람다가 지역 변수와 매개변수
        215. // (갈무리가 가능한)뿐만 아니라 정적
        216. // 저장소 수명 기간(static storage
        217. // duration)을 가진 객체에도 의존할
        218. // 수 있기 때문이다.
        219.  
        220. // 정적 저장소 수명 기간을 가진 객체를
        221. // 람다 안에서 사용할 수는 있지만, 갈무리할
        222. // 수는 없다.
        223.  
        224. // 그러나 기본 값 갈무리 모드의 표기는 마치
        225. // 그런 객체도 모두 갈무리된다는 느낌을 준다.
        226.  
        227. // 다음 예를 보자.
        228.  
        229. void addDivisorFilter(void)
        230. {
        231. static auto calc1 = computeSomeValue1(); // 이제는 정적 변수
        232. static auto calc2 = computeSomeValue2(); // 이제는 정적 변수
        234. static auto divisor = // 이제는 정적 변수
        235. computeDivisor(calc1, calc2);
        237. filters.emplace_back(
        238. [=](int value) // 아무 것도 갈무리하지 않음!
        239. { return value % divisor == 0; } // 위의 정적 변수를 지칭한다.
        240. );
        242. ++divisor; // divisor를 수정한다.
        243. }
        244.  
        245. // 이 람다는 아무것도 갈무리하지 않는다.
        246.  
        247. // 오히려 이 람다의 코드는 static
        248. // 변수 divisor를 지칭한다.
        249.  
        250. // addDivisorFilter의 각 호출의 끝에서
        251. // divisor가 증가하며, 따라서 이 함수를 통해서
        252. // filters에 추가된 람다는 이전과는 다른
        253. // 행동(divisor의 새 값에 상응하는)을
        254. // 보이게 된다.
        255.  
        256. // 현실적으로 이 람다는 divisor를 참조로
        257. // 갈무리한 것과 같으며, 이는 기본 값 갈무리
        258. // 모드가 뜻하는 바와 직접적으로 모순이 된다.
        259.  
        260. // 애초에 기본 값 갈무리 모드를 사용하지 않는다면
        261. // 이처럼 오해의 여지가 큰 코드가 만들어질 위험도
        262. // 사라진다.

        
        
        예제 코드 접기
        
        
        

  32. 객체를 클로저 안으로 이동하려면 초기화 갈무리를 사용하라 / 240

      • 객체를 클로저 안으로 이동할 때에는 C++14의 초기화 갈무리를 사용하라.

        초기화 갈무리로는 다음과 같은 것들을 지정할 수 있다.
        
        
        1. 람다로부터 생성되는 클로저 클래스에 속한 데이터 멤버의 이름
        2. 그 데이터 멤버를 초기화하는 표현식
        
        
        다음은 초기화 갈무리를 이용해서 std::unique_ptr를 클로저 안으로 이동하는 예이다.
        
        초기화 갈무리 예제 코드 보기
        
        
        

        1. class Widget { // 어떤 유용한 타입
        2. public:
        3. ...
        5. bool isValidated(void) const;
        6. bool isProcessed(void) const;
        7. bool isArchived(void) const;
        9. private:
        10. ...
        11. };
        12.  
        13. auto pw = std::make_unique<Widget>(); // Widget을 생성한다;
        14. // std::make_unique에
        15. // 관해서는 항목 21을 보라
        16.  
        17. ... // 여기서 *pw를 조작한다.
        18.  
        19. auto func = [pw = std::move(pw)] // 클로저의 데이터 멤버를
        20. { return pw->isValidated() // std::move(pw)로
        21. && pw->isArchived(); }; // 초기화한다.
        22.  
        23. // []안쪽 부분이 초기화 갈무리이다.
        24.  
        25. // "="의 좌변은 클로저 클래스 안의 데이터 멤버
        26. // (클로저에서 사용할)의 이름이고, 우변은 그것을
        27. // 초기화하는 표현식이다.
        28.  
        29. // 흥미로운 점은, "="의 좌변과 우변의 범위가
        30. // 다르다는 것이다.
        31.  
        32. // 좌변의 범위는 해당 클로저 클래스의 범위이고,
        33. // 우변의 범위는 람다가 정의되는 지점의 범위와
        34. // 동일하다.
        35.  
        36. // 만일 pw를 람다 안으로 이동하기 전에 조작할
        37. // 필요가 없는 경우라면, 클로저 클래스의 데이터
        38. // 멤버를 std::make_unique로 직접 초기화하면 된다.
        39.  
        40. auto func = [pw = std::make_unique<Widget>()] // 클로저 안의 데이터
        41. { return pw->isValidated() // 멤버를 make_
        42. && pw->isArchived(); }; // unique 호출
        43. // 결과로 초기화
        44.  
        45. // C++11에서는 어떤 표현식의 결과를 갈무리하는 것이
        46. // 불가능했지만, 이 예에서 보듯이 C++14에서는 가능하다.
        47.  
        48. // 이 점을 생각하면, C++14의 '갈무리' 개념이
        49. // C++11에 비해 훨씬 더 일반화되었음이 명확하다.
        50.  
        51. // 그래서 초기화 갈무리를 일반화된 람다 갈무리
        52. // (generalized lambda capture)라고 부르기도 한다.

        
        
        초기화 갈무리 예제 코드 접기
        
        
        

      • C++11에서는 직접 작성한 클래스나 std::bind로 초기화 갈무리를 흉내 낼 수 있다.

        C++11에서는 객체를 클로저 안으로 이동할 방법이 없다. 이런 상황에서는, 직접 작성한 클래스나 std::bind로 초기화 갈무리를 흉내내는 방법을 써야 한다.
        
        바인드 객체를 이용한 방법의 요점은 다음과 같다.
        
        
        • 객체를 C++11 클로저 안으로 이동 생성하는 것은 불가능하나, 객체를 C++11 바인드 객체 안으로 이동 생성하는 것은 가능하다.
        • C++11에서 이동 갈무리를 흉내 내는 방법은, 객체를 바인드 객체 안으로 이동 생성하고, 이동 생성된 객체를 람다에 참조로 전달하는 것이다.
        • 바인드 객체의 수명이 클로저의 수명과 같으므로, 바인드 객체 안의 객체들을 마치 클로저 안에 있는 것처럼 취급하는 것이 가능하다.
        
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // C++11에서 객체를 클로저 안으로 이동하는 방법
        3. // 중의 하나는 직접 작성한 클래스를 쓰는 것이다.
        4.  
        5. // 예를 들어 다음은 방금 본 C++14 예제와
        6. // 같은 일을 수행하는 C++11 코드이다.
        7.  
        8. class IsValAndArch { // 유효성 및 보관 여부
        9. public: // (validated and
        10. using DataType = std::unique_ptr<Widget>; // archived)를 판정
        12. explicit IsValAndArch(DataType&& prt) // std::move는
        13. : pw(std::move(ptr)) {} // 항목 25에서 설명한다.
        15. bool operator()(void) const
        16. { return pw->isValidated() && pw->isArchived(); }
        18. private:
        19. DataType pw;
        20. };
        21.  
        22. auto func = IsValAndArch(std::make_unique<Widget>());
        23.  
        24. // C++11에는 std::make_unique가 없다.
        25. // 실제로 이런 형태의 코드가 필요하다면
        26. // make_unique를 직접 작성하면 된다
        27. // (항목 21 참고).
        28.  
        29.  
        30. //-----------------------------------------------------------------------------
        31. // 그러나 람다가 워낙 편하므로, 람다를
        32. // 고집하는 프로그래머가 많을 것이다.
        33.  
        34. // 다행히 C++11에서 이동 갈무리를
        35. // 흉내 내는 방법이 있다.
        36.  
        37. // 1. 갈무리할 객체를 std::bind가 산출하는 함수 객체로 이동하고,
        38. // 2. 그 '갈무리된' 객체에 대한 참조를 람다에 넘겨준다.
        39.  
        40. // 지역 std::vector를 생성해서 거기에 적절한
        41. // 값들을 추가한 후 클로저 안으로 이동한다고 하자.
        42.  
        43. // C++14에서는 쉽다.
        44.  
        45. std::vector<double> data; // 클로저 안으로 이동할
        46. // 객체
        47.  
        48. ... // data에 데이터를 채운다.
        49.  
        50. auto func = [data = std::move(data)] // C++14의 초기화 갈무리
        51. { /* 여기서 data를 사용 */ };
        52.  
        53. // 다음은 이에 상응하는 C++11 코드이다.
        54.  
        55. std::vector<double> data; // 이전과 동일
        56.  
        57. ... // 이전과 동일
        58.  
        59. auto func =
        60. std::bind( // C++11에서 초기화
        61. [](const std::vector<double>& data) // 갈무리를 흉내 내는
        62. { /* 여기서 data를 사용 */ }, // 방법
        63. std::move(data)
        64. );
        65.  
        66. // 바인드 객체는 std::bind에 전달된
        67. // 모든 인수의 복사본을 포함한다.
        68.  
        69. // 바인드 객체가 '호출'되면, 바인드 객체에
        70. // 저장된 인수들이 애초에 std::bind 호출 시
        71. // 첫 인수로 지정한 호출 가능 객체에 전달된다.
        72.  
        73. // 이 예에서는, func(바인드 객체)가 호출되면
        74. // func에 저장된 data의 복사본(이동 생성된)이
        75. // std::bind 호출 시 지정한 람다에 하나의
        76. // 인수로서 전달된다.
        77.  
        78.  
        79. //-----------------------------------------------------------------------------
        80. // 기본적으로, 람다로부터 만들어진 클로저 클래스의
        81. // operator() 멤버 함수는 const이다.
        82.  
        83. // 이 때문에 람다 본문 안에서 클로저의 모든 데이터
        84. // 멤버는 const가 된다.
        85.  
        86. // 그러나 바인드 객체 안의 이동 생성된 data
        87. // 복사본은 const가 아니다.
        88.  
        89. // 람다 안에서 data 복사본이 수정되지 않게
        90. // 하려면 람다의 매개변수를 const에 대한
        91. // 참조로 선언해야 한다.
        92.  
        93. // 만일 람다를 mutable로 선언하면, 해당 클로저
        94. // 클래스의 operator()는 const로 선언되지
        95. // 않을 것이므로 람다의 매개변수 선언에서 const를
        96. // 제거해야 마땅하다.
        97.  
        98. auto func =
        99. std::bind( // C++11에서 mutable
        100. [](std::vector<double>& data) mutable // 람다의 초기화 갈무리를
        101. { /* 여기서 data를 사용 */ }, // 흉내 내는 방법
        102. std::move(data)
        103. );
        104.  
        105.  
        106. //-----------------------------------------------------------------------------
        107. // std::bind를 이용해서 이동 갈무리를 흉내 내는
        108. // 또 다른 예제를 살펴보자.
        109.  
        110. // 다음은 앞에서 본, C++14의 클로저 안에서
        111. // std::unique_ptr를 생성하는 예이다.
        112.  
        113. auto func = [pw = std::make_unique<Widget>()] // 이전과 동일,
        114. { return pw->isValidated() // 클로저 안에서
        115. && pw->isArchived(); }; // pw를 생성한다.
        116.  
        117. // 그리고 다음은 이를 C++11에서 흉내 낸 것이다.
        118.  
        119. auto func = std::bind(
        120. [](const std::unique_ptr<Widget>& pw)
        121. { return pw->isValidated()
        122. && pw->isArchived(); },
        123. std::make_unique<Widget>()
        124. );
        125.  

        
        
        예제 코드 접기
        
        
        사실 C++11 람다의 한계를 우회하기 위해 std::bind를 사용하는 것은 다소 모순적이다. 항목 34에서는 std::bind보다는 람다를 선호하라고 조언하기 때문이다.
        
        그러나, 그 항목에서는 C++11에서 std::bind가 유용한 경우가 존재한다는 점도 지적하며, 지금이 바로 그런 경우 중 하나이다 (C++14에서는 초기화 갈무리와 auto 매개변수 덕분에 그런 경우들이 없다).

  33. std::forward를 통해서 전달할 auto&& 매개변수에는 decltype을 사용하라 / 246

      • std::forward를 통해서 전달할 auto&& 매개변수에는 decltype을 사용하라.

        항목 28에서는 std::forward 호출 시 전달할 인수가 좌측값임을 나타내기 위해서는 좌측값 참조 타입 인수를 사용하고 우측값임을 나타내기 위해서는 비참조 타입 인수를 사용하는 것이 관례라는 점을 설명한다.
        
        하지만, decltype은 좌측값 인수에 대해서는 좌측값 참조 타입을, 우측값 인수에 대해서는 우측값 참조 타입을 돌려준다. 이때, 마찬가지로 항목 28에서 설명한 참조 축약(collapse)을 적용하면, 비참조 타입 인수를 사용한 것과 같은 결과를 얻을 수 있다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 람다의 매개변수 명세에 auto를 사용하면,
        3. // 컴파일러는 람다의 클로저 클래스의 operator()
        4. // 를 템플릿 함수로 만든다.
        5.  
        6. // 다음을 보자.
        7.  
        8. auto f = [](auto x){ return normalize(x); };
        9.  
        10. // 이 람다가 산출하는 클로저 클래스의
        11. // 함수 호출 연산자는 다음과 같은 모습이다.
        12.  
        13. class 컴파일러가_만든_어떤_클래스_이름 {
        14. public:
        15. template <typename T> // auto 반환 타입은
        16. auto operator()(T x) const // 항목 3을 보라
        17. { return normalize(x); }
        19. ... // 클로저 클래스의
        20. }; // 나머지 기능들
        21.  
        22. // 만일 normalize가 좌측값과 우측값을
        23. // 다르게 처리한다면, 람다가 x를 normalize에
        24. // 완벽하게 전달해야 한다.
        25.  
        26. auto f = [](auto&& x)
        27. { return normalize(std::forward<???>(x)); };
        28.  
        29. // 과연 ???에 어떤 타입 인수를 넘겨야 할까?
        30.  
        31.  
        32. //-----------------------------------------------------------------------------
        33. // 이런 경우에 항목 3에서 설명한 decltype을
        34. // 사용할 수 있다.
        35.  
        36. // 만일 좌측값이 전달되었다면 decltype(x)는
        37. // 좌측값 참조에 해당하는 타입을 산출하고,
        38. // 우측값이 전달되었다면 decltype(x)는
        39. // 우측값 참조 타입을 산출한다.
        40.  
        41. // 항목 28에서는 std::forward 호출 시 인수가
        42. // 좌측값임을 나타내기 위해서는 좌측값 참조 타입 인수를
        43. // 사용하고 우측값임을 나타내기 위해서는 비참조 타입
        44. // 인수를 사용하는 것이 관례라는 점도 설명한다.
        45.  
        46. // decltype을 사용했을 때, 좌측값이 전달된
        47. // 경우라면 문제가 없다.
        48.  
        49. // 하지만 우측값이 전달된 경우라면 비참조 타입이
        50. // 아니라 우측값 참조 타입 인수를 std::forward에
        51. // 전달하게 된다.
        52.  
        53. // 항목 28에 나온 std::forward의 C++14 구현을
        54. // 다시 살펴보자.
        55.  
        56. template <typename T> // 이름공간
        57. T&& forward(remove_reference_t<T>& param) // std 안에서
        58. {
        59. return static_cast<T&&>(param);
        60. }
        61.  
        62. // 일반적으로, 클라이언트가 Widget 타입의 우측값을
        63. // 완벽하게 전달할 때에는 그 Widget 타입으로
        64. // std::forward를 인스턴스화 할 것이다.
        65.  
        66. Widget&& forward(Widget& param) // T가 Widget일 때의
        67. { // std::forward의
        68. return static_cast<Widget&&>(param); // 인스턴스화 결과
        69. }
        70.  
        71. // 그런데, 클라이언트 코드가 T를 비참조 타입으로
        72. // 지정하지 않고 우측값 참조 타입으로 지정하면
        73. // 어떻게 될지도 생각해 보자.
        74.  
        75. Widget&& && forward(Widget& param) // T가 Widget&&일 때의
        76. { // std::forward의
        77. return static_cast<Widget&& &&>(param); // 인스턴스화 결과
        78. } // (참조 축약(collapse)은 아직
        79. // 적용되지 않았음)
        80.  
        81. // 여기에 우측값 참조에 대한 우측값 참조는 단일한
        82. // 우측값 참조가 된다는 참조 축약(collapse) 규칙을 적용하면,
        83. // 다음과 같은 모습이 될 것이다.
        84.  
        85. Widget&& forward(Widget& param) // T가 Widget&&일 때의
        86. { // std::forward의
        87. return static_cast<Widget&&>(param); // 인스턴스화 결과
        88. } // (참조 축약(collapse)이 적용된
        89. // 이후)
        90.  
        91. // 이 인스턴스는, T를 비참조 타입으로 지정했을 때와
        92. // 동일함을 알 수 있다.
        93.  
        94.  
        95. //-----------------------------------------------------------------------------
        96. // 결국 auto&& 매개변수를 std::forward에
        97. // 전달할때는 decltype을 쓰면 된다.
        98.  
        99. auto f = [](auto&& x)
        100. {
        101. return normalize(std::forward<decltype(x)>(x));
        102. };
        103.  
        104. // 게다가, 다음처럼 마침표 세 개를 두 번 추가하면
        105. // 매개변수 하나가 아니라 임의의 개수의 매개변수들을
        106. // 받아서 완벽하게 전달하는 람다가 된다.
        107.  
        108. // 이는 C++14의 람다가 가변 인수를 지원하는 덕분이다.
        109.  
        110. auto f = [](auto&&... xs)
        111. {
        112. return normalize(std::forward<decltype(xs)>(xs)...);
        113. };
        114.  

        
        
        예제 코드 접기
        
        
        

  34. std::bind보다 람다를 선호하라 / 249

      • std::bind를 사용하는 것보다 람다가 더 읽기 쉽고 표현력이 좋다. 그리고 더 효율적일 수 있다.

        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 예를 들어 소리 나는 경보(alarm)를 설정하는
        3. // 함수를 작성한다고 하자.
        4.  
        5.  
        6. // 시간상의 한 지점을 대표하는 타입 별칭(using 구문은 항목 9 참고)
        7. using Time = std::chrono::steady_clock::time_point;
        8.  
        9. // enum class에 관해서는 항목 10을 보라
        10. enum class Sound { Beep, Siren, Whistle };
        11.  
        12. // 시간 길이를 나타내는 타입에 대한 별칭 선언
        13. using Duration = std::chrono::steady_clock::duration;
        14.  
        15. // 시간 t에서 소리 s를 기간 d만큼 출력한다.
        16. void setAlarm(Time t, Sound s, Duration d);
        17.  
        18.  
        19. // 더 나아가서, 프로그램의 어떤 지점에서
        20. // 한 시간 후부터 30초간 소리를 내는 경보를
        21. // 설정한다고 하자.
        22.  
        23. // 그런데 경보음은 미리 결정되지 않는다고 하자.
        24.  
        25. // 그런 경우 setAlarm에 대한, 소리만 지정하면
        26. // 되는 인터페이스를 람다를 이용해서 작성해
        27. // 두면 편리할 것이다.
        28.  
        29. // setSoundL('L'은 lambda를 뜻함)은 경보음을
        30. // 직접 지정해서 한 시간 후부터 30초간 울리게
        31. // 하는 함수 객체이다.
        32. auto setSoundL =
        33. [](Sound s)
        34. {
        35. // std::chrono의 구성요소들을 한정사 없이 사용할 수 있게 한다.
        36. using namespace std::chrono;
        38. setAlarm(steady_clock::now() + hours(1), // 한 시간 후부터
        39. s, // 지정된 경보음을
        40. seconds(30)); // 30초 간 재생
        41. };
        42.  
        43. // 람다에 익숙하지 않은 사람이라도, 람다에 전달된
        44. // 매개변수 s가 setAlarm의 한 인수로 전달됨을
        45. // 이해할 수 있을 것이다.
        46.  
        47. // C++14에서는 C++11의 사용자 정의 리터럴 기능에
        48. // 기초하는 표준 접미사(suffix)들을 이용해서 코드를
        49. // 더욱 간결하게 만들 수 있다.
        50.  
        51. // 이를테면 초는 s, 밀리초는 ms, 시간은 h라는
        52. // 접미사를 이용해서 지정하면 된다.
        53.  
        54. // 다음은 std::literals 이름공간에서 구현되어 있는
        55. // 이러한 접미사들을 이용해서 위의 코드를 다시
        56. // 작성한 것이다.
        57.  
        58. auto setSoundL =
        59. [](Sound s)
        60. {
        61. using namespace std::chrono;
        62. using namespace std::literals; // C++14 접미사들을 위해
        64. setAlarm(steady_clock::now() + 1h, // C++14 버전;
        65. s, // 의미는 앞의
        66. 30s); // 예제와 동일함
        67. };
        68.  
        69.  
        70. //-----------------------------------------------------------------------------
        71. // 이제 이와 같은 일을 하는 함수 객체를
        72. // std::bind를 이용해서 작성해 보자.
        73.  
        74. // 다음은 약간의 오류가 포함되어 있는 예제이다.
        75.  
        76. using namespace std::chrono; // 이전과 동일
        77. using namespace std::literals;
        78.  
        79. using namespace std::placeholders; // _1을 사용하는 데 필요함
        80.  
        81. auto setSoundB = // B는 bind를 뜻함
        82. std::bind(setAlarm,
        83. steady_clock::now() + 1h, // 문제가 있음! 아래 설명 참고
        84. _1,
        85. 30s);
        86.  
        87. // 람다 버전에서처럼 setAlarm 호출 부분을
        88. // 강조하고 싶었지만, 여기에는 강조할 호출이 없다.
        89.  
        90. // 자리표(placeholder) "_1"을 처음 보았다면
        91. // 그 부분이 사실상 마법으로 보일 것이다.
        92.  
        93. // 그리고 자리표 구문을 알더라도, setSoundB 호출의
        94. // 첫 인수가 setAlarm의 둘째 인수로 전달된다는
        95. // 점을 파악하려면 머릿속에서 그 자리표의 번호를
        96. // std::bind 매개변수 목록에서의 그 자리표의
        97. // 위치와 연결하려는 과정을 거쳐야 한다.
        98.  
        99. // 그리고 std::bind 호출 부분만 봐서는
        100. // 이 인수의 타입을 알 수 없으므로, setSoundB에
        101. // 어떤 종류의 인수가 전달되는지를 알기 위해
        102. // setAlarm 선언을 살펴봐야 한다.
        103.  
        104. // 앞에서 언급했듯이, 이 코드는 정확하지 않다.
        105.  
        106. // 람다 버전에서는 "steady_clock::now() + 1h"라는
        107. // 표현식이 setAlarm을 호출하는 시점에서 평가되고,
        108. // 그 시점으로부터 한 시간 후에 경보가 울리게 된다.
        109.  
        110. // 그러나 std::bind 호출에서 인수 "steady_clock::now() + 1h"는
        111. // setAlarm을 호출하고 한 시간이 지난 후가 아니라
        112. // set::bind를 호출하고 한 시간이 지난 후에 울린다.
        113.  
        114. // 이 문제를 바로잡으려면, 그 표현식을 setAlarm
        115. // 호출 때까지 지연하라고 std::bind에게 알려주어야
        116. // 한다.
        117.  
        118. // 그러려면 다음과 같이 코드를 짜야 한다.
        119.  
        120. auto setSoundB =
        121. std::bind(setAlarm,
        122. std::bind(std::plus<>(),
        123. std::bind(steady_clock::now),
        124. 1h),
        125. _1,
        126. 30s);
        127.  
        128. // "std::plus<어떤 타입>" 대신 "std::plus<>"가
        129. // 쓰인 점이 의아할 수 있다.
        130.  
        131. // 일반적으로 C++14에서는 표준 연산자 템플릿에
        132. // 대한 템플릿 타입 인수를 생략할 수 있으며,
        133. // 지금도 그런 일반적인 상황에 해당한다.
        134.  
        135. // C++11에는 이런 기능이 없으므로, 다음과 같이
        136. // 코드를 작성해야 한다.
        137.  
        138. using namespace std::chrono;
        139. using namespace std::placeholders;
        140.  
        141. auto setSoundB =
        142. std::bind(setAlarm,
        143. std::bind(std::plus<steady_clock::time_point>(),
        144. std::bind(steady_clock::now),
        145. hours(1)),
        146. _1,
        147. seconds(30));
        148.  
        149. // 이것만 보더라도 std::bind를 선호할 마음이
        150. // 사라졌을 것이다.
        151.  
        152.  
        153. //-----------------------------------------------------------------------------
        154. // 여기서 끝이 아니다.
        155.  
        156. // setAlarm을 오버로딩하면 새로운 문제가 발생한다.
        157.  
        158. // 경보음의 크기(음량)를 네 번째 매개변수로 받는
        159. // 다음과 같은 오버로딩 버전을 추가한다고 하자.
        160.  
        161. enum class Volume { Normal, Loud, LoudPlusPlus };
        162.  
        163. void setAlarm(Time t, Sound s, Duration d, Volume v);
        164.  
        165. // 람다는 예전처럼 작동한다.
        166.  
        167. // 오버로딩 해소에 의해, setAlarm의 인수 세
        168. // 개짜리 버전이 선택되기 때문이다.
        169.  
        170. auto setSoundL =
        171. [](Sound s)
        172. {
        173. using namespace std::chrono;
        175. setAlarm(steady_clock::now() + 1h, // OK; setAlarm의
        176. s, // 3 인수 버전을
        177. 30s); // 호출한다.
        178. };
        179.  
        180. // 반면 std::bind 버전은 컴파일되지 않는다.
        181.  
        182. auto setSoundB = // 오류! 어떤
        183. std::bind(setAlarm, // setAlarm인지?
        184. std::bind(std::plus<>(),
        185. std::bind(steady_clock::now),
        186. 1h),
        187. _1,
        188. 30s);
        189.  
        190. // 문제는, 컴파일러로서는 두 setAlarm 함수 중
        191. // 어떤 것을 std::bind에 넘겨주어야 할지
        192. // 결정할 방법이 없다는 것이다.
        193.  
        194. // 컴파일러가 알고 있는 것은 함수 이름뿐이며,
        195. // 이름만으로는 모호성을 해소할 수 없다.
        196.  
        197. // 이를 해결하려면, setAlarm을 적절한 함수
        198. // 포인터 타입으로 캐스팅해야 한다.
        199.  
        200. using SetAlarm3ParamType = void(*)(Time t, Sound s, Duration d);
        201.  
        202. auto setSoundB = // 이제는
        203. std::bind(static_cast<SetAlarm3ParamType>(setAlarm), // OK
        204. std::bind(set::plus<>(),
        205. std::bind(steady_clock::now),
        206. 1h),
        207. _1,
        208. 30s);
        209.  
        210. // 이 경우 람다와 std::bind의 차이점이
        211. // 하나 더 생긴다.
        212.  
        213. // 람다의 경우 setAlarm의 호출을 인라인화
        214. // (inlining)할 수 있는 보통의 함수 호출이다.
        215.  
        216. // 반면, std::bind의 경우 setAlarm을
        217. // 함수 포인터를 통해 호출하는데, 함수 포인터를
        218. // 통한 함수의 호출은 인라인화가 될 가능성이 작다.
        219.  
        220. // 즉, 람다를 사용하는 것이 더 효율적이다.
        221.  
        222.  
        223. //-----------------------------------------------------------------------------
        224. // 좀 더 복잡한 코드에서는 람다의 장점이 두드러진다.
        225.  
        226. // 다음 람다는 주어진 인수가 최솟값(lowVal)과
        227. // 최댓값(highVal) 사이에 있는지의 여부를 돌려준다.
        228.  
        229. // lowVal과 highVal은 지역 변수들이다.
        230.  
        231. auto betweenL =
        232. [lowVal, highVal]
        233. (const auto& val) // C++14
        234. { return lowVal <= val && val <= highVal; };
        235.  
        236. // 이를 std::bind로도 표현할 수 있으나,
        237. // 매우 읽기가 힘들다.
        238.  
        239. using namespace std::placeholders; // 이전과 동일
        240.  
        241. auto betweenB = // C++14
        242. std::bind(std::logical_and<>(),
        243. std::bind(std::less_equal<>(), lowVal, _1),
        244. std::bind(std::less_equal<>(), _1, highVal));
        245.  
        246. // C++11에서는 비교할 타입들을 명시적으로
        247. // 지정해야 하므로 다음과 같이 된다.
        248.  
        249. auto betweenB = // C++11 버전
        250. std::bind(std::logical_and<bool>(),
        251. std::bind(std::less_equal<int>(), lowVal, _1),
        252. std::bind(std::less_equal<int>(), _1, highVal));
        253.  
        254. // 물론 C++11에서는 람다가 auto 매개변수를 받지
        255. // 못하므로, 람다에서도 해당 타입을 지정해야 한다.
        256.  
        257. auto betweenL = // C++11 버전
        258. [lowVal, highVal]
        259. (int val)
        260. { return lowVal <= val && val <= highVal; };
        261.  
        262. // 어떤 경우이든, 람다 버전이 더 짧고 이해하기도 쉽다.
        263.  
        264.  
        265. //-----------------------------------------------------------------------------
        266. // 자리표 구문은, 그 행동이 불투명하기 때문이라는
        267. // 이유만으로 불편한 것은 아니다.
        268.  
        269. // Widget 객체의 압축 복사본을 만드는 함수가
        270. // 있다고 하자.
        271.  
        272. enum class CompLevel { Low, Normal, High }; // 압축 수준
        273.  
        274. Widget compress(const Widget& w, // w의 압축 복사본을
        275. CompLevel lev); // 만든다.
        276.  
        277. // 그리고 특정한 Widget 객체 w의 압축 수준을
        278. // 지정할 수 있는 함수 객체를 만든다고 하자.
        279.  
        280. // std::bind를 쓰면 다음과 같을 것이다.
        281.  
        282. Widget w;
        283.  
        284. using namespace std::placeholders;
        285.  
        286. auto compressRateB = std::bind(compress, w, _1);
        287.  
        288. // std::bind에 전달된 w는 이후의 compress
        289. // 호출을 위해 바인드 객체 compressRateB 안에
        290. // 저장된다.
        291.  
        292. // 그런데 w가 값으로 저장될까, 아니면 참조로 저장될까?
        293.  
        294. // 답은 "값으로 전달된다"이다.
        295.  
        296. // 문제는, 명시적으로 드러나지 않기 때문에 std::bind의
        297. // 작동 방식을 알고 있어야 이를 알 수 있다는 것이다.
        298.  
        299. // 반면 람다 접근방식에는 w가 값으로 갈무리되는지 아니면
        300. // 참조로 갈무리되는지 소스 코드에 명백히 드러난다.
        301.  
        302. auto compressRateL = // w는 값으로 갈무리되고
        303. [w](CompLevel lev) // lev는 값으로 전달된다.
        304. { return compress(w, lev); };
        305.  
        306. // 람다에서는 매개변수들이 전달되는 방식도
        307. // 갈무리만큼이나 명백하게 드러난다.
        308.  
        309. // 지금 예에서는 lev가 값으로 전달됨을
        310. // 바로 알 수 있다.
        311.  
        312. compressRateL(CompLevel::High); // 인수는 값으로
        313. // 전달된다.
        314.  
        315. // 그러나 std::bind로 얻은 바인드 객체를 호출할
        316. // 때에는 인수의 전달 방식이 명확하지 않다.
        317.  
        318. compressRateB(CompLevel::High); // 인수는 어떻게
        319. // 전달될까?
        320.  
        321. // 이 경우에도, 인수의 전달 방식을 알려면
        322. // std::bind의 작동방식을 알아야 한다
        323. // (담은, 바인드 객체에 전달되는 모든 인수는
        324. // 참조로 전달된다는 것이다. 이는 완벽 전달을
        325. // 사용하기 때문이다).

        
        
        예제 코드 접기
        
        
        

      • C++14가 아닌 C++11에서는 이동 갈무리를 구현하거나 객체를 템플릿화된 함수 호출 연산자에 묶으려 할 때 std::bind가 유용할 수 있다.

        C++14에서는 람다 대신 std::bind를 써야 할 이유가 전혀 없다. C++11에서는, 다음과 같이 제한된 두 경우라면 std::bind의 사용을 정당화할 수 있다.
        
        
        • 이동 갈무리(move capture): C++11 람다는 이동 갈무리를 지원하지 않는다. 그러나 람다와 std::bind의 조합을 통해서 이동 갈무리를 흉내 내는 것은 가능하다. 자세한 사항은 항목 32를 보기 바란다. 그 항목은 C++14에서는 초기화 갈무리 덕분에 그러한 흉내가 더 이상 필요하지 않다는 점도 설명한다.
        • 다형적 함수 객체(polymorphic function object): 바인드 객체에 대한 함수 호출 연산자는 완벽 전달을 사용하기 때문에 그 어떤 타입의 인수들도 받을 수 있다(단, 항목 30에서 설명한 완벽 전달의 제약 안에서). 이는 객체를 템플릿화된 함수 호출 연산자와 묶으려 할 때 유용하다.
          
          예제 코드 보기
          
          
          

          1. // 예를 들어 다음과 같은 클래스가 있다고 하자.
          2.  
          3. class PolyWidget {
          4. public:
          5. template <typename T>
          6. void operator()(const T& param) const;
          7. ...
          8. };
          9.  
          10. // std::bind로 PolyWidget 객체를 묶으려면
          11. // 다음과 같이 하면 된다.
          12.  
          13. PolyWidget pw;
          14.  
          15. auto boundPW = std::bind(pw, _1);
          16.  
          17. // 이제 boundPW를 서로 다른 타입의
          18. // 인수들로 호출할 수 있다.
          19.  
          20. boundPW(1930); // PolyWidget::operator()에
          21. // int를 전달
          22.  
          23. boundPW(nullptr); // PolyWidget::operator()에
          24. // nullptr를 전달
          25.  
          26. boundPW("Rosebud"); // PolyWidget::operator()에
          27. // 문자열을 전달
          28.  
          29. // C++11의 람다로는 이런 일이 불가능하다.
          30.  
          31. // 그러나 C++14에서는 auto 매개변수를
          32. // 가진 람다로 간단히 구현할 수 있다.
          33.  
          34. auto boundPW = [pw](const auto& param) // C++14
          35. { pw(param); }
          36.  

          
          
          예제 코드 접기
          
          
          
        이들은 극단적인 경우들이며, C++14 람다를 지원하는 컴파일러가 점차 늘어남에 따라 이런 경우들도 점차 사라질 것이다.

• Chapter 7   동시성 API

  이번 장의 항목들에서, 표준 라이브러리에는 future 객체를 위한 템플릿이 두 가지임을 염두해 두기 바란다. 바로 std::future와 std::shared_future인데, 이 둘의 구분이 중요하지 않은 경우가 많기 때문에 이번 장에서는 그냥 둘을 future 객체라고 통칭하는 경우가 많다.

  35. 스레드 기반 프로그래밍보다 task 기반 프로그래밍을 선호하라 / 259

      • std::thread API에서는 비동기적으로 실행된 함수의 반환값을 직접 얻을 수 없으며, 만일 그런 함수가 예외를 던지면 프로그램이 종료된다.

        doAsyncWork라는 함수를 비동기적으로 실행한다고 하자. 방법은 크게 두 가지이다. 하나는 std::thread 객체를 생성해서 그 객체에서 doAsyncWork를 실행하는 것이다. 이는 스레드 기반(thread-based) 프로그래밍에 해당한다.
        
        int doAsyncWork(void);
        
        std::thread t(doAsyncWork);
        
        또 하나는 doAsyncWork를 std::async에 넘겨주는 것이다. 이는 task 기반(task-based) 프로그래밍에 해당한다(원서 정오표는 단지 std::async를 사용한다고 해서 저절로 task 기반 프로그래밍이 되는 것은 아님을 지적하면서, 참고 자료로 바르토시 밀레프스키^{Bartosz Milewski}의 2011년 10월 22자 블로그 글 "Async Tasks in C++11: Not Quite There Yet"을 소개한다).
        
        auto fut = std::async(doAsyncWork);
        // fut은 future를 뜻함
        
        이런 호출에서, std::async에 절달된 함수 객체는 하나의 task로 간주된다.
        
        이 예제에서 doAsyncWork는 반환값을 돌려주는데, 스레드 기반 호출에서는 그 반환값에 접근할 방법이 없다. 그러나 task 기반 접근방식에서는, std::async 객체가 돌려주는 future 객체에있는 get이라는 멤버 함수를 통해 반환값에 접근할 수 있다.
        
        doAsyncWork가 예외를 방출한 경우, get을 통해서 그 예외에 접근할 수도 있다. 스레드 기반 접근방식에서는, doAsyncWork가 예외를 던지면 프로그램이 죽는다(std::terminate 호출을 통해서).

      • 스레드 기반 프로그래밍에서는 스레드 고갈, 과다구독(oversubscription), 부하 균형화, 새 플랫폼으로의 적응을 여러분이 직접 처리해야 한다.

        먼저 동시적 C++ 소프트웨어에서 '스레드'라는 용어가 세 가지 의미로 쓰인다는 점을 지적하고 넘어갈 필요가 있겠다.
        
        
        • 실제 계산을 수행하는 스레드를 뜻하는 하드웨어 스레드. 현세대의 컴퓨터 아키텍처는 CPU 코어당 하나 이상의 하드웨어 스레드를 제공한다.
        • 운영체제가 하드웨어 스레드들에서 실행되는 모든 프로세서와 일정을 관리하는 데 사용하는 소프트웨어 스레드. OS 스레드나 시스템 스레드라고도 한다. 대체로, 하드웨어 스레드보다 많은 소프트웨어 스레드를 생성할 수 있다. 한 소프트웨어 스레드가 차단(blocking)되어도(이를테면 입출력 연산이 진행중이거나, 뮤텍스나 조건 변수를 기다리는 등), 차단(blocking)되지 않은 다른 소프트웨어 스레드들을 실행함으로써 산출량을 향상할 수 있기 때문이다.
        • C++ 표준 라이브러리의 std::thread. 하나의 C++ 프로세스 안에서 std::thread 객체는 바탕 소프트웨어 스레드에 대한 핸들로 작용한다. std::thread 객체가 '널^null' 핸들을 나타내기도 한다. 즉, std::thread 객체가 그 어떤 소프트웨어 스레드에도 대응되지 않을 수 있다. 기본 생성자로 생성된(따라서 실행할 함수가 없는) 상태이거나, 다른 std::thread 객체로 이동한 후이거나, join을 통해서 다른 스레드들과 합류한 후(실행하던 함수가 종료된 후)이거나, detach를 통해서 탈착된 후(std::thread 객체와 바탕 소프트웨어 스레드 사이의 연결이 끊어진 후)이면 그럴 수 있다.
        
        
        소프트웨어 스레드는 제한된 자원이다. 시스템이 제공할 수 있는 것보다 많은 소프트웨어 스레드를 생성하려고 하면 std::system_error 예외가 발생한다. 이는 스레드에서 실행하고자 하는 함수가 예외를 던질 수 없는 경우에도 마찬가지이다.
        
        int doAsyncWork(void) noexcept;
        // noexcept는 항목 14를 보라
        
        다음 문장은 예외를 던질 수 있다.
        
        std::thread t(doAsyncWork);
        // 사용 가능한 스레드가 없으면
        // 예외가 발생한다.
        
        스레드 기반 프로그래밍에서는 이런 스레드 부족을 프로그래머가 직접 처리해야 한다. 한 가지 접근방식은 doAsyncWork를 그냥 현재 스레드에서 실행하는 것이지만, 그러면 현재 스레드에 부하(load)가 과중하게 걸릴 수 있다. 만일 현재 스레드가 GUI 스레드라면 사용자 입력에 대한 반응성 문제가 발생할 수 있는 것이다.
        
        또 다른 접근방식은 기존의 일부 소프트웨어 스레드가 완료되길 기다렸다가 std::thread를 새로 생성하는 것이다. 그런데 기존 스레드들이 doAsyncWork가 수행해야 하는 어떤 동작을 기다리고 있을 수도 있다.
        
        가용 스레드가 모자라지 않는다고 해도, 과다구독(oversubscription) 때문에 문제가 발생할 수 있다. 과다구독(oversubscription)이란 실행 준비가 된 소프트웨어 스레드가 하드웨어 스레드보다 많은 상황을 가리킨다.
        
        과다구독(oversubscription)이 발생하면 스레드 스케줄러(보통의 경우 OS의 일부)는 하드웨어상의 실행 시간을 여러 조각으로 나누어 소프트웨어 스레드들에게 배분한다. 이 과정에서 문맥 전환(context switch)이 수행된다. 그러한 문맥 전환은 시스템의 전반적인 스레드 관리 부담을 증가시킨다.
        
        과다구독(oversubscription)을 피하기는 어렵다. 소프트웨어 스레드 개수와 하드웨어 스레드 개수의 이상적인 비율은 실행 가능한 소프트웨어 스레드 개수에 의존하는 경우가 많으며, 그러한 개수가 동적으로 변할 수 있기 때문이다.
        
        또한 이 비율은, 문맥 전환 비율에, 그리고 소프트웨어 스레드가 CPU 캐시를 얼마나 효율적으로 활용하는가에도 의존한다. 게다가 하드웨어 스레드 개수와 CPU 캐시의 세부사항(크기, 상대적 빠르기 등)은 CPU 아키텍처에 의존한다.
        
        결과적으로 여러분이 과다구독(oversubscription)을 피하도록 응용 프로그램을 잘 조율한다고 해도, 그 해법이 다른 종류의 컴퓨터에서도 잘 작동하리라는 보장은 없다.

      • std::async와 기본 시동 방침(launch policy)을 이용한 task 기반 프로그래밍은 그런 대부분의 문제를 알아서 처리해준다.

        std::async를 사용하면 스레드 부족으로 인해 예외가 발생할 가능성이 크게 줄어든다. 기본 시동 방침(launch policy)을 지정한(항목 36을 보라) 호출에서는 std::async가 새 소프트웨어 스레드를 생성하지 않을 수도 있다.
        
        대신 std::async는 지정된 함수를 doAsyncWork의 결과가 필요한 스레드(즉, fut에 대해 get이나 wait를 호출하는 스레드)에서 실행하라고 스케줄러에게 요청할 수 있으며, 합리적인 스케줄러는 시스템이 과다구독(oversubscription)되었거나 스레드가 부족한 상황에서 그러한 자유의 장점을 취한다.
        
        한 가지 경고하자면, 이 기법을 적용했을 때에도 앞에서 말한 부하 불균형 문제가 발생할 수 있다. 단 부하 균형화와 관련해서, 컴퓨터에서 일어나는 일들의 전반적인 상황을 실행 스케줄러가 여러분보다 더 상세히 알고 있을 가능성이 크다.
        
        std::async에서도 GUI 스레드의 반응성이 여전히 문제가 될 수 있다. 그런 경우에는 std::launch::async라는 시동 방침(launch policy)을 std::async에 넘겨주는 것이 바람직하다. 그러면 실행하고자 하는 함수가 실제로 현재 스레드와는 다른 스레드에서 실행된다(항목 36 참고).
        
        최신의 스레드 스케줄러는 시스템 전역 스레드 풀을 이용해서 과다구독(oversubscription)을 피하며, 작업 훔치기(work-stealing) 알고리즘을 이용해서 부하를 하드웨어 코어들에 좀 더 균형 있게 분산한다.
        
        앞으로도 이 분야의 발전이 계속되리라고 기대하는 것은 합당하며, task 기반 접근방식으로 개발한 동시적 프로그램은 그런 기술이 좀 더 널리 퍼짐에 따라 그 혜택을 저절로 받게 된다.
        
        그렇긴 하지만, 스레드를 직접 다루는 게 적합한 경우도 존재한다. 이를테면 다음과 같다.
        
        
        • 바탕 스레드 적용 라이브러리의 API에 접근해야 하는 경우. 일반적으로 C++ 동시성 API는 저수준 플랫폼 고유 API를 이용해서 구현된다. 흔히 쓰이는 것은 pthreads 라이브러리나 Windows 스레드 라이브러리이다. 현재, 이런 API들은 C++보다 풍부한 기능을 제공한다(예를 들어 C++에는 스레드 우선순위나 친화도(affinity) 같은 개념이 없다). 바탕 스레드 적용 라이브러리의 API에 접근할 수 있도록, std::thread 객체는 흔히(반드시 그렇지는 않아서 이식성이 없음을 뜻한다) native_handle이라는 멤버 함수를 제공한다. 그런데 std::future(std::async가 돌려주는)에는 이에 해당하는 기능이 없다.
        • 응용 프로그램의 스레드 사용량을 최적화해야 하는, 그리고 할 수 있어야 하는 경우. 예를 들어 하드웨어 특성들이 미리 정해진 컴퓨터에서 유일하게 의미 있는 프로세스(OS 프로세스들이나 기타 사소한 프로세스들을 제외할 때)로 실행될 서버 소프트웨어를 개발한다면 이러한 요구가 생길 수 있다.
        • C++ 동시성 API가 제공하는 것 이상의 스레드 적용 기술을 구현해야 하는 경우. 이를테면 여러분이 사용하는 C++ 구현이 스레드 풀을 제공하지 않는 특정 플랫폼을 위한 스레드 풀을 직접 구현해야 하는 경우가 있다.
        
        
        물론 이들은 흔치 않은 경우이며, 대부분의 경우에서는 스레드를 직접 다루는 대신 task 기반 설계를 사용하는 것이 바람직하다.

  36. 비동기성이 필수일 때에는 std::launch::async를 지정하라 / 265

      • std::async의 기본 시동 방침(launch policy)은 task의 비동기적 실행과 동기적 실행을 모두 허용한다.

        std::async를 호출해서 어떤 함수(또는 호출 가능한 객체)를 실행하는 것에는 그 함수를 비동기적으로 실행하겠다는 의도가 깔려 있지만, 반드시 그 함수가 비동기적으로 실행되는 것은 아니라는 사실을 주의할 필요가 있다.
        
        std::async는 함수 호출을 시동 방침(launch policy)에 따라 비동기적으로 실행할 수도 있고 지연해서 실행할 수도 있다. 시동 방침(launch policy)은 두 가지인데, std::launch 범위의 enum에 정의된 열거자들을 이용해서 지정할 수 있다(범위 있는 enum에 관해서는 항목 10을 보라).
        
        함수 f를 std::async를 통해서 실행한다고 할 때,
        
        
        • std::launch::async 시동 방침(launch policy)을 지정하면 f는 반드시 비동기적으로, 다시 말해서 다른 스레드에서 실행된다.
        • std::launch::deferred 시동 방침(launch policy)을 지정하면 f는 std::async가 돌려준 future 객체(std::future)에 대해 get이나 wait가 호출될 때에만 실행될 수 있다. 다시 말해서, f는 그러한 호출이 일어날 때까지 지연된다(deferred). get이나 wait가 호출되면 f는 동기적으로 실행된다. 즉 호출자는 f의 실행이 종료될 때까지 차단(blocking)된다. get이나 wait가 호출되지 않으면 f는 결코 실행되지 않는다.
        
        
        기본 시동 방침(launch policy)은 이 둘을 OR로 결합한 것이다.
        
        기본 시동 방침(launch policy) 예제 코드 보기
        
        
        

        1. // 즉, 다음 두 호출은 완전히 같은 의미이다.
        2.  
        3. auto fut1 = std::async(f); // 함수 f를 기본
        4. // 시동 방침(launch policy)으로
        5. // 실행한다.
        6.  
        7. auto fut2 = std::async(std::launch::async | // 함수 f를 비동기로
        8. std::launch::deferred, // 또는 지연해서
        9. f); // 실행한다.
        10.  

        
        
        기본 시동 방침(launch policy) 예제 코드 접기
        
        
        결과적으로, 기본 시동 방침(launch policy)에서 f는 비동기적으로 실행될 수도 있고 동기적으로 실행될 수도 있다.

      • 그러나 이러한 유연성 때문에 thread_local 접근의 불확실성이 발생하고, task가 절대로 실행되지 않을 수도 있고, 시간 만료 기반 wait 호출에 대한 프로그램 논리에도 영향이 미친다.

        std::async를 기본 시동 방침(launch policy)과 함께 사용하면 몇 가지 흥미로운 영향이 생긴다. 예를 들어 다음 문장이 스레드 t에서 실행된다고 하자.
        
        auto fut = std::async(f);
        
        그러면,
        
        
        • f가 지연 실행될 수도 있으므로, f와 t가 동시에 실행될지 예측하는 것이 불가능하다.
        • f가 fut에 대해 get이나 wait를 호출하는 스레드와는 다른 스레드에서 실행될 지 예측하는 것이 불가능하다. t가 그 스레드라고 할 때, f와 t와는 다른 스레드에서 실행될지는 예측할 수 없다.
        • 프로그램의 모든 가능한 경로에서 fut에 대한 get이나 wait 호출이 일어난다는 보장이 없을 수도 있으므로, f가 반드시 실행될 것인지 예측하는 것이 불가능할 수도 있다.
        
        
        기본 시동 방침(launch policy)의 스케줄링 유연성이 thread_local 변수들의 사용과는 궁합이 잘 맞지 않는 경우도 많다.
        
        이 유연성은 또한 만료 시간이 있는 wait 기반 루프에도 영향을 미친다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // f에 그런 스레드 지역 저장소(thread-local storage, TLS)를
        3. // 읽거나 쓰는 코드가 있다고 할 때, 그 코드가 어떤
        4. // 스레드의 지역 변수에 접근할지 예측할 수 없다.
        5.  
        6. auto fut = std::async(f); // f의 TLS가 독립적인 스레드의
        7. // 것일 수도 있고, fut에
        8. // 대해 get이나 wait를
        9. // 호출하는 스레드의 것일 수도
        10. // 있다.
        11.  
        12.  
        13. //-----------------------------------------------------------------------------
        14. // 지연된 task에 대해 wait_for나 wait_until을
        15. // 호출하면 std::future_status::deferred라는
        16. // 값이 반환되기 때문에, 예를 들어 언젠가는
        17. // 끝날 것처럼 보이는 다음 루프가 실제로는
        18. // 무한이 실행될 수도 있다.
        19.  
        20. using namespace std::literals; // C++14의 시간 접미사들을
        21. // 위해; 항목 34를 보라
        22.  
        23. void f(void) // f는 1초간 수면 후
        24. { // 반환된다.
        25. std::this_thread::sleep_for(1s);
        26. }
        27.  
        28. auto fut = std::async(f); // f를 비동기적으로
        29. // (개념상으로는) 실행한다.
        30.  
        31. while (fut.wait_for(100ms) != // f의 실행이 끝날 때까지
        32. std::future_status::ready) // 루프를 반복한다...
        33. { // 그런데 실행이 끝나지 않을
        34. ... // 수도 있다!
        35. }
        36.  
        37. // f가 std::async를 호출한 스레드와 동시에
        38. // 실행된다면, f 자체가 무한히 실행되는 것이
        39. // 아닌 이상 문제는 없다.
        40.  
        41. // 그러나 f가 지연된다면, fut.wait_for는 항상
        42. // std::future_status::deferred를 돌려준다.
        43.  
        44. // 그 값은 std::future_status::ready와는 절대
        45. // 같지 않으므로, 루프는 절대 종료되지 않는다.
        46.  
        47. // 이런 종류의 버그는 부하가 아주 많이 걸리지
        48. // 않으면 드러나지 않을 수 있으므로, 개발과
        49. // 단위 검사(unit testing) 도중에는 간과하기
        50. // 쉽다.
        51.  
        52. // 컴퓨터에 부하가 아주 많이 걸리면 과다구독(oversubscription)이나
        53. // 스레드 고갈 현상이 나타나며, 그러면 task가
        54. // 지연될 가능성이 아주 커진다.
        55.  
        56. // 이러한 문제의 해결책은 간단하다.
        57.  
        58. // 그냥 std::async 호출이 돌려준 future
        59. // 객체를 이용해서 해당 task가 지연되었는지
        60. // 점검하고, 지연되었다면 시간 만료(timeout)
        61. // 기반 루프에 진입하지 않게 하는 것이다.
        62.  
        63. // 안타깜게도 task의 지연 여부를 future 객체로부터
        64. // 직접 알아내는 방법은 없다.
        65.  
        66. // 대신 wait_for 같은 시간 만료 기반 함수를
        67. // 호출해야 한다.
        68.  
        69. // 단, 이 경우 목적은 실제로 뭔가를 기다리는
        70. // 것이 아니므로, 만료 시간을 0으로 해서
        71. // wait_for를 호출하면 된다.
        72.  
        73. auto fut = std::async(f); // 이전과 동일
        74.  
        75. if (fut.wait_for(0s) == // 만일 task가
        76. std::future_status::deferred) // 지연되었으면...
        77. {
        78. // ... fut에 wait나 get을 적용해서
        79. ... // f를 동기적으로 호출한다.
        81. } else { // task가 지연되지 않았다.
        82. while (fut.wait_for(100ms) != // 무한 루프는 불가능
        83. std::future_status::ready) { // 하다(f가 완료된다고
        84. // 가정할 때).
        85.  
        86. ... // task가 지연되지도 않았고 준비되지도 않았으므로
        87. // 준비될 때까지 동시적 작업을 수행한다.
        88. }
        90. ... // fut이 준비되었다.
        92. }

        
        
        예제 코드 접기
        
        
        

      • task를 반드시 비동기적으로 실행해야 한다면 std::launch::async를 지정하라.

        이러한 여러 고려사항에서 이끌어 낼 수 있는 결론 하나는, 어떤 task에 대해 기본 시동 방침(launch policy)과 함께 std::async를 사용하는 것은 다음 조건들이 모두 성립할 때에만 적합하다는 것이다.
        
        
        • task가 get이나 wait를 호출하는 스레드와 반드시 동시적으로 실행되어야 하는 것은 아니다.
        • 여러 스레드 중 어떤 스레드의 thread_local 변수들을 읽고 쓰는지가 중요하지 않다.
        • std::async가 돌려준 future 객체에 대해 get이나 wait가 반드시 호출된다는 보장이 있거나, task가 전혀 실행되지 않아도 괜찮다.
        • task가 지연된 상태일 수도 있다는 점이 wait_for나 wait_until을 사용하는 코드에 반영되어 있다.
        
        
        이 조건 중 하나라도 성립하지 않는다면 std::async가 주어진 task를 진정으로 비동기적으로 실행하도록 강제할 필요가 있다. 그렇게 하는 방법은 std::launc::async를 첫 인수로 지정해서 std::async를 호출하는 것이다.
        
        예제 코드 보기
        
        
        

        1. // std::async가 주어진 task를 비동기적으로
        2. // 실행하도록 강제하려면 다음과 같이 하면 된다.
        3.  
        4. auto fut = std::async(std::launch::async, f); // f를 비동기적으로
        5. // 시동(launch)한다.
        6.  
        7. // std::async를 이런 방식으로 사용할 때마다
        8. // std::launch::async 시동 방침(launch policy)을 명시적으로
        9. // 지정하지 않아도 된다면 더욱 좋을 것이다.
        10.  
        11. // 다행히 그런 함수를 만드는 것은 간단한 일이다.
        12. // 다음은 C++11 버전이다.
        13.  
        14. template <typename F, typename... Ts>
        15. inline
        16. std::future<typename std::result_of<F(Ts...)>::type>
        17. reallyAsync(F&& f, Ts&&... params) // 비동기적 f(params...)
        18. { // 호출을 위한 future 객체를
        19. return std::async(std::launch::async, // 돌려준다.
        20. std::forward<F>(f),
        21. std::forward<Ts>(params)...);
        22. }
        23.  
        24. // std::async처럼 이 함수는 params로 f를
        25. // 호출한 결과를 나타내는 std::future 객체를 돌려준다.
        26.  
        27. // 그 결과의 타입을 결정하는 것은 쉽다.
        28.  
        29. // 타입 특성 std::result_of를 적용한 결과가
        30. // 바로 그 타입이다.
        31.  
        32. // reallyAsync의 사용법은 std::async의 것과 같다.
        33.  
        34. auto fut = reallyAsync(f); // f를 비동기적으로 실행한다;
        35. // std::async가 예외를 던질
        36. // 상황이라면 이 함수도 같은
        37. // 예외를 던진다.
        38.  
        39. // C++14에서는 반환 타입을 auto로 추론할
        40. // 수 있어서 함수 선언이 좀 더 간단해진다.
        41.  
        42. template <typename F, typename... Ts>
        43. inline
        44. auto // C++14
        45. reallyAsync(F&& f, Ts&&... params)
        46. {
        47. return std::async(std::launch::async,
        48. std::forward<F>(f),
        49. std::forward<Ts>(params)...);
        50. }

        
        
        예제 코드 접기
        
        
        

  37. std::thread들을 모든 경로에서 join 불가능하게 만들어라 / 270

      • 모든 경로에서 std::thread를 join 불가능으로 만들어라.

        모든 std::thread 객체는 join 가능(joinable) 상태이거나 join 불가능(unjoinable) 상태이다. join 가능 std::thread는 바탕 실행 스레드 중 현재 실행 중(running)이거나 실행 중 상태로 전이할 수 있는 스레드에 대응된다.
        
        예를 들어, 차단(blocking)된 상태이거나 실행 일정을 기다리는 중인 바탕 스레드에 해당하는 std::thread는 join 가능 상태이다. 그리고 실행이 완료된 바탕 스레드에 해당하는 std::thread 객체도 join 가능으로 간주한다.
        
        join 불가능한 std::thread 객체로는 다음과 같은 것들이 있다.
        
        
        • 기본 생성된 std::thread. 그런 std::thread 객체에는 실행할 함수가 없으므로 바탕 실행 스레드와는 대응되지 않는다.
        • 다른 std::thread 객체로 이동된 후의 std::thread 객체. 이동의 결과로, 원본 std::thread에 대응되는 바탕 스레드는 대상 std::thread의 바탕 스레드가 된다(그런 스레드가 있었다면).
        • join에 의해 합류된 std::thread. join 이후의 std::thread 객체는 실행이 완료된 바탕 실행 스레드에 대응되지 않는다.
        • detach에 의해 탈착된 std::thread. detach는 std::thread 객체와 그에 대응되는 바탕 스레드 사이의 연결을 끊는다.
        
        
        std::thread의 join 가능성이 중요한 이유 하나는, 만일 join 가능한 스레드의 소멸자가 호출되면 프로그램 실행이 종료된다는 것이다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 예를 들어 필터링 함수 filter와 최댓값 maxVal을
        3. // 매개변수로 받는 함수 doWork가 있다고 하자.
        4.  
        5. // doWork는 자신의 계산에 필요한 모든 조건이
        6. // 만족되었는지 점검한 후 0 이상 maxVal 미만의
        7. // 모든 값 중 주어진 필터를 통과한 값들에
        8. // 대해 계산을 수행한다.
        9.  
        10. // 필터링을 수행하는 것과, doWork 조건들의 만족
        11. // 여부를 점건하는 데에 시간이 많이 걸린다면,
        12. // 두 작업을 동시에 실행하는 것이 합리적이다.
        13.  
        14. // task 기반 설계를 적용하는 것이 좋겠지만
        15. // (항목 35 참고), 이번 예제에서는 필터링을
        16. // 수행하는 스레드의 우선순위를 설정해야 할
        17. // 필요가 있어서 스레드 기반으로 만들 수
        18. // 밖에 없다고 하자.
        19.  
        20. constexpr auto tenMillion = 10'000'000; // constexpr는
        21. // 항목 15를 보라.
        22. // C++14의 정수
        23. // 리터럴은 작은
        24. // 따옴표를 이용하여
        25. // 가독성을 높일 수
        26. // 있다.
        27.  
        28. bool doWork(std::function<bool(int)> filter, // 계산 수행 여부를
        29. int maxVal = tenMillion) // 돌려준다;
        30. { // std::function은
        31. // 항목 5를 보라
        33. std::vector<int> goodVals; // 필터를 통과한
        34. // 값들
        36. std::thread t([&filter, maxVal, &goodVals] // goodVals에
        37. { // 값들을 채운다.
        38. for (auto i = 0; i <= maxVal; ++i)
        39. { if (filter(i)) goodVals.push_back(i); }
        40. });
        42. auto nh = t.native_handle(); // t의 네이티브 핸들을
        43. ... // 이용해서 t의 우선
        44. // 순위를 설정한다.
        46. if (conditionAreSatisfied()) { // 조건들이 만족되었다면
        47. t.join(); // t의 완료를 기다린다.
        48. performComputation(goodVals);
        49. return true; // 계산이 수행되었음을
        50. } // 뜻하는 값을 반환
        52. return false; // 수행되지 않았음을
        53. } // 뜻하는 값을 반환
        54.  
        55. // t의 실행을 시작한 후 t의 우선순위를 설정하는 것은
        56. // 마치 소를 잃고 외양간을 고치듯이 순서가 틀린 것이다.
        57.  
        58. // 사실 t를 정지된 상태(suspended state)로 시작하는 것
        59. // (계산을 시작하기 전에 우선순위를 설정할 수 있도록)이
        60. // 더 나은 설계이다.
        61.  
        62. // 항목 39에서 스레드를 정지된 상태로 시작하는
        63. // 방법을 참고하기 바란다.
        64.  
        65. // conditionAreSatisfied()가
        66. // true를 돌려준다면 별 문제가 없다.
        67.  
        68. // 그러나 false를 돌려주거나 예외를 던진다면
        69. // 실행의 흐름이 doWork의 끝에 도달해서
        70. // t의 소멸자가 호출되는데, 이 때 t는
        71. // join 가능한 상태이므로 프로그램 실행이
        72. // 종료된다.
        73.  
        74.  
        75. //-----------------------------------------------------------------------------
        76. // std::thread의 소멸자가 이렇게 동작하는 이유는
        77. // 암묵적으로 join이나 detach를 하는 것 모두
        78. // 문제가 발생할 여지가 있기 때문이다.
        79.  
        80. // 그렇다고 해서 직접 모든 경로에서 std::thread 객체가
        81. // join 불가능하도록 만드는 것은 어려울 수 있다.
        82. // 실행 경로가 많을 수 있기 때문이다.
        83.  
        84. // 다행히 스마트 포인터(항목 18, 19, 20 참고)처럼
        85. // std::thread를 자동으로 join 불가능하게 만들어 주는
        86. // 객체를 만드는 것은 어렵지 않다.
        87.  
        88.  
        89. // RAII는 "Resource Acquisition Is Initialization"을 뜻한다.
        90. class ThreadRAII {
        91. public:
        92. enum class DtorAction { join, detach }; // enum class는
        93. // 항목 10을 보라
        94.  
        95. ThreadRAII(std::thread&& t, DtorAction a) // 소멸자에서 t에
        96. : action(a), t(std::move(t)) {} // 대해 동작 a를 수행
        98. ~ThreadRAII(void)
        99. {
        100. if (t.joinable()) { // join 가능성 판정은
        101. // 아래 본문 참고
        102. if (action == DtorAction::join) {
        103. t.join();
        104. } else {
        105. t.detach();
        106. }
        107. }
        108. }
        110. ThreadRAII(ThreadRAII&&) = default; // 이동 연산들
        111. ThreadRAII& operator=(ThreadRAII&&) = default; // 지원한다.
        113. std::thread& get(void) { return t; } // 아래 본문 참고
        115. private:
        116. DtorAction action;
        117. std::thread t;
        118. };
        119.  
        120. // 다음 몇 가지 요점을 짚어 보자.
        121.  
        122.  
        123. // 1. -------------------------------------------
        124. // 생성자는 std::thread 우측값만 받는다.
        125. // 그것을 ThreadRAII 객체로 이동할 것이기
        126. // 때문이다(std::thread 객체는 복사할 수 없다).
        127.  
        128.  
        129. // 2. -------------------------------------------
        130. // 생성자의 매개변수들은 호출자가 직관적으로
        131. // 기억할 수 있는 순서로 선언되어 있다.
        132.  
        133. // 그러나 멤버 초기화 리스트는 데이터 멤버들이 선언된
        134. // 순서를 따른다.
        135.  
        136.  
        137. // 3. -------------------------------------------
        138. // ThreadRAII는 바탕 std::thread 객체에
        139. // 접근할 수 있는 get 함수를 제공한다.
        140.  
        141. // 이처럼 get을 제공하면 std::thread 인터페이스
        142. // 전체를 ThreadRAII에 복제할 필요가 없다.
        143.  
        144. // 또한, 이는 std::thread를 사용할 수 있는
        145. // 문맥에서 ThreadRAII를 사용할 수 있다는
        146. // 의미이기도 하다.
        147.  
        148.  
        149. // 4. -------------------------------------------
        150. // ThreadRAII 소멸자는 std::thread 객체
        151. // t에 대해 멤버 함수를 호출하기 전에 먼저
        152. // t가 join 가능인지부터 점검한다.
        153.  
        154. // 이는 꼭 필요하다. join 불가능 스레드에
        155. // 대해 join이나 detach를 호출하면 미정의
        156. // 행동이 나오기 때문이다.
        157.  
        158.  
        159. // 5. -------------------------------------------
        160. // 소멸자에서 t가 join 가능한지 점검하는 부분과
        161. // t를 join 불가능하게 만드는(join이나 detach를
        162. // 호출하는 부분) 부분 사이에 다른 스레드가
        163. // 끼어들어 t를 join 불가능하게 만들어 버리면
        164. // 문제가 발생할 수 있다.
        165.  
        166. // 다행이 이는 기우이다. join 가능한 std::thread
        167. // 객체는 오직 멤버 함수 호출(join이나 detach) 또는
        168. // 이동 연산에 의해서만 join 불가능한 상태로
        169. // 변할 수 있다.
        170.  
        171. // ThreadRAII 객체의 소멸자가 호출되는 시점에서는
        172. // 그 객체에 대한 그런 멤버 함수를 호출할 만한
        173. // 스레드가 남아 있지 않아야 한다.
        174.  
        175. // 그런 호출들이 동시에 일어나는 곳은 소멸자
        176. // 만이 아니라, 하나의 객체에 대해 동시에 두
        177. // 멤버 함수를 실행하려 하는 클라이언트 코드이다.
        178.  
        179. // 일반적으로 하나의 객체에 대해 여러 멤버
        180. // 함수를 동시에 호출하는 것은 그 멤버 변수
        181. // 함수들이 const 멤버 함수인 경우에만
        182. // 안전하다(항목 16 참고).
        183.  
        184.  
        185. // 6. -------------------------------------------
        186. // ThreadRAII는 소멸자를 선언하므로 컴파일러가
        187. // 이동 연산들을 작성해주지 않는다(항목 17 참고).
        188.  
        189. // 그렇지만 ThreadRAII 객체의 이동을 지원하지
        190. // 않을 이유는 없다.
        191.  
        192. // 컴파일러가 만들어주는 기본 이동 연산들로도
        193. // 충분하므로 "=default" 구문을 사용하면
        194. // 된다.
        195.  
        196.  
        197. //-----------------------------------------------------------------------------
        198. // 다음은 doWork 예제에 ThreadRAII를
        199. // 적용한 코드이다.
        200.  
        201. bool doWork(std::function<bool(int)> filter, // 이전과 동일
        202. int maxVal = tenMillion)
        203. {
        204. std::vector<int> goodVals; // 이전과 동일
        206. ThreadRAII t( // RAII 객체를 사용
        207. std::thread([&filter, maxVal, &goodVals]
        208. {
        209. for (auto i = 0; i <= maxVal; ++i)
        210. { if (filter(i)) goodVals.push_back(i); }
        211. }),
        212. ThreadRAII::DtorAction::join // RAII 동작
        213. );
        215. auto nh = t.get().native_handle();
        216. ...
        218. if (conditionAreSatisfied()) {
        219. t.get().join();
        220. performComputation(goodVals);
        221. return true;
        222. }
        224. return false;
        225. }
        226.  
        227. // 이 예에서는 join을 호출하도록 했는데
        228. // 나중에 나오겠지만, 이 상황에서는 detach보다
        229. // join을 사용하는 것이 그나마 낫기
        230. // 때문이다.
        231.  
        232. // join은 성능 이상을 유발할 수 있고,
        233. // detach는 미정의 동작과 프로그램 종료를
        234. // 유발할 수 있다.
        235.  
        236. // 성능 이상이 그나마 나은 선택이다.
        237.  
        238. // 하지만 join을 사용하더라도, 예제의 람다
        239. // 함수가 예외를 던지면 프로그램이 종료될 수
        240. // 있다.
        241.  
        242. // 게다가 join이 실행되게 하면 프로그램이
        243. // 멈추는(무한 루프와 같은) 문제까지 발생할
        244. // 수 있다.
        245.  
        246. // 이런 종류의 문제(프로그램이 멈추는)에 대한
        247. // '제대로 된' 해결책은 비동기적으로 실행되는
        248. // 람다에게 이제 더 일할 필요가 없으니 일찍
        249. // 반환하라고 알려 주는 것이다.
        250.  
        251. // C++11은 그런 interruptible thread
        252. // 를 지원하지 않기 때문에 직접 구현해야 한다.

        
        
        예제 코드 접기
        
        
        

      • 소멸 시 join 방식은 디버깅하기 어려운 성능 이상으로 이어질 수 있다.

        std::thread의 소멸자가 할 수 있는 두 옵션 중 하나는, 소멸자에서 암묵적으로 join을 호출하는 것이다. 즉, std::thread의 소멸자가 바탕 비동기 실행 스레드의 완료를 기다리게 하는 것이다.
        
        합리적으로 보일 수 있으나, 실제로는 추적하기 어려운 성능 이상(performance anomaly)들이 나타날 수 있다. 예를 들어 conditionAreSatisfied()가 이미 false를 돌려주었는데도 모든 값이 필터가 적용되길 doWork가 기다리는 것은 직관적이지 않다.

      • 소멸 시 detach 방식은 디버깅하기 어려운 미정의 행동으로 이어질 수 있다.

        std::thread의 소멸자가 할 수 있는 두 옵션 중 다른 하나는, 소멸자에서 암묵적으로 detach를 호출하는 것이다. 즉, std::thread의 소멸자가 std::thread 객체와 바탕 실행 스레드 사이의 연결을 끊게 하는 것이다. 이 경우 바탕 스레드가 실행을 계속할 수 있다.
        
        이 접근방식이 유발하는 디버깅 문제는 join의 경우보다 더 나쁘다. 좀전의 예제 코드를 예로 들어 보자. doWork에서 goodVals는 지역 변수인데, 람다가 참조에 의해 갈무래해서 자신의 본문 안에서 수정한다(push_back 호출을 통해).
        
        람다가 비동기적으로 실행되는 도중에 conditionAreSatisfied()가 false를 돌려주었다고 하자. 그러면 doWork가 반환되며, 따라서 지역 변수들(goodVals도 포함)이 파괴된다.
        
        이제 doWork의 스택 프레임이 뽑혀서(pop) 실행의 흐름이 doWork의 호출 지점으로 넘어가겠지만, 해당 스레드는 doWork의 호출 지점에서 계속 실행된다.
        
        호출 지점 다음에 f라는 함수를 호출하는 문장이 있다고 하자. 이 f는 doWork의 스택 프레임이 차지하던 메모리의 일부 또는 전부를 사용할 수 있다. 이런 f가 호출된 상황에서도 doWork에서 시작된 람다가 계속 실행될 수도 있다.
        
        f의 관점에서 이는 자신의 스택 프레임에 있는 메모리의 내용이 갑지기 변하는 기현상이 일어난다. 이런 기현상을 디버깅하는 게 얼마나 재미있는 일인지 상상해 보기 바란다.

      • 데이터 멤버 목록에서 std::thread 객체를 마지막에 선언하라.

        앞 예제의 ThreadRAII에서 std::thread 멤버가 마지막으로 선언되어 있음을 볼 수 있다. 이 클래스에서는 선언 순서가 중요하지 않지만, 일반적으로는 한 데이터 멤버의 초기화가 다른 멤버에 의존할 수 있다.
        
        그리고 std::thread 객체는 초기화되자마자 해당 함수를 실행할 수도 있으므로, 클래스에서 std::thread 데이터 멤버는 항상 제일 마지막에 선언하는 것이 좋다.
        
        이처럼 std::thread를 다른 모든 멤버가 성공적으로 초기화된 후에 초기화하면, 해당 비동기 스레드가 다른 모든 멤버에 안전하게 접근할 수 있다.

  38. 스레드 핸들 소멸자들의 다양한 행동 방식을 주의하라 / 278

      join 가능 std::thread를 파괴하면 프로그램이 종료되며, 그 이유를 항목 37에서 설명했다.
      
      그렇지만 future 객체의 소멸자는 어떨 때에는 암묵적으로 join을 수행한 것 같은 결과를 내고 어떨 때에는 암묵적으로 detach를 수행한 것 같은 결과를 낸다. 그렇다고 프로그램이 종료되는 일은 없다.
      
      우선, future 객체는 피호출자가 결과를 호출자에게 전송하는 통신 채널의 한쪽 끝이라는 점을 주목하기 바란다. 피호출자는 자신의 계산 결과를 그 통신 채널에 기록한다(보통은 std::promise 객체를 통해서). 그리고 호출자는 future 객체를 이용해서 그 결과를 읽는다.
      
      그런데 피호출자의 결과는 어디에 저장될까? 호출자가 해당 future 객체에 대해 get을 호출하기 전에 피호출자의 실행이 끝날 수도 있으므로, 결과를 피호출자의 std::promise에 저장할 수는 없다. std::promise 객체는 피호출자의 지역 범위에 있으므로, 피호출자가 완료되면 함께 파괴되기 때문이다.
      
      결과를 호출자의 future 객체에 저장할 수도 없다. 왜냐하면 해당 std::future를 이용해서 std::shared_future를 생성할 수도 있으며, 원본 std::future가 파괴된 후에도 std::shared_future를 여러 번 복사할 수 있기 때문이다.
      
      복사를 지원하지 않는 결과 타입이 있을 수 있다고 할 때, 그리고 결과의 수명이 적어도 그것을 참조하는 마지막 future 객체만큼은 유지된다고 할 때, 피호출자에 대응되는 잠재적으로 다수의 future 객체 중 어떤 것에 피호출자의 결과를 담아야 할지 결정하기가 마땅치 않다.
      
      따라서 호출자에도, 피호출자에도 연관되지 않은 장소에 결과를 담아야 한다. 그 장소가 바로 공유된 상태(shared state), 줄여서 공유 상태이다.
      
      이러한 공유 상태의 존재가 중요한 것은, future 객체 소멸자의 행동을 그 future 객체와 연관된 공유 상태가 결정하기 때문이다.
      
      

      • future 객체의 소멸자는 그냥 future 객체의 데이터 멤버들을 파괴할 뿐이다.

        비동기적으로 실행되고 있는 task의 경우 이는 바탕 스레드에 암묵적 detach를 수행하는 것과 비슷하다. 지연된 task를 참조하는 마지막 future 객체의 경우 이는 그 지연된 task가 절대로 실행되지 않음을 뜻한다.
        
        이는 "정상" 행동에 해당하며 정상 행동은, future 객체의 소멸자가 future 객체를 파괴한다는 것이다. 소멸자는 바탕 스레드를 그 무엇과도 join시키지 않으며, 그 무엇으로부터도 탈착(detach)하지 않으며, 그 무엇도 실행하지 않는다. 그냥 future 객체의 데이터 멤버들을 파괴하고 공유 상태 안의 참조 카운트를 감소한다.

      • std::async를 통해 시동(launch)된 비지연 task에 대한 공유 상태를 참조하는 마지막 future 객체의 소멸자는 그 task가 완료될 때까지 차단(blocking)된다.

        본질적으로, 그런 future 객체의 소멸자는 task가 비동기적으로 실행되고 있는 스레드에 대해 암묵적인 join을 수행한다.
        
        "정상" 행동에 대한 예외는 다음 조건들을 모두 만족하는 future 객체에 대해서만 일어난다.
        
        
        • future 객체가 std::async 호출에 의해 생성된 공유 상태를 참조한다.
        • task의 시동 방침(launch policy)이 std::launch::async이다(항목 36 참고). 여기에는 그 방침(policy)을 실행시점 시스템이 선택한 경우와 std::async 호출 시 명시적으로 지정한 경우 모두가 포함된다.
        • future 객체가 공유 상태를 참조하는 마지막 future 객체이다. std::future의 경우에는 이 조건이 항상 성립한다. std::shared_future의 경우, future 객체가 파괴되는 동안 같은 공유 상태를 다른 std::shared_future가 참조하고 있다면, 파괴되는 future 객체는 정상 행동을 따른다(즉, 그냥 데이터 멤버들만 파괴된다).
        
        
        이 모든 조건이 성립할 때에만 future 객체의 소멸자는 특별한 행동을 보이는데, 그 행동이란 비동기적으로 실행되는 task가 완료될 때까지 소멸자의 실행이 차단(blocking)되는 것이다.
        
        표준 위원회는 암묵적 detach와 관련된 문제들(항목 37 참고)을 피하려 했으나, 필수적인 프로그램 종료(join 가능 std::thread에 적용된 - 역시 항목 37을 보라)라는 급진적인 방침을 채용하는 것도 꺼렸다. 그래서 위원회는 암묵적 join이라는 타협안을 선택했다.
        
        future 객체에 대한 API는 주어진 future 객체가 std::async 호출에 의해 생긴 공유 상태를 참조하는지를 판단할 수 있는 수단을 제공하지 않으므로, 임의의 future 객체에 대해 그 소멸자가 비동기적으로 실행되는 task의 완료를 기다리느라 차단(blocking)될 것인지를 알아내는 것은 불가능하다.
        
        이로부터 몇 가지 흥미로운 결과가 빚어진다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 이 컨테이너는 소멸자에서 차단(blocking)될 수도 있다; 컨테이너에 담긴
        3. // 하나 이상의 future 객체들이 std::async를 통해 시동(launch)된 비지연 task에
        4. // 대한 공유 상태를 참조할 수도 있기 때문이다.
        5. std::vector<std::future<void> > futs; // std::future<void>는
        6. // 항목 39를 보라
        7.  
        8. class Widget { // Widget 객체의 소멸자가
        9. public: // 차단(blocking)될 수도 있다.
        11. ...
        13. private:
        14. std::shared_future<double> fut;
        15. };
        16.  
        17.  
        18. //-----------------------------------------------------------------------------
        19. // 물론, 주어진 future 객체가 특별한 소멸자 행동을
        20. // 유발하는 조건들을 만족하지 않음을 미리 알 수
        21. // 있다면, future 객체의 소멸자가 차단(blocking)되는 일은
        22. // 없을 것임을 확신할 수 있다.
        23.  
        24. // 예를 들어, 소멸자의 특별한 행동은 공유 상태가
        25. // std::async 호출에서 비롯된 경우에만 일어날 수 있다.
        26.  
        27. // 그러나 그 외의 여러 원인으로도 공유 상태가
        28. // 생성될 수 있다.
        29.  
        30. // 그중 하나가 std::package_task의 사용이다.
        31.  
        32. // std::package_task 객체는 주어진 함수 또는
        33. // 호출 가능 객체를 비동기적으로 실행할 수
        34. // 있도록 '포장'하는데, 포장된 함수의 실행
        35. // 결과는 공유 상태에 저장된다.
        36.  
        37. // 그 공유 상태를 참조하는 future 객체를 얻으려면
        38. // 다음처럼 std::package_task의 get_future
        39. // 함수를 호출하면 된다.
        40.  
        41. int calcValue(void); // 실행할 함수
        42.  
        43. std::package_task<int(void)> // 비동기적 실행을 위해
        44. pt(calcValue); // calcValue를 포장한다.
        45.  
        46. auto fut = pt.get_future(); // pt에 대한 future 객체를 얻는다.
        47.  
        48. // 이 경우에는 future 객체 fut가 std::async
        49. // 호출로 만들어진 공유 상태를 참조하지
        50. // 않음이 명확하므로, 해당 소멸자는
        51. // 정상적으로 행동한다.
        52.  
        53. // 성공적으로 생성한 std::package_task 객체는
        54. // 임의의 std::thread에서 실행할 수 있다.
        55.  
        56. // std::package_task 객체는 복사할 수 없으므로,
        57. // pt를 std::thread 생성자에 넘겨줄 때에는
        58. // 반드시 우측값으로 캐스팅해야 한다.
        59.  
        60. std::thread t(std::move(pt)); // pt를 스레드 t에서 실행
        61. // std::move에 관해서는
        62. // 항목 23을 보라
        63.  
        64. // 정리해 보자.
        65.  
        66. { // 블록의 시작
        67. std::package_task<int(void)>
        68. pt(calcValue);
        70. auto fut = pt.get_future();
        71. std::thread t(std::move(pt));
        73. ... // 아래 설명 참고
        75. } // 블록의 끝
        76.  
        77. // "..." 부분에서 괌심을 둘 부분은 t에 대해
        78. // 어떤 일이 일어나는가인데, 크게 세 가지로
        79. // 나눌 수 있다.
        80.  
        81.  
        82. // 1. -------------------------------------------
        83. // t에 아무 일도 일어나지 않는다.
        84.  
        85. // 이 경우, 범위(블록)의 끝에서 t는 join 가능
        86. // 스레드이다. 따라서 프로그램이 종료된다(항목 37 참고).
        87.  
        88.  
        89. // 2. -------------------------------------------
        90. // t에 대해 join을 수행한다.
        91.  
        92. // 애초에 호출 코드에서 join을 수행한다면 fut의
        93. // 소멸자에서는 join을 수행할 필요가 없으며,
        94. // 따라서 차단(blocking)될 이유가 없다.
        95.  
        96.  
        97. // 3. -------------------------------------------
        98. // t에 대해 detach를 수행한다.
        99.  
        100. // 마찬가지로, 애초에 호출 코드에서 detach를
        101. // 수행한다면 fut의 소멸자에서 그것을 수행할
        102. // 필요가 없다.
        103.  
        104.  
        105. // 다른 말로 하면, std::package_task에 의해 만들어진
        106. // 공유 상태를 참조하는 future 객체가 있다면, 소멸자의
        107. // 특별한 행동을 고려한 코드를 작성할 필요가 없다.
        108.  
        109. // 종료와 join, 탈착에 관한 결정은 이미 해당
        110. // std::thread(일반적으로 std::package_task가
        111. // 실행되는)를 조작하는 코드에서 내려지기 때문이다.

        
        
        예제 코드 접기
        
        
        

  39. 일회성(one-shot) 사건 통신에는 void future 객체를 고려하라 / 283

      • 간단한 사건 통신을 수행할 때, 조건 변수 기반 설계에는 여분의 뮤텍스가 필요하고, 검출 task와 반응 task의 진행 순서에 제약이 있으며, 사건이 실제로 발생했는지를 반응 task가 다시 확인해야 한다.

        조건을 검출하는 task를 검출 task(detecting task)라고 부르고 그 조건에 반응하는 task를 반응 task(reacting task)라고 부르기로 할 때, 조건 변수(condition variable, 줄여서 condvar)를 이용한 전략은 간단하다. 반응 task는 하나의 조건 변수를 기다리고, 검출 task는 사건이 발생하면 그 조건 변수를 통지하면 된다.
        
        조건 변수 기반 설계 예제 코드 보기
        
        
        

        1. // 다음과 같은 객체들이 있다고 할 때,
        2.  
        3. std::condition_variable cv; // 사건을 위한 조건 변수
        4.  
        5. std::mutex m; // cv와 함께 사용할 뮤텍스
        6.  
        7. // 검출 task 쪽의 코드는 다음처럼 아주
        8. // 간단한 구조이다.
        9.  
        10. ... // 사건을 검출한다.
        11.  
        12. cv.notify_one(); // 반응 task에게 알린다.
        13.  
        14. // 사건 발생을 알려줄 반응 task가 여러 개라면
        15. // notify_one 대신 notify_all을 사용하면
        16. // 된다.
        17.  
        18. // 반응 task의 코드는 이보다 조금 복잡한데,
        19. // 이는 조건 변수에 대해 wait를 호출하기
        20. // 전에 먼저 std::unique_lock 객체를 통해서
        21. // 뮤텍스를 잠가야 하기 때문이다.
        22.  
        23. // 다음은 개념적인 접근방식이다.
        24.  
        25. ... // 반응 준비
        26.  
        27. { // 임계 영역을 연다.
        29. std::unique_lock<std::mutex> lk(m); // 뮤텍스를 잠근다.
        31. cv.wait(lk); // 통지를 기다린다.
        32. // 제대로 된 방식이 아님!
        34. ... // 사건에 반응한다
        35. // (m이 잠긴 상태임).
        36.  
        37. } // 임계 영역을 닫는다;
        38. // lk의 소멸자가 m을 해제한다.
        39.  
        40. ... // 계속 반응한다
        41. // (m은 이제 풀린 상태임).
        42.  
        43. // 뮤텍스는 공유 데이터에 대한 접근을 제어하는 데
        44. // 쓰이나, 검출 task와 반응 task에는 그런 접근
        45. // 제어가 전혀 필요 없을 수도 있다.
        46.  
        47. // 예를 들어 검출 task가 어떤 전역 자료구조의
        48. // 초기화를 수행한 후 반응 task에 넘겨주어서
        49. // 반응 task가 그 자료구조를 처리한다고 하자.
        50.  
        51. // 만일 검출 task가 초기화 과정에서만 자료구조에
        52. // 접근하고 그 후에는 전혀 접근하지 않는다면,
        53. // 그리고 반응 task가 초기화 이후에만 자료구조에
        54. // 접근하고 그 전에는 전혀 접근하지 않는다면,
        55. // 두 task가 서로 마주치는 일이 없다.
        56. // 따라서 뮤텍스는 필요하지 않다.
        57.  
        58. // 조건 변수 접근방식에 뮤테스가 필요하다는 점은
        59. // 설계에 뭔가 문제가 있음을 암시한다.
        60.  
        61. // 그 외에도 처리해야 할 문제점이 두 가지 더 있다.
        62.  
        63.  
        64. // 1. -------------------------------------------
        65. // 만일 반응 task가 wait를 실행하기 전에
        66. // 검출 task가 조건 변수를 통지하면 반응 task가
        67. // 멈추게 된다(hang).
        68.  
        69. // 반응 task가 wait를 실행하기 전에 검출 task가
        70. // 통지를 실행하면 반응 task는 그 통지를 놓치게
        71. // 되며, 그러면 영원히 통지를 기다리게 된다.
        72.  
        73. // 2. -------------------------------------------
        74. // wait 호출문은 가짜 wakeup을 고려하지 않는다.
        75.  
        76. // 조건 변수를 기다리는 코드가 조건 변수가 통지되지
        77. // 않았는데도 깨어날 수 있다는 것은 C++ 이외의
        78. // 다른 여러 언어들에서도 흔히 있는 일이다.
        79.  
        80. // 그런 일을 가짜 wakeup(spurious wakeup)이라고 부른다.
        81.  
        82. // 가짜 wakeup 문제를 제대로 처리하려면, 기다리던
        83. // 조건이 정말로 발생했는지 확인해야 하며, 깨어난
        84. // 후 가장 먼저 하는 일이 바로 그러한 확인이어야
        85. // 한다.
        86.  
        87. // C++의 조건 변수 API에서는, 기다리던 조건을
        88. // 판정하는 람다 또는 기타 함수 객체를 wait에
        89. // 넘겨서 간단하게 구현 가능하다.
        90.  
        91. cv.wait(lk,
        92. []{ return 사건 발생 여부; });
        93.  
        94. // 이러한 능력을 활용하려면, 자신이 기다리던 조건이
        95. // 정말로 참인지를 반응 task가 판단할 수 있어야
        96. // 하는데, 이게 가능했으면 애초에 검출 task의
        97. // 신호를 기다리도록 만들 필요가 없다.

        
        
        조건 변수 기반 설계 예제 코드 접기
        
        
        

      • 플래그 기반 설계를 사용하면 그런 단점들이 없지만, 대신 차단(blocking)이 아니라 폴링이 일어난다는 단점이 있다.

        플래그 기반 설계 예제 코드 보기
        
        
        

        1. // 우선 부울 플래그 하나를 false로
        2. // 초기화해 둔다.
        3.  
        4. // 검출 스레드는 사건 발생을 검출하면
        5. // 그 플래그를 설정한다.
        6.  
        7. std::atomic<bool> flag(false); // 공유 플래그; std::atomic은
        8. // 항목 40을 보라
        9.  
        10. ... // 사건을 검출한다.
        11. flag = true; // 반응 task에게 통지한다.
        12.  
        13. // 반응 스레드에서는 그냥 이 부울 플래그를
        14. // 폴링(polling; 주기적 점검)한다.
        15.  
        16. ... // 받을 준비
        17.  
        18. while (!flag); // 사건을 기다린다.
        19.  
        20. ... // 사건에 반응한다.
        21.  
        22. // 이러한 접근방식에는 조건 변수 기반 설계의
        23. // 단점들이 전혀 없지만, 폴링 비용이 이 장점을
        24. // 깎아 먹는다.

        
        
        플래그 기반 설계 예제 코드 접기
        
        
        

      • 조건 변수와 플래그를 조합할 수도 있으나, 그런 조합을 이용한 통신 메커니즘은 필요 이상으로 복잡하다.

        조건 변수와 플래그 조합 예제 코드 보기
        
        
        

        1. // 조건 변수 기반 설계와 플래그 기반 설계를
        2. // 결합하는 것도 흔하다.
        3.  
        4. // 즉, 사건 발생 여부를 플래그로 나타내되,
        5. // 그 플래그에 대한 접근을 뮤텍스로 동기화하는
        6. // 것이다.
        7.  
        8. // 이 경우 플래그에 대한 동시 접근을 뮤텍스로
        9. // 방지하므로, 플래그를 std::atomic으로 둘
        10. // 필요는 없다.
        11.  
        12. std::condition_variable cv; // 이전과 동일
        13. std::mutex m;
        14.  
        15. bool flag(false); // std::atomic이 아님
        16.  
        17. ...
        18.  
        19. {
        20. std::lock_guard<std::mutex> g(m); // g의 생성자에서 m을 잠근다.
        22. flag = true; // 반응 task에게 통지한다
        23. // (제1부).
        24.  
        25. } // g의 소멸자에서 m을 푼다.
        26. cv.notify_one(); // 반응 task에게 통지한다
        27. // (제2부).
        28.  
        29. // 그리고 반응 task는 다음과 같다.
        30.  
        31. ... // 반응 준비
        32.  
        33. { // 이전과 동일
        34. std::unique_lock<std::mutex> lk(m); // 이전과 동일
        36. cv.wait(lk, [] { return flag; }); // 가짜 wakeup을 방지하기
        37. // 위해 람다를 사용한다.
        39. ... // 사건에 반응한다
        40. // (m은 잠긴 상태).
        41. }
        42.  
        43. ... // 계속 반응한다
        44. // (m은 이제 풀린 상태).
        45.  
        46. // 이 방식이 잘 작동하긴 하지만 아주
        47. // 깔끔하다고는 할 수 없다.

        
        
        조건 변수와 플래그 조합 예제 코드 접기
        
        
        

      • std::promise와 future 객체를 사용하면 이러한 문제점들을 피할 수 있지만, 그런 접근방식은 공유 상태에 힙 메모리를 사용하며, 일회성 통신만 가능하다.

        void future 객체 예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 검출 task에는 std::promise 객체를 하나 두고,
        3. // 반응 task에는 그에 대응되는 future 객체를 하나 둔다.
        4.  
        5. // 기다리던 사건이 발생했음을 인식하면 검출 task는
        6. // 자신의 std::promise를 설정한다.
        7.  
        8. // 그동안 반응 task는 자신의 future 객체에 대해
        9. // wait를 호출해 둔 상태이다.
        10.  
        11. // wait 호출은 std::promise가 설정될
        12. // 때까지 차단(blocking)된다.
        13.  
        14. // 그런데 std::promise와 future 모두 타입
        15. // 매개변수를 요구하는 템플릿이다.
        16.  
        17. // 그 타입 매개변수는 통신 채널을 통해 전송할
        18. // 데이터의 타입을 뜻한다.
        19.  
        20. // 그러나 지금 예에서는 딱히 전송할 데이터가 없으므로
        21. // void를 타입으로 지정하면 된다.
        22.  
        23. // 정리하자면, 다음과 같은 약속 객체가 있을 때
        24.  
        25. std::promise<void> p; // 통신 채널에서 사용할
        26. // 약속 객체
        27.  
        28. // 검출 task의 코드는 아주 간단하다.
        29.  
        30. ... // 사건을 검출한다.
        31.  
        32. p.set_value(); // 반응 task에게 통지한다.
        33.  
        34. // 반응 task의 코드 역시 그만큼이나 간단하다.
        35.  
        36. ... // 반응 준비
        37.  
        38. p.get_future().wait(); // p에 해당하는 future 객체를
        39. // 기다린다.
        40.  
        41. ... // 사건에 반응한다.
        42.  
        43. // 이 설계에는 뮤텍스가 필요하지 않으며,
        44. // 반응 task가 wait로 대기하기 전에 검출
        45. // task가 자신의 std::promise를 설정해도
        46. // 작동하며, 가짜 wakeup도 없다(가짜 wakeup
        47. // 문제는 조건 변수에서만 일어난다).
        48.  
        49. // 그리고 조건 변수 기반 접근방식에서처럼
        50. // 반응 task는 wait 호출 후 진정으로
        51. // 차단(blocking)되므로 기다리는 동안 시스템 자원을
        52. // 전혀 소모하지 않는다.
        53.  
        54. // 단점이 없는 것은 아니다. 예를 들어
        55. // 항목 38에서 설명하듯이 std::promise와
        56. // future 객체 사이에는 공유 상태가 있으며,
        57. // 대체로 공유 상태는 동적으로 할당된다.
        58.  
        59. // 따라서 이 설계는 힙 기반 할당 및 해제
        60. // 비용을 유발한다고 가정해야 한다.
        61.  
        62. // 더 중요한 것은, std::promise와 future 객체
        63. // 사이의 통신 채널은 여러번 되풀이해서 사용할
        64. // 수 없는 일회성 메커니즘이라는 것이다.
        65.  
        66.  
        67. //-----------------------------------------------------------------------------
        68. // 스레드를 한 번만 정지한다면(생성 시점과
        69. // 해당 스레드 함수의 실행시점 사이에서),
        70. // void future 객체를 이용하는 설계가
        71. // 합리적인 선택이다.
        72.  
        73. std::promise<void> p;
        74.  
        75. void react(void); // 반응 task에 해당하는 함수
        76.  
        77. void detect(void) // 검출 task에 해당하는 함수
        78. {
        79. std::thread t([] // 스레드를 생성한다.
        80. {
        81. p.get_future().wait(); // future 객체가 설정될
        82. react(); // 때까지 t를 정지
        83. });
        84.  
        85. ... // 여기서 t는 정지된 상태임;
        86. // react는 그다음에 호출됨
        88. p.set_value(); // t의 정지를 푼다(그러면
        89. // react를 호출한다).
        91. ... // 추가 작업을 수행
        93. t.join(); // t를 join 불가능으로
        94. } // 만든다(항목 37 참고).
        95.  
        96. // detect 바깥의 모든 경로에서 t를 join 불가능으로
        97. // 만드는 것이 중요하므로, 항목 37의 ThreadRAII
        98. // 같은 RAII 클래스를 사용하는 것이 바람직하다.
        99.  
        100. void detect(void)
        101. {
        102. ThreadRAII tr ( // RAII 객체를 사용
        103. std::thread([]
        104. {
        105. p.get_future().wait();
        106. react();
        107. }),
        108. ThreadRAII::DtorAction::join // 위험함!(설명 참고)
        109. );
        111. ... // 여기서 tr 내부의
        112. // 스레드는 정지된 상태임
        114. p.set_value(); // tr 내부 스레드의
        115. // 정지를 푼다.
        117. ...
        118. }
        119.  
        120. // 이전보다는 안전하지만, 만일 첫 "..." 부분
        121. // ("여기서 tr 내부의 스레드는 정지된 상태임"
        122. // 주석이 있는 부분)에서 예외가 발생하면 p에 대한
        123. // set_value 호출이 일어나지 않으며, 따라서
        124. // 람다 안의 wait 호출은 계속해서 차단(blocking)된다.
        125.  
        126. // 즉, 람다를 실행하는 스레드가 결코 완료되지
        127. // 않는다.
        128.  
        129. // 이 문제에 관해서는 저자의 블로그 The View From Aristeia의
        130. // 2013년 12월 24일자 글 "ThreadRAII + Thread Suspension = Trouble?"과
        131. // 후속글 "More on ThreadRAII and Thread Suspension"
        132. // (2015년 4월 8일)도 참고하기 바란다.
        133.  
        134.  
        135. //-----------------------------------------------------------------------------
        136. // 이제 반응 task가 하나가 아니라 여러 개인
        137. // 경우를 생각해 보자.
        138.  
        139. // 핵심은 react 코드에서 std::future 대신
        140. // std::shared_future를 사용하는 것이다.
        141.  
        142. // std::future의 share 멤버 함수가 자신의
        143. // 공유 상태에 대한 소유권을 share가 산출하는
        144. // std::shared_future 객체에 넘겨준다는
        145. // 점만 알면 코드가 거의 저절로 작성될 것이다.
        146.  
        147. // 까다로운 부분은 반응 task 스레드마다 공유 상태를
        148. // 참조하는 개별적인 std::shared_future 복사본을
        149. // 두어야 한다는 점이다.
        150.  
        151. std::promise<void> p; // 이전과 동일
        152.  
        153. void detect(void) // 이제는 여러 개의 반응
        154. { // task에 통지한다.
        155.  
        156. auto sf = p.get_future().share(); // sf의 타입은
        157. // std::shared_future<void>
        159. std::vector<std::thread> vt; // 반응 스레드들을 담는
        160. // 컨테이너
        162. for (int i = 0; i < threadsToRun; ++i) {
        163. vt.emplace_back([sf]{ sf.wait(); // sf의 지역 복사본을
        164. react(); }); // 기다린다.
        165. } // emplace_back은
        166. // 항목 42를 보라
        168. ... // 만일 이 "..."에서 예외가
        169. // 발생하면 join 가능한
        170. // std::thread들이 파괴되어서
        171. // 프로그램이 종료된다!
        173. p.set_value(); // 모든 스레드의 정지를 푼다.
        175. ...
        177. for (auto& t: vt) { // 모든 스레드를 join
        178. t.join(); // 불가능으로 만든다;
        179. } // auto& 구문은
        180. } // 항목 2를 보라
        181.  

        
        
        void future 객체 예제 코드 접기
        
        
        

  40. 동시성에는 std::atomic을 사용하고, volatile은 특별한 메모리에 사용하라 / 292

      • std::atomic은 뮤텍스 보호 없이 여러 스레드가 접근하는 데이터를 위한 것으로, 동시적 소프트웨어의 작성을 위한 도구이다.

        std::atomic 객체가 성공적으로 생성되고 나면, 그 객체에 대한 연산은 마치 뮤텍스로 보호되는 임계 영역(ciritical section) 안에서 수행되는 것처럼 작동한다.
        
        그러나 이러한 원자적 연산은 실제로 뮤텍스를 사용할 때보다 좀 더 효율적인 특별한 기계어 명령들로 구현되는 것이 보통이다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // std::atomic을 사용하는 다음과 같은 예제
        3. // 코드를 생각해 보자.
        4.  
        5. std::atomic<int> ai(0); // ai를 0으로 초기화한다.
        6.  
        7. ai = 10; // 원자적으로 ai를 10으로 설정한다.
        8.  
        9. std::cout << ai; // 원자적으로 ai의 값을 읽는다.
        10.  
        11. ++ai; // 원자적으로 ai를 증가한다(11이 된다).
        12.  
        13. --ai; // 원자적으로 ai를 감소한다(10이 된다).
        14.  
        15. // 이 문장들을 실행하는 동안 ai를 읽는
        16. // 다른 스레드들이 보게 되는 값은 0이나 10,
        17. // 11 뿐이다.
        18.  
        19. // 이 예제에서 주목할 점은 2 가지가 있다.
        20.  
        21. // 첫째로, "std::cout << ai;" 문장에서
        22. // ai가 std::atomic 객체라는 점이 보장하는
        23. // 것은 ai의 읽기가 원자적이라는 것뿐이다.
        24.  
        25. // 전체 문장이 원자적으로 처리된다는 보장은 없다.
        26.  
        27. // ai의 값을 읽는 시점과 ai의 값이 표준 출력에
        28. // 기록되는 시점 사이에 다른 스레드가 ai의 값을
        29. // 수정할 수도 있다.
        30.  
        31. // 그러나, int에 대한 operator<<는 주어진 int
        32. // 인수에 대한 값 전달 매개변수를 출력에 사용하므로,
        33. // 이 문장의 행동에 영향을 주지 않는다.
        34.  
        35. // 둘째로, 이 예제에서 마지막 두 문장의 행동을
        36. // 주목할 필요가 있다.
        37.  
        38. // 증가 연산이나 감소 연산은 읽기-수정-쓰기
        39. // (read-modify-write, RMW) 연산이지만,
        40. // 각각 원자적으로 수행된다.
        41.  
        42. // 이처럼, 일단 std::atomic 객체가 생성되고
        43. // 나면, 그 객체에 대한 모든 멤버 함수는,
        44. // 심지어 RMW 연산들을 수행하는 멤버 함수도,
        45. // 다른 스레드들에게 반드시 원자적으로 보인다.
        46.  
        47.  
        48. //-----------------------------------------------------------------------------
        49. // 그러나, volatile로 선언한다고 해서
        50. // 그 변수가 원자적으로 연산되지 않는다.
        51.  
        52. // 다음 예시를 보자.
        53.  
        54.  
        55. std::atomic<int> ac(0); // "원자적 카운터"
        56.  
        57. volatile int vc(0); // "휘발성(volatile) 카운터"
        58.  
        59. // 그런 다음, 동시에 실행되는 두 스레드에서
        60. // 각 카운터를 한 번씩 증가한다.
        61.  
        62. /*- 스레드 1 -*/ /*- 스레드 2 -*/
        63. ++ac; ++ac;
        64. ++vc; ++vc;
        65.  
        66. // 두 스레드 모두 실행이 끝난 후에 ac의 값은
        67. // 반드시 2 이다.
        68.  
        69. // 증가 연산이 원자적으로 실행되었기 때문이다.
        70.  
        71. // 그러나 vc의 값은 2가 아닐 수도 있다.
        72.  
        73. // 증가 연산은 내부적으로 다음 연산들로 이루어져 있다.
        74.  
        75. // 1. vc의 값을 읽는다.
        76. // 2. 그 값을 증가한다.
        77. // 3. 그 결과를 다시 vc에 기록한다.
        78.  
        79. // 그런데 volatile 객체에 대해서는 이 세 연산이
        80. // 원자적으로 실행된다는 보장이 없다.
        81.  
        82. // 따라서 다음과 같이 실행될 수도 있다.
        83.  
        84. // 1. 스레드 1이 vc의 값을 읽는다. 그 값은 0이다.
        85. // 2. 스레드 2가 vc의 값을 읽는다. 그 값은 여전히 0이다.
        86. // 3. 스레드 1이 자신이 읽은 값 0을 증가하고, 그 결과인 1을 vc에 기록한다.
        87. // 4. 스레드 2가 자신이 읽은 값 0을 증가하고, 그 결과인 1을 vc에 기록한다.
        88.  
        89. // 그 결과 vc는 2가 아니라 1이라는 값을 갖는다.
        90. // 물론 이와 다른 결과가 나올 수도 있다(미정의 행동).
        91.  
        92.  
        93. //-----------------------------------------------------------------------------
        94. // 일반적으로, 서로 무관한 대입들의 순서를
        95. // 컴파일러가 임의로 바꾸는 것은 적법한 일이다.
        96.  
        97. // 예를 들어 다음과 같은 대입들이 있을 때
        98. // (여기서 a와 b, x, y는 각각 독립적인 변수),
        99.  
        100. a = b;
        101. x = y;
        102.  
        103. // 컴파일러가 이들의 순서를 다음과 같이 바꿀 수 있다.
        104.  
        105. x = y;
        106. a = b;
        107.  
        108. // 컴파일러가 문장들의 순서를 바꾸지 않는다고 해도,
        109. // 바탕 하드웨어가 바꿀 수도 있다.
        110.  
        111. // 왜냐하면, 순서를 바꾸면 코드가 더 빨리 실행되는
        112. // 경우가 있기 때문이다.
        113.  
        114. // 그러나 std::atomic을 사용하면 이러한 코드 순서
        115. // 재배치에 대한 제약들이 생긴다.
        116.  
        117. // 그런 제약 중 하나는, 소스 코드에서 std::atomic 변수를
        118. // 기록하는 문장 이전에 나온 그 어떤 코드도 그 문장
        119. // 이후에 실행되지 않아야 한다는 것이다.
        120.  
        121. // 필요한 값이 준비되었음을 첫째 task가 둘째 task에게
        122. // std::atomic<bool>을 이용해서 알려주는 방법 하나를
        123. // 항목 39에서 설명한다.
        124.  
        125. // 첫 task, 즉 값을 계산하는 task의 코드는
        126. // 다음과 같은 형태이다.
        127.  
        128. std::atomic<bool> valAvailable(false);
        129.  
        130. auto imptValue = computeImportantValue(); // 값을 계산한다.
        131.  
        132. valAvailable = true; // 다른 task에게 값이
        133. // 준비되었음을 알린다.
        134.  
        135. // 이 코드를 읽는 우리는 imptValue 대입이 반드시
        136. // valAvailable 대입보다 먼저 일어나야 함을
        137. // 알고 있다.
        138.  
        139. // 하지만, 컴파일러는 두 대입문을 단지 서로 독립적인
        140. // 변수에 대한 두 대입으로 볼 뿐이다.
        141.  
        142. // 이 경우에는, valAvailable가 std::atomic 변수이므로
        143. // 컴파일러는 imptValue와 valAvailable의 대입문들의
        144. // 순서를 그대로 지켜야 할 뿐만 아니라, 바탕 하드웨어
        145. // 역시 그 순서대로 명령들을 실행하게 만들어야 한다.
        146.  
        147. // 만일 valAvailable이 std::atomic이 아니라
        148. // volatile 변수였다면 이러한 제약들이 가해지지
        149. // 않아서, 대입문들의 순서가 바뀔 수 있다.
        150.  
        151. volatile bool valAvailable(false);
        152.  
        153. auto imptValue = computeImportantValue();
        154.  
        155. valAvailable = true; // 다른 스레드들은 이 대입을
        156. // imptValue 대입 이전에 볼 수 있다.
        157.  
        158.  
        159. //-----------------------------------------------------------------------------
        160. // std::atomic의 복사 연산은 삭제되었다.
        161. // 따라서 다음의 코드는 컴파일에 실패한다.
        162.  
        163. std::atomic<int> x;
        164.  
        165. auto y = x; // 컴파일에 실패한다!
        166. y = x; // 마찬가지!
        167.  
        168. // 이유는 다음과 같다.
        169.  
        170. // x를 이용한 y의 복사 생성 연산이 원자적이라면,
        171. // 컴파일러는 x를 읽고 y를 기록하는 작업을 하나의
        172. // 원자적 연산으로 수행하는 코드를 산출해야 한다.
        173.  
        174. // 대체로 그런 원자적 연산을 하드웨어 수준에서
        175. // 지원하지는 않기 때문에, 표준 위원회는 std::atomic
        176. // 타입에 대한 복사 생성을 지원하지 않기로 했다.
        177.  
        178. // 복사 대입 역시 같은 이유로 삭제되었다.
        179.  
        180. // 이동 연산들은 std::atomic에 대해 명시적으로
        181. // 선언되어 있지 않으므로, 항목 17의 설명에 따라
        182. // std::atomic은 이동 생성도, 이동 대입도
        183. // 제공하지 않는다.
        184.  
        185. // 그렇다고 x의 값을 y에 넣는 것이
        186. // 불가능한 것은 아니다.
        187.  
        188. // std::atomic의 멤버 함수 load와
        189. // store를 사용하면 된다. 두 멤버 함수는
        190. // 각각 값을 원자적으로 읽고, 기록하는 함수이다.
        191.  
        192. std::atomic<int> y(x.load()); // x를 읽는다.
        193. y.store(x.load()); // x를 다시 읽는다.
        194.  
        195. // x를 읽는 연산과 그 값으로 y를 초기화하는
        196. // 연산 또는 y에 저장하는 연산이 개별적인
        197. // 함수 호출들이므로, 두 문장이 각자 하나의
        198. // 원자적 연산으로 실행되리라고 기대할 이유가 없다.
        199.  
        200. // 컴파일러가 x의 값을 두 번 읽는 대신
        201. // 첫 번째 읽기에서 얻은 값을 레지스터에
        202. // 저장해서 최적화 할 수도 있다.
        203.  
        204. 레지스터 = x.load(); // x를 레지스터로 읽어 들인다.
        205.  
        206. std::atomic<int> y(레지스터); // y를 레지스터 값으로 초기화한다.
        207.  
        208. y.store(레지스터); // 레지스터 값을 y에 저장한다.
        209.  
        210.  
        211. //-----------------------------------------------------------------------------
        212. // 꼭 필요한 경우가 아니어도 std::atomic의
        213. // load, store 멤버 함수를 사용하는
        214. // 개발자들이 있다.
        215.  
        216. // 그렇게 하면 관련된 변수들이 '보통'의 변수가
        217. // 아니라는 사실이 소스 코드에 명백히 드러난다는
        218. // 이유에서이다.
        219.  
        220. // 예를 들어, std::atomic의 load와 store를
        221. // 호출하면 잠재적인 확장성(scalability)
        222. // 병목 지점들을 식별하는 데 도움이 된다.
        223.  
        224. // 그러나 이는 대체로 스타일상의 문제이다.

        
        
        예제 코드 접기
        
        
        

      • volatile은 읽기와 기록을 최적화로 제거하지 말아야 하는 메모리를 위한 것으로, 특별한 메모리를 다룰 때 필요한 도구이다.

        특별한 메모리 중에서 가장 흔히 접할 수 있는 것은 아마도 메모리 대응 입출력(memory-mapped I/O)에 쓰이는 메모리일 것이다.
        
        그런 메모리에 있는 장소들에 대한 접근은 보통의 메모리를 읽거나 쓰는 것이 아니라, 외부 감지기나 디스플레이, 프린터, 네트워크 포트 같은 주변장치와 실제로 통신한다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // '보통' 메모리에는 메모리의 한 장소에 어떤 값을
        3. // 기록하면 다른 어떤 값을 덮어쓰지 않는 한
        4. // 그 값이 유지된다는 특성이 있다.
        5.  
        6. // 다음을 보자.
        7.  
        8. int x;
        9.  
        10. auto y = x; // x를 읽는다.
        11. y = x; // x를 다시 읽는다.
        12.  
        13. // 이 경우 컴파일러는 둘째 줄, 즉 y에 대한
        14. // 대입문을 제거해서 목적 코드를 최적화할 수 있다.
        15.  
        16. // 둘째 줄은 첫째 줄, 즉 y의 초기화와 정확히
        17. // 같은 일을 하기 때문이다.
        18.  
        19. // 또한 '보통'의 메모리에는, 어떤 메모리 장소에
        20. // 어떤 값을 기록한 후 그 값을 한번도 읽지 않고
        21. // 그 메모리 장소에 값을 다시 기록한다면 첫 번째
        22. // 기록은 제거할 수 있다는 특성이 있다.
        23.  
        24. // 다음을 보자.
        25.  
        26. x = 10; // x를 기록한다.
        27. x = 20; // x를 다시 기록한다.
        28.  
        29. // 컴파일러는 첫 문장을 제거할 수 있다.
        30.  
        31. // 즉, 소스 코드에 다음과 같은 문장이 있을 때,
        32.  
        33. auto y = x; // x를 읽는다.
        34. y = x; // x를 다시 읽는다.
        35. x = 10; // x를 기록한다.
        36. x = 20; // x를 다시 기록한다.
        37.  
        38. // 컴파일러는 이를 다음과 같은 소스 코드로
        39. // 취급할 수 있다.
        40.  
        41. auto y = x; // x를 읽는다.
        42.  
        43. x = 20; // x를 기록한다.
        44.  
        45. // 사람이 이런 코드를 작성할 여지는 적지만,
        46. // 컴파일러가 템플릿 인스턴스화와 인라인화,
        47. // 그리고 다양한 순서 재배치 최적화들을
        48. // 적용하고 나면, 남아도는 적재(redundant loads)와
        49. // 죽은 저장(superfluous writes)들이
        50. // 드물지 않게 생겨난다.
        51.  
        52.  
        53. //-----------------------------------------------------------------------------
        54. // 지금까지 말한 최적화들은 메모리가 '보통'의 방식으로
        55. // 행동할 때에만 유용하다.
        56.  
        57. // 그러나 메모리 대응 입출력에 쓰이는 메모리와 같은
        58. // 경우에는 이런 최적화를 적용할 수 없다.
        59.  
        60. // 남아도는 읽기들로 보이는 코드를 다시 생각해 보자.
        61.  
        62. auto y = x; // x를 읽는다.
        63. y = x; // x를 다시 읽는다.
        64.  
        65. // 만일 x가 이를테면 온도계가 보고하는 값이라면,
        66. // 두 번째 x 읽기는 여분이 아니다.
        67.  
        68. // 첫 번째 읽기와 두 번째 읽기 사이에 온도가
        69. // 변했을 수도 있기 때문이다.
        70.  
        71. // 불필요한 기록들로 보이는 코드도 마찬가지이다.
        72.  
        73. x = 10; // x를 기록한다.
        74. x = 20; // x를 다시 기록한다.
        75.  
        76. // 만일 x가 무선 신호 전송기의 제어 포트에
        77. // 해당한다면, 이 코드는 무선으로 명령을 보내는
        78. // 작업을 하는 것일 수 있으며, 10과 20은
        79. // 각자 다른 명령에 대응될 것이다.
        80.  
        81. // 만일 최적화 때문에 첫 대입문이 제거되면
        82. // 무선으로 전송되는 명령들이 달라진다.
        83.  
        84.  
        85. //-----------------------------------------------------------------------------
        86. // volatile은 해당 코드가 특별한 메모리를 다룬다는
        87. // 점을 컴파일러에게 알려주는 수단이다.
        88.  
        89. // 즉, 컴파일러는 이를 "이 메모리에 대한 연산들에는
        90. // 그 어떤 최적화도 수행하지 말라"는 지시라고 생각한다.
        91.  
        92. // 만일 x가 특별한 메모리에 해당한다면, 다음처럼
        93. // volatile로 선언해야 마땅하다.
        94.  
        95. volatile int x;
        96.  
        97. // 다시 다음의 코드를 보자.
        98.  
        99. auto y = x; // x를 읽는다.
        100. y = x; // x를 다시 읽는다(최적화로 제거할 수 없음).
        101.  
        102. x = 10; // x를 기록한다(최적화로 제거할 수 없음).
        103. x = 20; // x를 다시 기록한다.
        104.  
        105. // 참고로, y는 volatile이 아니다.
        106.  
        107. // 항목 2의 규칙들에 따르면, 비참조·비 포인터 타입을
        108. // 선언할 때에는 const와 volatile 한정사가 제거된다.
        109.  
        110.  
        111. //-----------------------------------------------------------------------------
        112. // 그러나 std::atomic 변수에는 이러한
        113. // 사항들이 적용되지 않는다.
        114.  
        115. // 따라서 다음와 코드는,
        116.  
        117. std::atomic<int> x;
        118.  
        119. auto y = x; // 개념적으로 x를 읽는다.
        120. y = x; // 개념적으로 x를 다시 읽는다.
        121.  
        122. x = 10; // x를 기록한다.
        123. x = 20; // x를 다시 기록한다.
        124.  
        125. // 다음과 같이 최적화될 수 있다.
        126.  
        127. auto y = x; // 개념적으로 x를 읽는다.
        128. x = 20; // x를 기록한다.
        129.  
        130. // 그러나, "개념적으로" 라는 주석이 붙은 문장은
        131. // 컴파일되지 않는다.
        132.  
        133. // std::atomic의 복사 연산들이
        134. // 삭제되었기 때문이다(항목 11 참고).

        
        
        예제 코드 접기
        
        
        

      • std::atomic과 volatile의 용도가 다르므로, 함께 사용하는 것도 가능하다.

        예를 들어 다음과 같은 선언이 있을 때,
        
        volatile std::atomic<int> vai;
        
        vai에 대한 연산들은 원자적이며, 최적화에 의해 제거될 수 없다.

• Chapter 8   다듬기

  41. 이동이 저렴하고 항상 복사되는 복사 가능 매개변수에 대해서는 값 전달을 고려하라 / 303

      • 이동이 저렴하고 항상 복사되는 복사 가능 매개변수에 대해서는 값 전달이 참조 전달만큼이나 효율적이고, 구현하기가 더 쉽고, 산출되는 목적 코드의 크기도 더 작다.

        예제 코드 보기
        
        
        

        1. // 함수 매개변수 중에는 애초에 복사되도록
        2. // 만들어진 것들이 있다.
        3.  
        4. // 예를 들어 다음 예제 코드의 멤버 함수 addName
        5. // 은 자신의 매개변수를 비공개 데이터 멤버 컨테이너에
        6. // 저장한다.
        7.  
        8. // 효율성을 위해서는, 이런 멤버 함수가 좌측값 인수는
        9. // 복사하되 우측값 인수는 이동하는 것이 바람직하다.
        10.  
        11. class Widget {
        12. public:
        13. void addName(const std::string& newName) // 좌측값을 받아서
        14. { names.push_back(newName); } // 복사한다.
        16. void addName(std::string&& newName) // 우측값을 받아서
        17. { names.push_back(std::move(newName)); } // 이동한다;
        18. ... // std::move의 용법은
        19. // 항목 25를 보라
        20. private:
        21. std::vector<std::string> names;
        22. };
        23.  
        24. // 이런 코드가 작동하긴 하지만, 본질적으로
        25. // 같은 일을 하는 함수를 두 개 작성해야
        26. // 한다.
        27.  
        28. // 한 가지 대안은 보편 참조(universal reference)(항목 24 참고)를
        29. // 받는 함수 템플릿으로 만드는 것이다.
        30.  
        31. class Widget {
        32. public:
        33. template <typename T> // 좌측값과 우측값을
        34. void addName(T&& newName) // 모두 받는다;
        35. { // 좌측값은 복사하고
        36. names.push_back(std::forward<T>(newName)); // 우측값은 이동한다;
        37. } // std::forward의
        38. // 용법은 항목 25를
        39. ... // 보라
        41. };
        42.  
        43. // 이렇게 하면 다루어야 할 소스 코드가 줄어들지만,
        44. // 보편 참조(universal reference)와 관련된 여러 문제점들이 발생할 수 있다.
        45.  
        46. // addName 같은 함수가 좌측값은 복사하고 우측값은
        47. // 이동하게 만들 수 있다면, 그러면서도 함수 하나만
        48. // (소스 코드와 목적 코드 모두) 다룰 수 있다면,
        49. // 게다가 보편 참조(universal reference)의 여러 골칫거리도 피할 수 있다면
        50. // 아주 좋을 것이다.
        51.  
        52. // 이럴 때 값 전달을 사용하면 된다.
        53.  
        54. class Widget {
        55. public:
        56. void addName(std::string newName) // 좌측값이나 우측값을
        57. { names.push_back(std::move(newName)); } // 받아서 이동한다.
        59. ...
        61. };
        62.  
        63. // 값 전달 매개변수는 좌측값 인수에 대해서는 복사 생성자를 통해 복사
        64. // 생성되고, 우측값 인수에 대해서는 이동 생성자를 통해 이동 생성된다.
        65.  
        66. Widget w;
        67.  
        68. ...
        69.  
        70. std::string name("Bart");
        71.  
        72. w.addName(name); // addName을 좌측값으로 호출
        73.  
        74. ...
        75.  
        76. w.addName(name + "Jenne"); // addName을 우측값으로 호출
        77.  
        78. // 첫 addName 호출에서 매개변수 newName은
        79. // 좌측값으로 초기화된다. 따라서 C++98에서처럼
        80. // 복사 생성된다.
        81.  
        82. // 둘째 호출에서 newName은 std::string에 대한
        83. // operator+ 호출로부터 생성되는 std::string
        84. // 객체로 초기화된다.
        85.  
        86. // 그 객체는 우측값이므로 이동 생성된다.

        
        
        예제 코드 접기
        
        
        매개변수를 값으로 전달 받는 방법을 사용할 때 염두해 둘 주의사항이 몇 가지 있다. 예제 코드의 멤버 함수 addName 구현의 세 가지 방식(좌측값을 받는 버전과 우측값을 받는 버전의 오버로딩, 보편 참조(universal reference)를 받는 버전, 값으로 전달받는 버전)에는 다음과 같은 비용이 든다.
        
        
        • 오버로딩 구현의 경우: 호출자가 넘겨준 인수가 좌측값이든 우측값이든, 그 인수는 newName이라는 참조에 묶인다. 복사, 이동 연산을 기준으로 한 비용은 없다. 함수 본문에서는, 좌측값 오버로딩에서는 newName이 Widget::names로 복사되고 우측값 오버로딩에서는 이동된다.
          
          비용 정리: 좌측값의 경우 복사 1회, 우측값의 경우 이동 1회
        • 보편 참조(universal reference)를 이용한 구현의 경우: 오버로딩 구현에서처럼 호출자의 인수는 참조 newName에 묶인다. 이는 비용이 없는 연산이다. 함수 본문에서는, std::forward 때문에 좌측값 std::string 인수는 Widget::names에 복사되고 우측값 std::string 인수는 이동된다.
          
          항목 25에서 설명하듯이, 인수가 std::string이 아닌 타입이면 그 인수는 std::string 생성자로 전달되며, 그러면 std::string의 복사 또는 이동이 0회 이상 일어날 수 있다. 그러나 지금의 논의와는 큰 상관이 없으므로 지금은 인수가 항상 std::string 타입이라고 가정한다.
          
          비용 정리: 좌측값의 경우 복사 1회, 우측값의 경우 이동 1회
        • 값 전달을 이용한 구현의 경우: 호출자가 넘겨준 인수가 좌측값이든 우측값이든 매개변수 newName이 반드시 생성된다. 인수가 좌측값이면 비용은 복사 생성 1회이고 우측값이면 이동 생성 1회이다. 함수 본문에서는, 어떤 경우이든 newName이 항상 Widget::names로 이동된다.
          
          비용 정리: 좌측값의 경우 복사 1회 + 이동 1회, 우측값의 경우 이동 2회
        
        
        즉, 값 전달 방식의 매개변수를 사용하면 어떤 경우이든 이동이 1회씩 더 일어난다.
        
        구체적으로 다음 네 가지 사항에 주목하기 바란다.
        
        
        1. 값 전달을 "사용하라"가 아니고 고려하라일 뿐이다. 값 전달 방식에는 함수를 하나만 작성하면 된다는 장점과 목적 코드에 함수 하나만 만들어진다는 장점, 그리고 보편 참조(universal reference)와 관련된 문제점이 없다는 장점이 있는 것이 사실이다. 그렇지만 다른 대안들보다 비용이 크며, 잠시 후에 보겠지만 아직 이야기하지 않은 비용이 추가되는 경우도 있다.
        2. 복사 가능 매개변수에 대해서만 값 전달을 고려해야 한다. 복사할 수 없는 매개변수는 반드시 이동 전용 타입일 것이다(이를테면 std::unique_ptr). 값 전달 방식의 장점은 함수를 하나만 작성하면 되는 것인데 어차피 이동 연산만 있다면 우측값에 대한 버전만 작성하면 된다. 게다가 참조로 전달하면 이동을 1회만 하면 되지만, 값으로 전달하면 이동이 2회 일어난다.
        3. 값 전달은 이동이 저렴한 매개변수에 대해서만 고려해야 한다. 이동이 저렴한 경우에는 이동이 한 번 더 일어난다고 해도 큰 문제가 되지 않는다. 그러나 이동의 비용이 크다면, 불필요한 이동을 수행하는 것은 불필요한 복사를 수행하는 것과 비슷하다.
        4. 값 전달은 항상 복사되는 매개변수에 대해서만 고려해야 한다. 만일 매개변수를 항상 복사하는 것이 아니라, 매개변수가 어떤 조건을 만족하는 경우에만 복사하고, 그렇지 않은 경우에는 아무런 일도 하지 않는 함수가 있다고 하자. 이 함수의 매개변수를 참조로 받으면, 조건을 만족하는 매개변수를 받았을 때에는 복사가 일어나고 그렇지 않은 매개변수를 받았을 때에는 복사가 일어나지 않는다. 그러나 이 함수의 매개변수를 값으로 받으면, 어떤 경우에도 복사가 일어난다.

      • 좌측값 인수의 경우 값 전달(즉, 복사 생성) 다음의 이동 대입은 참조 전달 다음의 복사 대입보다 훨씬 비쌀 가능성이 있다.

        이동이 저렴한 복사 가능 타입에 대해 항상 복사를 수행하는 함수라고 해도 값 전달이 적합하지 않은 경우가 종종 있다. 이는 함수가 매개변수를 복사하는 방식이 두 가지이기 때문이다.
        
        하나는 생성을 통한 복사(복사 생성이나 이동 생성)이고 또 하나는 대입을 통한 복사(복사 대입이나 이동 대입)이다.
        
        생성을 통해서 매개변수를 복사하는 함수의 비용은 앞에서 분석한 그대로이다(값 전달 사용시 추가적인 이동이 1회 일어남). 그러나 매개변수를 대입을 통해서 복사하는 함수에서는 추가적으로 고려해야 할 사항이 있다. 자세한 것은 다음 예제 코드를 참고하기 바란다.
        
        예제 코드 보기
        
        
        

        1. // 패스워드를 나타내는 클래스가 있다고 하자.
        2.  
        3. // 패스워드는 바뀔 수 있으므로, changeTo라는
        4. // 설정 함수를 제공하기로 한다.
        5.  
        6. class Password {
        7. public:
        8. explicit Password(std::string pwd) // 값 전달
        9. : text(std::move(pwd)) {} // text를 생성한다.
        11. void changeTo(std::string newPwd) // 값 전달
        12. { text = std::move(newPwd); } // text에 대입한다.
        14. ...
        16. private:
        17. std::string text;
        18. };
        19.  
        20. // 패스워드를 평문으로 저장하는 문제는 무시하고
        21. // 다음 코드를 보자.
        22.  
        23. std::string initPwd("Supercalifragilisticexpialidocious");
        24.  
        25. Password p(initPwd);
        26.  
        27. // 생성자에서 값 전달이 쓰이므로 std::string
        28. // 이동 생성 1 회의 비용이 발생한다.
        29.  
        30. // 그런데 프로그램의 사용자가 비밀번호를 변경했다고 하자.
        31.  
        32. std::string newPassword = "Beware the Jabberwock";
        33.  
        34. p.changeTo(newPassword);
        35.  
        36. // changeTo에 전달되는 인수는 좌측값(newPassword)이다.
        37.  
        38. // 따라서 매개변수 newPwd가 생성될 때 호출되는 것은
        39. // std::string의 복사 생성자이다.
        40.  
        41. // 그 생성자는 새 패스워드를 담을 메모리를 할당한다.
        42.  
        43. // 그런 다음 newPwd가 text로 이동 대입되는데,
        44. // 이에 의해 text가 차지하고 있던 메모리가 해제된다.
        45.  
        46. // 따라서 changeTo 안에서 동적 메모리 관리 동작이
        47. // 두 번 일어난다.
        48.  
        49. // 그런데 지금 예에서 기존 패스워드가 새 패스워드보다 길다.
        50.  
        51. // 따라서 메모리를 할당하거나 해제할 필요가 없다.
        52.  
        53. // 오버로딩 접근방식을 사용한다면 할당과 해제를
        54. // 완전히 생략할 수 있다.
        55.  
        56. class Password {
        57. public:
        58. ...
        60. void changeTo(const std::string& newPwd) // 좌측값을 위한
        61. { // 오버로딩
        63. text = newPwd; // 만일 text.capacity() >= newPwd.size()
        64. // 이면 text의 메모리를 재사용할 수 있다.
        65. }
        67. ...
        68.  
        69. private:
        70. std::string text; // 이전과 동일
        71. };
        72.  
        73. // 이 시나리오에서 값 전달의 비용에는 여분의
        74. // 메모리 할당과 해제가 포함된다.
        75.  
        76. // 동적 메모리 할당 및 해제 비용은 std::string
        77. // 이동 연산의 수십, 수백 배일 가능성이 크다.
        78.  
        79. // 흥미롭게도, 만일 기존 패스워드가 새것보다 짧다면
        80. // 대체로 대입 도중 할당-해제 쌍을 피하는 것이
        81. // 불가능하며, 그런 경우 값 전달이 참조 전달과
        82. // 거의 비슷한 빠르기로 실행될 것이다.
        83.  
        84. // 모든 타입이 그런 것은 아니지만,
        85. // 그런 타입이 많이 있다.
        86.  
        87. // 특히 std::string과 std::vector가 그런 타입이다.

        
        
        예제 코드 접기
        
        
        결론적으로, 최대한 빨라야 하는 소프트웨어에서는 값 전달 방식이 그리 바람직하지 않은 전략이다. 저렴한 이동 연산이라도 피하는 것이 중요하기 때문이다. 게다가 이동 연산이 몇 번 일어나는지가 확실하지 않은 경우도 있다.
        
        만일 Widget::addName이 Widget::validateName 이라는 함수를 호출하며 그 함수 역시 값 전달 방식이라고 하면 어떨까? 그리고 그 validateName 역시 또 다른 값 전달 방식의 함수를 호출할 수도 있다.

      • 값 전달에서는 잘림 문제가 발생할 수 있으므로, 일반적으로 기반 클래스 매개변수 타입에 대해서는 값 전달이 적합하지 않다.

        성능과는 무관하지만 신경 쓸 필요가 있는 또 다른 문제점이 있다. 바로, 참조 전달과는 달리 값 전달에서는 잘림 문제(slicing problem) 가 발생할 여지가 있다는 점이다.
        
        잘림 문제는 파생 클래스 타입의 객체가 기본 클래스 타입의 객체에 대입될 때, 파생 클래스 부분이 잘려 나가는(slice off) 문제이다.
        
        잘림 문제 예제 코드 보기
        
        
        

        1. class Widget { ... }; // 기반 클래스
        2.  
        3. class SpecialWidget: public Widget { ... }; // 파생 클래스
        4.  
        5. void processWidget(Widget w); // Widget과 그로부터 파생된 임의의
        6. // 타입을 받는 함수;
        7. // 잘림 문제가 있다.
        8. ...
        9.  
        10. SpecialWidget sw;
        11.  
        12. ...
        13.  
        14. processWidget(sw); // processWidget은 이를
        15. // SpecialWidget이 아니라
        16. // Widget으로 인식한다!
        17.  

        
        
        잘림 문제 예제 코드 접기
        
        
        

  42. 삽입 대신 생성 삽입을 고려하라 / 314

      • 이론적으로, 생성 삽입 함수들은 종종 해당 삽입 버전보다 더 효율적이어야 하며, 덜 효율적인 경우는 절대로 없어야 한다.

        예제 코드 보기
        
        
        

        1. // 다음과 같은 상황을 생각해 보자.
        2.  
        3. std::vector<std::string> vs; // std::string 컨테이너
        4.  
        5. vs.push_back("xyzzy"); // 문자열 리터럴을 추가한다.
        6.  
        7. // 문자열 리터럴은 std::string과 타입이
        8. // 다르므로, push_back을 호출하는 문장은
        9. // 다음과 같이 해석된다.
        10.  
        11. vs.push_back(std::string("xyzzy"));
        12.  
        13. // 그 결과 임시 std::string 객체가 생성되고
        14. // 그 임시 객체(우측값)가 std::vector 안의
        15. // 문자열로 이동한다.
        16.  
        17. // 하지만 emplace_back 멤버 함수를
        18. // 사용하면 더 효율적으로 만들 수 있다.
        19.  
        20. vs.emplace_back("xyzzy");
        21.  
        22. // emplace_back은 완벽 전달을 이용하므로
        23. // 문자열 리터럴이 std::vector 안의
        24. // std::string 생성자에게 그대로 전달된다.
        25.  
        26. // 따라서 임시 객체의 생성과 소멸 비용이
        27. // 들지 않는다.

        
        
        예제 코드 접기
        
        
        생성 삽입 함수들은 삽입 함수들이 하는 모든 일을 할 수 있다. 게다가 좀 더 효율적으로 수행될 수 있는 경우가 있으며, 적어도 이론적으로는, 덜 효율적으로 수행되는 경우는 결코 없다.

      • 실질적으로, 만일 (1) 추가하는 값이 컨테이너로 대입되는 것이 아니라 생성되고, (2) 인수 타입(들)이 컨테이너가 담는 타입과 다르고, (3) 그 값이 중복된 값이어도 컨테이너가 거부하지 않는다면, 생성 삽입 함수가 삽입 함수보다 빠를 가능성이 아주 크다.

        다음 세 조건이 모두 성립한다면 거의 항상 생성 삽입의 성능이 삽입의 성능을 능가한다.
        
        
        • 추가할 값이 컨테이너에 대입되는 것이 아니라 컨테이너 안에서 생성된다. emplace_back처럼 그 어떤 객체도 존재하지 않는 곳에 추가하는 경우, 새 값은 컨테이너 안에 생성되어야 한다. 하지만, 새 값을 이미 다른 객체가 차지하고 있는 장소에 배치하도록 하면 상황이 달라진다. 다음을 보자.
          
          std::vector<std::string> vs;
          
          ...
          // 요소들을 vs에 추가한다.
          
          vs.emplace(vs.begin(), "xyzzy");
          // "xyzzy"를 vs의
          // 시작에 추가한다.
          
          이런 경우에, 기존의 객체가 차지하고 있던 메모리 장소에 새 객체를 생성하는 표준 라이브러리 구현은 드물다. 대신 구현들은 그 값을 해당 장소로 이동 대입한다.
          
          그런데 이동 대입을 수행하려면 이동의 원본이 필요하며, 따라서 이동 원본이 될 임시 객체를 생성해야 한다. 삽입에 비한 생성 삽입의 주된 장점은 임시 객체를 생성, 파괴하는 일이 없다는 것이므로, 이처럼 값을 대입을 통해서 컨테이너 안에 넣을 때에는 생성 삽입의 장점이 사라지는 경향이 생긴다.
          
          노드 기반 컨테이너들은 거의 항상 생성을 통해서 새 값을 추가하며, 표준 컨테이너들은 대부분 노드 기반이다. 노드 기반이 아닌 표준 컨테이너는 std::vector와 std::deque, std::string 뿐이다(std::array도 아니지만, 이 컨테이너는 삽입과 생성 삽입을 둘 다 지원하지 않는다).
          
          노드 기반이 아닌 컨테이너에서는 emplace_back이 항상 대입 대신 생성을 이용해서 새 값을 컨테이너에 넣는다고 간주해도 무방하다. 그리고 std::deque의 경우에는 emplace_front 역시 마찬가지이다.
        • 추가할 인수 타입(들)이 컨테이너가 담는 타입과 다르다. 일반적으로 삽입에 비한 생성 삽입의 장점은 유연한 인터페이스 덕분에 전달된 인수 타입들이 컨테이너가 담는 타입과 달라도 임시 객체의 생성과 파괴가 일어나지 않는다는 점이다. 어떤 컨테이너<T>에 T 타입의 객체를 추가할 때에는 생성 삽입이 삽입보다 빠를 이유가 없다. 그럴 때에는 삽입 인터페이스에서도 임시 객체를 생성할 필요가 없기 때문이다.
        • 컨테이너가 기존 값과의 중복 때문에 새 값을 거부할 우려가 별로 없다. 이는 컨테이너가 중복을 허용하거나, 또는 추가할 값들이 대부분 고유한 경우에 해당한다. 이 조건이 중요한 이유는, 중복 제한이 있는 경우 일반적으로 생성 삽입 구현은 새 값으로 노드를 생성해서 그것을 기존 컨테이너 노드들과 비교한다는 것이다.
          
          만일 추가할 값이 컨테이너에 없으면 그 노드를 컨테이너에 연결한다(link). 그러나 값이 이미 있으면 생성 삽입이 취소되고 그 노드가 파괴된다. 따라서 생성과 파괴 비용이 낭비되고 만다. 이런 노드들은 삽입 함수보다 생성 삽입 함수에서 더 자주 생성된다.

      • 자원 관리 객체를 컨테이너에 추가한다면, 그리고 자원 획득과 그 자원을 자원 관리 객체로 변환하는 시점 사이에 아무것도 끼어들지 못하게 하라는 조언(항목 21 참고)을 제대로 따른다면, 생성 삽입이 삽입 함수보다 더 나은 성능을 보일 가능성은 별로 없다.

        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // std::shared_ptr<Widget>들을 담는 컨테이너가
        3. // 있고, 커스텀 삭제자(항목 19 참고)를 통해서 해제되어야
        4. // 하는 std::shared_ptr 객체 하나를 이 컨테이너에
        5. // 추가한다고 하자.
        6.  
        7. // 항목 21에서 설명하듯이, std::shared_ptr를 생성할
        8. // 때에는 std::make_shared를 사용하는 것이 좋지만,
        9. // 지금처럼 커스텀 삭제자를 지정할 필요가 있는 경우에는
        10. // 그럴 수 없다.
        11.  
        12. std::list<std::shared_ptr<Widget> > ptrs;
        13.  
        14. void killWidget(Widget* pWidget); // 커스텀 삭제자
        15.  
        16. // 삽입 함수를 이용하는 코드는 다음과 같은 모습이다.
        17.  
        18. ptrs.push_back(std::shared_ptr<Widget>(new Widget, killWidget));
        19.  
        20. // 또는 이런 방식을 수도 있다. 의미는 동일하다.
        21.  
        22. ptrs.push_back({ new Widget, killWidget });
        23.  
        24. // 위의 두 방식 모두 임시 std::shared_ptr 객체가
        25. // 생성되었다 파괴되는 일이 생긴다.
        26.  
        27. // 다음과 같은 시나리오를 생각해 보자.
        28.  
        29.  
        30. // 1. -------------------------------------------
        31. // 두 호출 모두, "new Widget"으로 만들어진
        32. // 생 포인터를 담는 임시 std::shared_ptr<Widget>
        33. // 객체가 생성된다. 이 객체를 temp라고 부르기로 하자.
        34.  
        35.  
        36. // 2. -------------------------------------------
        37. // push_back은 그 temp를 참조로 받는다.
        38.  
        39. // temp의 복사본을 담을 리스트 노드를 할당하는
        40. // 도중에 메모리 부족(out-of-memory) 예외가 발생한다.
        41.  
        42.  
        43. // 3. -------------------------------------------
        44. // 예외가 push_back 바깥으로 전파되면서
        45. // temp가 파괴된다.
        46.  
        47. // temp는 자신이 관리하는 Widget을 참조하는
        48. // 마지막 std::shared_ptr 객체였으므로,
        49. // temp가 파괴되면서 해당 Widget도 자동으로
        50. // 해제된다.
        51.  
        52.  
        53. // 예외가 발생해도 어떠한 누수도 일어나지 않음을
        54. // 주목하자.
        55.  
        56.  
        57. // 이번에는 push_back 대신 emplace_back을
        58. // 사용해서 생각해 보자.
        59.  
        60.  
        61. // 1. -------------------------------------------
        62. // "new Widget"으로 만들어진 생 포인터가
        63. // emplace_back으로 완벽 전달된다.
        64.  
        65. // emplace_back은 새 값을 담을 리스트
        66. // 노드를 할당한다.
        67.  
        68. // 그런데 할당이 실패하고 메모리 부족
        69. // 예외가 발생한다.
        70.  
        71.  
        72. // 2. -------------------------------------------
        73. // 예외가 emplace_back 밖으로 전파되면서,
        74. // 힙에 있는 Widget 객체에 도달하는 유일한
        75. // 수단인 생 포인터가 사라진다.
        76.  
        77. // 결국 자원이 샌다.
        78.  
        79.  
        80. //-----------------------------------------------------------------------------
        81. // 사실 항목 21에서 설명하듯이, "new Widget" 같은
        82. // 표현식으로 생긴 생 포인터를 받아서 자원 관리 객체를
        83. // 생성하는 작업을 개별적인 문장에서 수행하는 것이 좋다.
        84.  
        85. // 다음은 그것을 따르는 예제이다.
        86.  
        87. std::shared_ptr<Widget> spw(new Widget, // Widget 객체와 그것을
        88. killWidget); // 관리하는 spw 객체를 생성
        89.  
        90. ptrs.push_back(std::move(spw)); // spw를 우측값으로 전달
        91.  
        92. // emplace_back 버전도 비슷하다.
        93.  
        94. std::shared_ptr<Widget> spw(new Widget, killWidget);
        95. ptrs.emplace_back(std::move(spw));
        96.  
        97. // 어떤 방식이든, 이 접근방식에서는 spw의
        98. // 생성과 파괴 비용이 발생한다.

        
        
        예제 코드 접기
        
        
        

      • 생성 삽입 함수는 삽입 함수라면 거부당했을 타입 변환들을 수행할 수 있다.

        초기화 방식은 두 가지가 있다. 하나는 복사 초기화(copy initialization)이고, 다른 하나는 직접 초기화(direct initialization)이다.
        
        explicit 생성자에서는 복사 초기화를 사용할 수 없지만 직접 초기화는 사용할 수 있다. std::regex는, const char* 타입의 인수를 받고 explicit으로 선언된 생성자를 제공한다.
        
        std::regex r1 = nullptr;
        // 복사 초기화;
        // 오류! 컴파일 안 됨
        
        std::regex r2(nullptr);
        // 직접 초기화;
        // 컴파일됨
        
        생성 삽입 함수는 직접 초기화를 사용한다. 따라서 explicit 생성자를 지원한다. 삽입 함수는 복사 생성자를 사용하므로 explicit 생성자를 지원하지 않는다.
        
        따라서 다음의 코드는 둘다 엉터리지만 생성 삽입 함수는 컴파일 오류가 뜨지 않는다.
        
        std::vector<std::regex> regexes;
        
        regexes.emplace_back(nullptr);
        // 컴파일됨; 직접 초기화에서는
        // 포인터를 받는, explicit으로
        // 선언된 std::regex 생성자를
        // 사용할 수 있다.
        
        regexes.push_back(nullptr);
        // 오류! 복사 초기화에서는
        // 그런 생성자를 사용할 수 없다.
        
        이 예제의 교훈은, 생성 삽입 함수를 사용할 때에는 제대로 된 인수를 넘겨주는 데 특별히 신경을 써야 한다는 것이다. 컴파일러는 여러분의 코드를 어떻게든 유효하게 만들기 위해 심지어 explicit 생성자들까지도 고려한다는 점을 기억하기 바란다.