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

• Chapter 1   기본 개념들

  1. 포인터(pointer)와 참조자(reference)를 구분하자 / 44

     • 참조자는 참조하고자 하는 어떤 객체를 미리 알고 있을 때, 다른 객체를 바꾸어 참조할 일이 결코 없을 때, 그리고 포인터를 사용하면 문법상 의미가 어색해지는 연산자를 구현할 때 사용하면 됩니다. 이 외의 경우에는 무조건 포인터를 사용하세요.

       예제 코드 보기
       
       
       

       1. //-------------------------------------------------------------------
       2. // 절대로 써서는 안되는 코드
       3.  
       4. char *pc = 0;
       5. char& rc = *pc;
       6.  
       7. // 이런 경우는 말이 필요 없는
       8. // "괘씸하고 못된 코드" 입니다.
       9. // 컴파일은 되겠지만, 실행 결과는
       10. // 에측 할 수 없습니다.
       11.  
       12.  
       13. //-------------------------------------------------------------------
       14. // 참조자는 선언될 때 반드시 초기화 해야 합니다.
       15.  
       16. string& rs; // 에러입니다! 참조는 반드시
       17. // 초기화해야 합니다.
       18.  
       19. string s("xyzzy");
       20. string& rs = s; // 통과. rs는 s를 참조합니다.
       21.  
       22. // 반면 포인터의 경우에는 이런 제약이 없습니다.
       23.  
       24. string *ps; // 초기화 되지 않은 포인터
       25. // 써도 상관없지만 문제가 생길 수 있습니다.
       26.  
       27.  
       28. //-------------------------------------------------------------------
       29. // 널 참조자 같은 것이 존재하지 않기 때문에
       30. // 참조자는 쓰기 전에 유효성을 검사할 필요가
       31. // 없습니다.
       32.  
       33. void printDouble(const double& rd)
       34. {
       35. cout << rd; // rd가 널 객체를 참조하는지 볼 필요도
       36. } // 없습니다. 반드시 double을 참조해야 합니다.
       37.  
       38. // 반면 포인터를 쓸 경우에는 사용 전에 반드시
       39. // 유효한 객체를 가리키고 있는지 검사해야 합니다.
       40. // (이것을 널 테스트라고 합니다.)
       41.  
       42. void printDouble(const double *pd)
       43. {
       44. if (pd) { // 널 포인터인지 검사합니다.
       45. cout << *pd;
       46. }
       47. }
       48.  
       49.  
       50. //-------------------------------------------------------------------
       51. // 포인터는 다른 객체의 주소값으로 얼마든지
       52. // 바꾸어 세팅할 수 있습니다.
       53.  
       54. // 하지만 참조자는 초기화될 때 참조했던
       55. // 그 객체만 참조합니다.
       56.  
       57. string s1("Nancy");
       58. string s2("Clancy");
       59.  
       60. string& rs = s1; // rs는 s1을 "참조합니다."
       61.  
       62. string *ps = &s1; // ps는 s1을 "가리킵니다."
       63.  
       64. rs = s2; // rs는 여전히 s1을 참조하지만,
       65. // s1의 값은 이제
       66. // "Clancy"입니다.
       67.  
       68. ps = &s2; // ps는 이제 s2를 가리킵니다.
       69. // 그리고 s1은 바뀌지 않습니다.
       70.  
       71.  
       72. //-------------------------------------------------------------------
       73. // 이런 경우에는 반드시 참조자를 쓰는 것이 좋습니다.
       74.  
       75. vector<int> v(10); // 크기 10의 int 벡터를 만듭니다.
       76.  
       77. v[5] = 10; // 이 대입 연산의 대상은 operator[]의
       78. // 반환값입니다.
       79.  
       80. // 만일 operator[]가 포인터를 반환하면,
       81. // 다음과 같이 조금 어색한(포인터의 벡터처럼 보이는)
       82. // 형태가 되어야 할 것입니다.
       83.  
       84. *v[5] = 10;

       
       
       예제 코드 접기
       
       
       

  2. 가능한 C++ 스타일의 캐스트를 즐겨 쓰자 / 47

     • C 스타일의 캐스트는 어떤 타입을 다른 타입으로 아무 생각 없이 바꾸어버릴 수 있습니다. 또한 C 스타일의 캐스트는 코드 내에서 찾아내기도 힘듭니다. 이런 단점을 보완하기 위해 C++ 스타일의 캐스트 연산자 네 가지를 새로 도입했습니다.

     • static_cast는 C 스타일의 캐스트와 똑같은 의미와 형변환 능력을 가지고 있는, 기본적인 캐스트 연산자 입니다.

       C 스타일의 캐스트와 구실이 똑같다 보니 제약도 똑같습니다. 예를 들어 struct를 int로 바꾼다던지 double을 포인터 타입으로 바꾸는 일은 이것으로 할 수 없습니다.
       
       static_cast 예제 코드 보기
       
       
       

       1. // int 타입의 변수를 double인 것처럼
       2. // 행세하게 해서 부동소수점 실수를 결과로
       3. // 내는 표현식에 넣고 싶을때 static_cast를
       4. // 다음과 같이 쓸 수 있습니다.
       5.  
       6. int firstNumber, secondNumber;
       7. ...
       8. double result = static_cast<double>(firstNumber) / secondNumber;
       9.  
       10. // C 스타일의 캐스트 보다 훨씬 쉽게
       11. // 찾아낼 수 있습니다.

       
       
       static_cast 예제 코드 접기
       
       
       

     • 나머지 세 가지의 C++ 캐스트 연산자는 좀더 구체적인 목적을 위해 만들어졌습니다. const_cast는 표현식의 상수성이나 휘발성(volatile)을 없애는 데에 사용합니다.

       ※ 상수성이나 휘발성을 제거하는 것 이외의 용도로 const_cast를 쓸 수 없습니다(통하지 않습니다).
       
       const_cast 예제 코드 보기
       
       
       

       1. class Widget { ... };
       2. class SpecialWidget: public Widget { ... };
       3.  
       4. void update(SpecialWidget *psw);
       5.  
       6. SpecialWidget sw; // sw는 비상수 객체입니다.
       7. const SpecialWidget& csw = sw; // 그러나 csw는 이 객체를
       8. // 상수 객체인 것처럼 참조합니다.
       9.  
       10. update(&csw); // 에러입니다! const SpecialWidget*는
       11. // SpecialWidget*를 받는 함수에 넘길
       12. // 수 없습니다.
       13.  
       14. update(const_cast<SpecialWidget*>(&csw));
       15. // 이상 무. &csw의 상수성이 명확하게
       16. // 제거되었습니다[그리고 csw(sw)
       17. // 의 정보는 이제 update 안에서
       18. // 바뀔 수 있습니다].
       19.  
       20. update((SpecialWidget*)&csw);
       21. // 앞에서와 똑같습니다. 하지만 두 눈을 부릅
       22. // 떠야 찾을 수 있는 C 스타일 캐스트입니다.
       23.  
       24. Widget *pw = new SpecialWidget;
       25. update(pw); // 에러입니다! pw의 타입은 Widget*이지만,
       26. // update는 SpecialWidget*를 받습니다.
       27.  
       28. update(const_cast<SpecialWidget*>(pw));
       29. // 에러입니다! const_cast는 상수성이나
       30. // 휘발성에 영향을 줄 때에만 유효하고,
       31. // 상속 관계를 하향시키는 캐스팅 등엔
       32. // 쓸 수 없습니다.

       
       
       const_cast 예제 코드 접기
       
       
       

     • dynamic_cast는 상속 계층 관계를 가로지르거나 하향시킨 클래스 타입으로 안전하게 캐스팅할 때 사용합니다. 말하자면, dynamic_cast는 기본 클래스의 객체에 대한 포인터나 참조자의 타입을 파생(derived) 클래스, 혹은 형제(sibling) 클래스의 타입으로 변환해 준다는 것입니다.

       ※ 캐스팅의 실패는 널 포인터(포인터를 캐스팅할 때)나 예외(참조자를 캐스팅할 때)를 보고 판별할 수 있습니다.
       
       dynamic_cast 예제 코드 보기
       
       
       

       1. class Widget { ... };
       2. class SpecialWidget: public Widget { ... };
       3.  
       4. void update(SpecialWidget *psw);
       5.  
       6. Widget *pw;
       7.  
       8. ...
       9.  
       10. update(dynamic_cast<SpecialWidget*>(pw));
       11. // 이상 무. update에 포인터 pw를
       12. // SpecialWidget에 대한 포인터로서 넘깁니다.
       13. // 물론 pw가 그 객체를 가리켜야 되고,
       14. // 그렇지 않으면 널 포인터가 넘어갑니다.
       15.  
       16. void updateViaRef(SpecialWidget& rsw);
       17.  
       18. updateViaRef(dynamic_cast<SpecialWidget&>(*pw));
       19. // 이상 무. pw가 그 객체를 참조하고 있으면
       20. // updateViaRef에 *pw를 SpecialWidget
       21. // 의 참조자 타입으로 넘깁니다. 실패하면
       22. // 예외가 발생합니다.
       23.  
       24. // dynamic_cast에도 제약이 있습니다.
       25. // 이 연산자는 상속 계층 구조를 오갈 때에만
       26. // 사용해야 하며, 가상 함수가 하나도 없는
       27. // 타입에는 적용할 수 없고
       28. // (자세한 내용은 항목 24를 참조하세요),
       29. // 상수성 제거에도 쓸 수 없습니다.
       30.  
       31. int firstNumber, secondNumber;
       32. ...
       33. double result = dynamic_cast<double>(firstNumber) / secondNumber;
       34. // 에러입니다! 가상 함수가 전혀 없습니다.
       35.  
       36. const SpecialWidget sw;
       37. ...
       38. update(dynamic_cast<SpecialWidget*>(&sw));
       39. // 에러입니다! dynamic_cast는 상수성을
       40. // 제거하는데 쓸 수 없습니다.

       
       
       dynamic_cast 예제 코드 접기
       
       
       

     • 네 가지 C++ 캐스트 연산자의 마지막은 reinterpret_cast입니다. 이 연산자가 적용된 후의 변환 결과는 거의 항상 컴파일러에 따라 다르게 정의되어 있습니다. 즉 이식성이 없어서, 이 연산자가 쓰인 소스는 직접 이식이 불가능합니다.

       reinterpret_cast의 가장 흔한 용도는 함수 포인터 타입을 서로 바꾸는 것입니다.
       
       reinterpret_cast 예제 코드 보기
       
       
       

       1. typedef void (*FuncPtr)(void); // FuncPtr은 인자를 받지 않고
       2. // void를 반환하는 함수에 대한
       3. // 포인터 입니다.
       4.  
       5. FuncPtr funcPtrArray[10]; // funcPtrArray는 10개의 FuncPtr로
       6. // 만들어진 배열입니다.
       7.  
       8. // 이때 다음 함수에 대한 포인터를
       9. // funcPtrArray에 넣어야 할
       10. // 피치 못할 사정이 생겼습니다.
       11.  
       12. int doSomething(void);
       13.  
       14. // FuncPtr의 반환 타입은 void인데,
       15. // doSomething의 반환 타입은 int라서
       16. // 통상적인 방법으론 doSomething을
       17. // funcPtrArray에 넣을 수 없습니다.
       18. // 이럴 때 reinterpret_cast를
       19. // 사용할 수 있습니다.
       20.  
       21. funcPtrArray[0] = &doSomething; // 에러입니다! 타입 불일치이군요.
       22.  
       23. funcPtrArray[0] = // 이것은 컴파일됩니다.
       24. reinterpret_cast<FuncPtr>(&doSomething);
       25.  
       26.  
       27. // 함수 포인터의 캐스팅은 소스의 이식성을
       28. // 떨어뜨리고(C++ 스펙에는 모든 함수 포인터를
       29. // 똑같은 방법으로 나타내야 한다는 보장이 전혀
       30. // 없습니다.), 어떤 경우에 이런 캐스팅은
       31. // 잘못된 결과를 낳기도 하기 때문에(항목 31을 보십시오),
       32. // 여러분의 목에 칼이 들어오기 전에는 함수 포인터의
       33. // 캐스팅은 어떻게든 피하세요.
       34.  

       
       
       reinterpret_cast 예제 코드 접기
       
       
       

     • 물론 C++ 캐스트 연산자를 지원하지 않는 컴파일러를 쓰는 분이라면, 전통적인 캐스팅을 쓸 수 밖에 없는데, 이 때 매크로를 이용하면 C++ 캐스트 연산자의 흉내를 낼 수 있습니다.

       예제 코드 보기
       
       
       

       1. #define static_cast(TYPE, EXPR)((TYPE)(EXPR))
       2. #define const_cast(TYPE, EXPR)((TYPE)(EXPR))
       3. #define reinterpret_cast(TYPE, EXPR)((TYPE)(EXPR))
       4.  
       5. ... // 항목 2의 앞선 예제 참조
       6.  
       7. double result = static_cast(double, firstNumber) / secondNumber;
       8.  
       9. update(const_cast(SpecialWidget*, &sw));
       10.  
       11. funcPtrArray[0] = reinterpret_cast(FuncPtr, &doSomething);
       12.  
       13. // 매크로로 흉내낸 C++ 캐스트 연산자는
       14. // 진짜 연산자들처럼 안전한 캐스팅을
       15. // 수행하는 것은 아니지만, 컴파일러가
       16. // 최신의 캐스트 연산자를 지원하게 되면,
       17. // 코드를 간단히 업그레이드 할 수 있겠지요?

       
       
       예제 코드 접기
       
       
       

  3. 배열과 다형성은 같은 수준으로 놓고 볼 것이 아니다 / 53

     • 배열은 배열의 첫 요소를 가리키는 포인터입니다. 배열의 첨자 연산 역시 포인터와 밀접한 관련이 있습니다. array[i]는 *(array + i)로 해석되게 되죠. 이 때 array + i가 가리키는 메모리 위치는 배열이 가리키는 위치로부터 얼마나 떨어져 있는지도 간단한 공식으로 알아 낼 수 있습니다. 바로 i * sizeof(배열 내의 요소 객체 하나) 입니다.

     • 기본 클래스에서 파생된 파생 클래스는 크기가 서로 다를 수도 있습니다. 만일 기본 클래스 배열을 받아 작업하는 코드로 파생 클래스 배열을 처리하면 어떻게 될까요? 기본 클래스와 파생 클래스의 크기가 다르다면, 각 배열 요소의 메모리 주소가 잘못 계산되어 문제를 일으킬 것이 분명합니다.

       예제 코드 보기
       
       
       

       1. class BST { ... };
       2. class BalancedBST: public BST { ... };
       3.  
       4. void printBSTArray(ostream& s,
       5.    const BST array[],
       6.    int numElements)
       7. {
       8. for (int i = 0; i < numElements; ++i) {
       9. s << array[i]; // operator<< 연산자 함수가
       10. } // BST 클래스에서 이미 정의되어
       11. } // 있다고 가정한 것입니다.
       12.  
       13. BST BSTArray[10];
       14.  
       15. ...
       16.  
       17. printBSTArray(cout, BSTArray, 10); // 잘 작동합니다.
       18.  
       19. BalancedBST bBSTArray[10];
       20.  
       21. ...
       22.  
       23. printBSTArray(cout, bBSTArray, 10); // 잘 작동할까?
       24.  
       25. // 위의 코드 중 반복문을 잘 봅시다.
       26.  
       27. for (int i = 0; i < numElements; ++i) {
       28. s << array[i];
       29. }
       30.  
       31. // 이 코드에서 array와 array + i 사이의
       32. // 거리는 항상 i * sizeof(BST)가 됩니다.
       33.  
       34. // 하지만 printBSTArray에 BalancedBST 배열을
       35. // 넘겨주면 i * sizeof(BalancedBST)로
       36. // 계산되어야 정상적으로 작동할 것입니다.
       37.  
       38. // 그러므로 printBSTArray에 BalancedBST 배열을
       39. // 넘겨주면 어떻게 될지 알 수 없습니다.

       
       
       예제 코드 접기
       
       
       

     • 기본 클래스 배열을 삭제하는 코드로 파생 클래스 배열을 삭제하려 할 때도 마찬가지의 문제가 발생합니다. 동적 배열을 삭제 할 때에 배열 각각의 요소의 소멸자를 호출하는 코드가 생성됩니다. 이 때 기본 클래스와 파생 클래스의 크기가 서로 다르다면, 마찬가지로 각 배열 요소의 메모리 주소가 잘못 계산되어 문제를 일으킬 것입니다.

       예제 코드 보기
       
       
       

       1. class BST { ... };
       2. class BalancedBST: public BST { ... };
       3.  
       4. // 배열을 삭제하는데, 우선 배열 삭제를 알리는
       5. // 메시지를 로그에 남깁니다.
       6. void deleteArray(ostream& logStream, BST array[])
       7. {
       8. logStream << "Deleting array at address "
       9. << static_cast<void*>(array) << '\n';
       10. delete[] array;
       11. }
       12.  
       13. BalancedBST *balTreeArray = new BalancedBST[50];
       14. // BalancedBST 배열을
       15. // 생성합니다.
       16.  
       17. ...
       18.  
       19. deleteArray(cout, balTreeArray);
       20. // 배열 삭제를 로깅합니다.
       21.  
       22. // 눈에는 보이지 않지만 이 코드에서도
       23. // 포인터값 계산이 행해집니다.
       24.  
       25. // 배열이 삭제될 때, 배열의 각 요소
       26. // 객체에 대해 소멸자가 호출되어야 합니다
       27. // (항목 8을 보세요).
       28.  
       29. // 컴파일러는 이런 문장을 만나면,
       30.  
       31. delete[] array;
       32.  
       33. // 이와 비슷한 코드를 만들어 내겠지요.
       34.  
       35. // *array내의 객체들을 하나씩 없애는데,
       36. // 객체들이 생성되었던 순서의 반대 순서로 없앱니다.
       37. for (int i = 해당 배열 내의 요소 개수 - 1; i >= 0; --i)
       38. {
       39. array[i].BST::~BST(); // array[i]의 소멸자를
       40. } // 호출합니다.
       41.  
       42. // C++ 언어 스펙에 의하면,
       43. // 기본 클래스 포인터를 통해
       44. // 파생 클래스 객체의 배열을
       45. // 삭제한 결과는 "정의되지 않았다"
       46. // 라고 되어 있지만, 우린 이게
       47. // 무슨 뜻인지 잘 압니다.

       
       
       예제 코드 접기
       
       
       

     • 어떤 구체 클래스로부터 또 다른 구체 클래스를 파생시키는 일만 없으면, 객체의 배열을 다형적으로 조작하는 실수는 별로 하지 않는 점을 일러둡니다. 구체 클래스를 상속하여 구체 클래스를 만들지 않도록 소프트웨어를 설계했을 때 얻는 장점들은 항목 33에서 볼 수 있습니다.

  4. 쓸데 없는 기본 생성자는 그냥 두지 말자 / 56

     • 일반적으로, 배열의 요소로서 들어가는 객체에 대해 생성자 매개변수를 지정할 수가 없기 때문에, 기본 생성자가 없는 클래스 객체의 배열을 생성하기란 불가능합니다. 하지만 이 제약을 피해 가는 세 가지 방법이 있습니다. 배열을 힙에 만들지 않았을 때의 해결책은 배열이 정의된 위치에서 생성자 매개변수를 직접 넣어 주는 것입니다.

       예제 코드 보기
       
       
       

       1. // 아래 클래스는 항상 유효한 IDNumber를
       2. // 가지고 있어야 하는 클래스 입니다.
       3. // 기본 생성자로는 유효한 IDNumber를
       4. // 알 수 없으므로 기본 생성자가 없습니다.
       5.  
       6. class EquipmentPiece {
       7. public:
       8. EquipmentPiece(int IDNumber);
       9. ...
       10. };
       11.  
       12. EquipmentPiece bestPieces[10]; // 에러입니다! EquipmentPiece의
       13. // 생성자를 호출할 수 없습니다.
       14.  
       15. EquipmentPiece *bestPieces =
       16. new EquipmentPiece[10]; // 에러입니다! 마찬가지 문제
       17.  
       18. // 배열을 힙에 만들지 않는다면
       19. // 다음과 같이 해결할 수 있습니다.
       20.  
       21. int ID1, ID2, ID3, ..., ID10; // 장비의 ID 번호를 가질
       22. // 변수들
       23. ...
       24.  
       25. EquipmentPiece bestPieces[] = { // 이제 문제없습니다. 생성자의 인자가
       26. EquipmentPiece(ID1), // 주어졌습니다.
       27. EquipmentPiece(ID2),
       28. EquipmentPiece(ID3),
       29. ...,
       30. EquipmentPiece(ID10)
       31. };

       
       
       예제 코드 접기
       
       
       

     • 힙에 생성한 배열(new로)에 대해서는 첫 번째 방법을 어떻게 써볼 수가 없답니다. 보다 일반적인 방법은 객체의 배열 대신에 포인터의 배열을 사용하는 것입니다.

       예제 코드 보기
       
       
       

       1. typedef EquipmentPiece* PEP;
       2.  
       3. PEP bestPieces[10]; // 문제없습니다. 생성자가 전혀 호출되지 않습니다.
       4.  
       5. PEP *bestPieces = new PEP[10]; // 역시 문제없습니다.
       6.  
       7. // 이제 배열에 들어 있는 각 포인터들은
       8. // 다른 EquipmentPiece 객체를
       9. // 가리키게 할 수 있겠지요.
       10.  
       11. for (int i = 0; i < 10; ++i)
       12. bestPieces[i] = new EquipmentPiece(ID Number);
       13.  
       14. // 이 방법은 두 개의 단점을 가지고 있습니다.
       15.  
       16. // 1. 이 배열 내의 모든 포인터가 가리키는
       17. // 객체를 삭제해야 한다는 것을 잊으면
       18. // 안됩니다.
       19.  
       20. // 2. 필요한 메모리 사용량이 늘어납니다.
       21. // EquipmentPiece 객체를 담을
       22. // 메모리 공간 이외에 포인터를 담을
       23. // 메모리 공간이 필요하니까요.

       
       
       예제 코드 접기
       
       
       

     • 두 번째 방법에서 포인터를 위한 메모리 공간의 낭비를 줄이기 위한 방법으로, 배열에 대해 직접 비가공(raw) 메모리를 할당한 후에 "메모리 지정 new(placement new)"(항목 8을 보세요.)를 써서 그 메모리 안에다 EquipmentPiece 객체가 생성되도록 하는 방법이 있습니다.

       예제 코드 보기
       
       
       

       1. // 10개의 EquipmentPiece 객체를 담을 수 있는
       2. // 크기의 비가공 메모리를 생성합니다.
       3. void *rawMemory =
       4. operator new[](10*sizeof(EquipmentPiece));
       5.  
       6. // bestPieces가 EquipmentPiece 배열 첫 요소의
       7. // 주소가 되도록 세팅합니다.
       8. EquipmentPiece *bestPieces =
       9. static_cast<EquipmentPiece*>(rawMemory);
       10.  
       11. // "메모리 지정 new(placement new)"를 써서
       12. // 이 메모리 안에 EquipmentPiece 객체
       13. // 10 개를 생성합니다.
       14. for (int i = 0; i < 10; ++i)
       15. new(bestPieces + i)EquipmentPiece(ID Number);
       16.  
       17. // 메모리 지정 new를 사용하는 방법의 단점은,
       18. // 대부분의 프로그래머가 이것에 별로 친하지
       19. // 않다는 점과는 별개로, "객체를 삭제해야 할
       20. // 때에 소멸자를 손으로 직접 호출해야 한다"
       21. // 는 점입니다.
       22.  
       23. // 물론 소멸자 호출로만 끝나는 것이 아니라,
       24. // 그 다음에는 operator delete[]
       25. // (항목 8을 참고하세요)를 호출해서 원래의
       26. // 비가공 메모리를 직접 해제해야 합니다.
       27.  
       28. // bestPieces 내의 객체들을 그 객체가 생성된
       29. // 순서의 반대 순서로 없앱니다.
       30. for (int i = 9; i >= 0; --i)
       31. bestPieces[i].~EquipmentPiece();
       32.  
       33. // 원래의 비가공 메모리를 없앱니다.
       34. operator delete[](rawMemory);
       35.  
       36. // 다음과 같이 해제하려 하면 안됩니다.
       37.  
       38. delete[] bestPieces; // 오작동을 일으킵니다! bestPieces는
       39. // new 연산자를 써서 세팅한
       40. // 포인터가 아닙니다.
       41.  
       42. // 왜냐하면 new 연산자를 통해 세팅되지 않은 포인터에
       43. // 대해 삭제한 결과는 "정의되어 있지 않기(undefined)"
       44. // 때문입니다.

       
       
       예제 코드 접기
       
       
       

     • 기본 생성자가 없는 클래스의 두 번째 문제점은 많은 템플릿 기반의 컨테이너 클래스에 먹일(?) 수가 없다는 것입니다. 왜냐하면 이런 컨테이너 클래스를 인스턴스화 하기 위해서는, 템플릿 매개변수로 들어가는 타입이 기본 생성자를 가지고 있어야 하기 때문입니다. 대부분의 경우, 신경써서 템플릿을 설계하면(예를 들어 std::vector) 기본 생성자가 필요 없어지기도 합니다. 하지만 "신경" 과는 거리가 먼 방법으로 설계된 템플릿들도 많습니다. 이런 경우에는 기본 생성자가 없는 클래스를 템플릿 매개변수로 쓸 수 없습니다.

       예제 코드 보기
       
       
       

       1. template <typename T>
       2. class Array {
       3. public:
       4. Array(int size);
       5. ...
       7. private:
       8. T *data;
       9. };
       10.  
       11. template <typename T>
       12. Array<T>::Array(int size)
       13. {
       14. data = new T[size]; // 배열 안의 각 요소에 대해
       15. ... // T::T()를 호출합니다.
       16. }

       
       
       예제 코드 접기
       
       
       

     • 기본 생성자가 없는 가상 기본 클래스는 소프트웨어 개발에 쓰기 힘들다는 문제도 따라옵니다. 그 이유는 가상 기본 클래스의 생성자 매개변수를, 생성되는 객체의 파생 클래스 쪽에서 제공해야 하기 때문입니다.

     • 기본 생성자로 초기화 할 만한 적당한 값이 없는 클래스에게 억지로 기본 생성자를 만들면, 이 클래스의 다른 멤버 함수들이 복잡해 질 수 있습니다. 왜냐하면 이 클래스의 객체가 항상 제대로 초기화 되었다는 보장을 할 수 없기 때문에, 거의 모든 멤버 함수에서 해당 객체가 초기화 되었는지 점검하는 코드가 추가되어야 할 것이기 때문입니다.

       예제 코드 보기
       
       
       

       1. // 기본 생성자가 없는 클래스는 사용상에
       2. // 꽤나 귀찮은 제약이 따르기 때문에,
       3. // 어떤 사람은 기본 생성자로는 객체를
       4. // 초기화하는데 필요한 정보를 얻기 힘든
       5. // 상황에서도 다음과 같이 억지로
       6. // 기본 생성자를 넣기도 합니다.
       7.  
       8. class EquipmentPiece {
       9. public:
       10. EquipmentPiece(int IDNumber = UNSPECIFIED);
       11. ...
       13. private:
       14. static const int UNSPECIFIED; // ID가 설정되지 않았다는
       15. ... // 의미를 가지고 고정된
       16. }; // 상수입니다.
       17.  
       18. // 이와 같이 만든 경우 EquipmentPiece의
       19. // 거의 모든 멤버 함수들에는 IDNumber가
       20. // UNSPECIFIED인지를 검사하는 코드가
       21. // 추가되어야 할 것입니다.

       
       
       예제 코드 접기
       
       
       

     • 쓸 데 없는 기본 생성자는 클래스의 효율에도 걸림돌이 됩니다. 멤버 함수들은 클래스의 멤버 데이터가 제대로 초기화 되었는지를 검사해야 하니, 이 검사 시간 만큼 실행 속도가 떨어지겠지요. 게다가, 추가된 검사 코드의 크기만큼 실행 파일 및 라이브러리도 커집니다. 그뿐만이 아니라 검사에 실패했을 경우를 처리하는 코드도 생각해야 합니다. 이렇게 저렇게 낭비되는 비용이 꽤 쏠쏠합니다.

• Chapter 2   연산자(Operators)

  5. 사용자 정의 타입변환 함수에 대한 주의를 놓지 말자 / 64

     • 컴파일러가 마음대로 암시적 타입 변환을 하도록 내버려두면 대개 득보다 실이 많습니다. 왜냐하면 이런 타입 변환 함수들이 여러분이 원하든 싫어하든 상관 없이 호출되고 말기 때문입니다. 이 때문에 프로그램의 동작이 엉뚱해지고 비직관적으로 변합니다. 이런 동작은 오류를 찾아내기가 끔찍이도 어렵습니다.

     • 특히 타입 변환 연산자(함수)는 마음 깊은 곳부터 원하지 않는 이상 제공하지 않는 편이 좋습니다. 가급적이면 같은 일을 하고, 다른 이름을 갖는 멤버 함수로 만드는 편이 낫습니다. 왜냐하면 단일 인자 생성자와는 다르게, 타입 변환 연산자(함수)는 암시적으로 호출되는 것을 막을 방법이 없기 때문입니다.

       예제 코드 보기
       
       
       

       1. class Rational {
       2. public:
       3. operator double(void) const; // Rational을
       4. ... // double로 암시적으로 바꿉니다.
       5. }
       6.  
       7. // 이 함수는 다음과 같은 문장에 들어 있을 때
       8. // 자동으로 호출됩니다.
       9.  
       10. Rational r(1, 2); // r은 1/2이란 값을 가지고 있습니다.
       11.  
       12. double d = 0.5 * r; // r을 double로 바꾸고
       13. // 곱셈을 수행합니다.
       14.  
       15. // 이 때 Rational 객체를 기본 제공 타입처럼
       16. // 콘솔에 출력하고 싶어서 다음과 같은 코드를
       17. // 작성했습니다.
       18.  
       19. Rational r(1, 2);
       20.  
       21. cout << r; // "1/2"를 출력해야 합니다.
       22.  
       23. // 이 때 Rational 객체에 operator<< 함수를
       24. // 작성해 넣는 것을 잊었다는 가정을 하나 더 합시다.
       25.  
       26. // 많은 사람들이 이 경우 컴파일 오류가 날 것이라고
       27. // 생각할 수 있지만, 사실은 Rational의 변환
       28. // 함수가 호출되어 double형으로 암시적으로 변환된
       29. // 후 출력에 성공합니다.
       30.  
       31. // 하지만 "1/2" 형태가 아닌 부동 소수점 형태인
       32. // "0.5"와 같이 원하지 않는 형태로 출력이 될 것입니다.
       33.  
       34. // 이를 해결하는 방법은 타입 변환 연산자를
       35. // 제공하는 대신 똑같은 일을 하는 다른 이름의
       36. // 멤버 함수를 만드는 것입니다.
       37.  
       38. class Rational {
       39. public:
       40. ...
       41. double asDouble(void) const; // Rational을
       42. }; // double 타입으로 바꿉니다.
       43.  
       44. // 그리고 이 멤버 함수를 직접 호출합니다.
       45.  
       46. Rational r(1, 2);
       47.  
       48. cout << r; // 에러입니다! Rational을
       49. // 받는 operator<<가 없습니다.
       50.  
       51. cout << r.asDouble(); // 문제없습니다. r을 double 타입으로
       52. // 출력합니다.

       
       
       예제 코드 접기
       
       
       

     • 단일 인자 생성자는 다른 이름의 멤버 함수를 만드는 방법을 쓸 수 없습니다. 왜냐하면 단일 인자 생성자가 꼭 필요한 경우도 많기 때문입니다. 이 경우 단일 인자 생성자가 암시적으로 호출되지 않도록 막는 방법을 써야 합니다. 방법은 두 가지가 있습니다. 간단한 방법은 생성자 앞에 explicit 키워드를 붙이는 것입니다. 다른 방법으로는 프록시 클래스(항목 30을 참고하세요)를 사용하는 방법이 있습니다.

       예제 코드 보기
       
       
       

       1. template <typename T>
       2. class Array {
       3. public:
       4. Array(int lowBound, int highBound);
       5. Array(int size);
       7. T& operator[](int index);
       8. ...
       9. };
       10.  
       11. // 첫 번째 생성자 처럼 인자를 두 개 받는
       12. // 생성자는 타입 변환 함수로는 써먹을 수
       13. // 없습니다.
       14.  
       15. // 두 번째 생성자는 인자를 하나만 받기 때문에
       16. // 타입 변환 함수로 쓰일 수 있습니다.
       17. // 즉 int 타입을 Array<T>타입으로
       18. // 암시적으로 변환할 수 있게 됩니다.
       19.  
       20. // 예를 하나 들겠습니다. Array<T>를
       21. // 특수화 시킨 Array<int> 객체가 있고,
       22. // 이 객체들을 비교하는 연산자, 그리고 이것을
       23. // 사용하는 코드가 다음과 같다고 합시다.
       24.  
       25. bool operator==(const Array<int>& lhs,
       26. const Array<int>& rhs);
       27. Array<int> a(10);
       28. Array<int> b(10);
       29.  
       30. ...
       31.  
       32. for (int i = 0; i < 10; ++i)
       33. if (a == b[i]) { // 윽! "a"는 "a[i]"가 되어야 합니다.
       34. a[i]와 b[i]가 같으면
       35. 정해둔 무언가를 합니다.
       36. }
       37. else {
       38. 그렇지 않을 때에는 또 무언가를 합니다.
       39. }
       40.  
       41. // 보시다시피 실수로 조건문의 "a"옆에 "[i]"을
       42. // 빼먹었습니다.
       43.  
       44. // 이런 상황에서 컴파일러는 컴파일 오류를 내지 않고,
       45. // 암시적으로 b[i](int 타입의 값)을 Array<int>로
       46. // 바꾸어 비교를 해 버립니다. 즉 컴파일러는
       47. // 다음과 비슷한 코드를 생성할 것입니다.
       48.  
       49. for (int i = 0; i < 10; ++i)
       50. if (a == static_cast<Array<int> >(b[i])) ...
       51.  
       52. // 암시적 타입변환 연산자의 취약점은 같은 일을 하되
       53. // 이름이 다른 멤버함수를 대신 만드는 방식으로
       54. // 쉽게 피할 수 있습니다.
       55.  
       56. // 하지만 단일 인자 생성자는 그렇게 쉽게 피해갈 수
       57. // 있는 성질의 것이 아닙니다. 단일 인자 생성자는
       58. // 진짜로 제공해야 할 경우도 적지 않거든요.
       59.  
       60. // 그래서 컴파일러가 무분별하게(암시적으로)
       61. // 이런 연산자를 호출하지 않도록 만들어야 합니다.
       62.  
       63. // 첫 번째 방법은 explicit 키워드를 사용하는
       64. // 것입니다.
       65.  
       66. template <typename T>
       67. class Array {
       68. public:
       69. ...
       70. explicit Array(int size); // "explicit"의 용법을 잘 알아두세요.
       71. ...
       72. };
       73.  
       74. Array<int> a(10); // 좋습니다, explicit로 선언된 생성자는
       75. // 객체 생성시에 평상시와 마찬가지로
       76. // 사용할 수 있습니다.
       77.  
       78. Array<int> b(10); // 역시 사용할 수 있습니다.
       79.  
       80. if (a == b[i]) ... // 에러입니다! int를
       81. // 암시적으로 Array<int>로
       82. // 바꿀 방법이 없습니다.
       83.  
       84. if (a == Array<int>(b[i])) ... // 좋습니다. int를 Array<int>로
       85. // 바꾸는 작업이 명시적으로
       86. // 이루어졌습니다(그러나 코드의
       87. // 로직은 좀 의심스럽네요).
       88.  
       89. if (a == static_cast<Array<int> >(b[i])) ...
       90. // 마찬가지로 문제없고,
       91. // 마찬가지로 의심스럽습니다.
       92.  
       93. if (a == (Array<int>)b[i]) ... // C 스타일의 캐스팅 역시
       94. // 별 문제가 없지만, 코드의
       95. // 로직은 여전히 의심스럽습니다.
       96.  
       97. // 또 다른 방법으로 프록시 클래스를
       98. // 사용하는 방법이 있습니다.
       99.  
       100. template <typename T>
       101. class Array {
       102. public:
       103.  
       104. class ArraySize { // 새로 만든 프록시 클래스(proxy class)
       105. public:
       106. ArraySize(int numElements) : theSize(numElements) {}
       107. int size(void) const { return theSize; }
       108. private:
       109. int theSize;
       110. };
       112. Array(int lowBound, int highBound);
       113. Array(ArraySize size); // 선언 형식이 새로워졌습니다.
       114.  
       115. ...
       116.  
       117. };
       118.  
       119. bool operator==(const Array<int>& lhs,
       120. const Array<int>& rhs);
       121. Array<int> a(10); // 문제없습니다. 10(int 타입)이
       122. Array<int> b(10); // ArraySize로 암시적으로 변환됩니다.
       123.  
       124. ...
       125.  
       126. for (int i = 0; i < 10; ++i)
       127. if (a == b[i]) ... // 저런! "a"는 "a[i]"가 되어야 합니다.
       128. // 따라서 이 코드에서 에러가 납니다.
       129.  
       130. // 조건문에서 int는 ArraySize로,
       131. // ArraySize는 Array<int>로
       132. // 암시적으로 변환될 수 있지만
       133. // int가 Array<int>로 변환되려면
       134. // 두 단계를 거쳐야 합니다.
       135.  
       136. // C++에서 두 단계를 암시적으로 변환하는것은
       137. // 금지되어 있습니다.

       
       
       예제 코드 접기
       
       
       

  6. 증가 및 감소 연산자의 전위(prefix)/후위(postfix) 형태를 반드시 구분하자 / 72

     • 증감 연산자를 오버로딩 할 때, 전위형 증감 연산자와 후위형 증감 연산자를 구분하기 위해 후위형 증감 연산자에는 0(int)를 인자로 넘깁니다.

       예제 코드 보기
       
       
       

       1. class UPInt {
       2. public:
       3. UPInt& operator++(void); // 전위 ++
       4. const UPInt operator++(int); // 후위 ++
       6. UPInt& operator--(void); // 전위 --
       7. const UPInt operator--(int); // 후위 --
       9. UPInt& operator+=(int); // UPInt과 int에 대해 마련한
       10. // += 연산자
       11. ...
       13. };
       14. UPInt i;
       15.  
       16. ++i; // i.operator++()를 호출합니다.
       17. i++; // i.operator++(0)를 호출합니다.
       18.  
       19. --i; // i.operator--()를 호출합니다.
       20. i--; // i.operator--(0)를 호출합니다.

       
       
       예제 코드 접기
       
       
       

     • 전위형 증감 연산자와 후위형 증감 연산자는 반환 타입도 구분해야 합니다. 전위형 증감 연산자는 반드시 참조자 타입을 반환해야 하고, 후위형 증감 연산자는 반드시 const 객체 타입을 반환해야 합니다.

       예제 코드 보기
       
       
       

       1. // 전위 형태: 증가시킨 후에 값을 가져옵니다.
       2. UPInt& UPInt::operator++(void)
       3. {
       4. *this += 1; // 증가
       5. return *this; // 값을 가져옵니다.
       6. }
       7.  
       8. // 후위 형태: 값을 가져오고 증가시킵니다.
       9. const UPInt UPInt::operator++(int)
       10. {
       11. const UPInt oldValue = *this; // 값을 가져옵니다.
       12. ++(*this); // 증가(무엇을 쓰나 잘 보세요)
       14. return oldValue; // 미리 가져온 값을
       15. } // 반환합니다.
       16.  
       17. // 보시다시피 후위형 증감 연산자는
       18. // 임시 객체를 반환해야 하기 때문에
       19. // *this의 참조자가 아닌 객체 타입을
       20. // 반환합니다. 하지만 왜 const가
       21. // 되어야 할까요? 다음을 잘 보세요.
       22.  
       23. UPInt i;
       24.  
       25. i++++; // 후위 증가 연산자를
       26. // 두 번 적용합니다.
       27.  
       28. // 이 코드는 다음과 같습니다.
       29.  
       30. i.operator++(0).operator++(0);
       31.  
       32. // 여기서 후위 연산자가 const가 아닌 객체를
       33. // 반환하는 것을 꺼려야 하는 데는 두 가지의 이유가
       34. // 있습니다.
       35.  
       36. // 첫째 이유는 기본 제공(built-in) 타입에
       37. // 대한 증가 연산자의 동작과 맞지 않는다는 것입니다.
       38.  
       39. // "아리송하면 int의 동작원리대로 만들지어다"
       40. // 라는 말을 떠올리시면 되겠습니다.
       41.  
       42. int i;
       43.  
       44. i++++; // 어이 없이 에러!
       45.  
       46. // 두 번째 이유로는 다음을 들 수 있습니다.
       47.  
       48. // 두 번째로 호출된 증가 연산자는
       49. // 첫 번째로 호출된 증가 연산자가
       50. // 반환한 임시 객체를 증가 시킵니다.
       51. // 따라서 i는 2가 아니라 1만 증가합니다.
       52.  
       53. // 보시다시피 매우 직관적이지 못합니다.
       54.  
       55. // 이것을 막는 가장 쉽고 빠른 방법이
       56. // 후위형 증감 연산자의 반환 타입에
       57. // const를 붙이는 것입니다.

       
       
       예제 코드 접기
       
       
       

     • 증감 연산자를 오버로딩 할 때에는 전위형 증감 연산자를 먼저 구현하고, 후위형 증감 연산자는 반드시 전위형 증감 연산자를 사용해서 구현해야 합니다. 이렇게 하면 전위형과 후위형이 똑같은 작업을 하도록 유지시키는 데 유용합니다(코드 중복이 줄어들어 유지 보수성이 좋아집니다).

  7. &&, ||, 혹은 (,)(쉼표 연산자) 연산자는 오버로딩 대상이 절대로 아니다 / 76

     • &&, ||, 혹은 (,)(쉼표 연산자) 연산자들은 원래의 연산자처럼 동작하도록 오버로딩할 수 없습니다. 따라서 이 연산자들은 오버로딩 하지 않는 것이 바람직합니다. 이 연산자들을 오버로딩 하는 경우 원래의 동작과 달라져서 직관적이지도 못하고, 단축평가도 이용할수 없기 때문입니다.

     • &&, || 연산자는 단축평가(short-circuit) 처리를 할 수 있습니다. 하지만 이 연산자들을 오버로딩하게 되면, 본래의 단축평가 의미구조(short-circuit semantics)가 함수호출 의미구조(function call semantics)로 바뀌게 됩니다. 이 때문에 단축평가가 수행되지 않음은 물론이고, 왼쪽 표현식이 오른쪽 표현식보다 먼저 평가된다는 확신도 할 수 없게 됩니다.

       예제 코드 보기
       
       
       

       1. if (expression1 && expression2) ...
       2.  
       3. // 만약 && 연산자를 오버로딩 하지 않았다면,
       4. // 반드시 expression1이 면저 평가되며,
       5. // expression1이 거짓인 경우 expression2는
       6. // 평가되지 않습니다.
       7.  
       8. // 하지만 만약 && 연산자를 오버로딩 한 경우
       9. // 컴파일러에게는 다음과 같은 형태로 보입니다.
       10.  
       11. if (expression1.operator&&(expression2)) ...
       12. // operator&&가
       13. // 멤버 함수일 경우
       14.  
       15. if (operator&&(expression1, expression2)) ...
       16. // operator&&가
       17. // 전역 함수일 경우
       18.  
       19. // 보시는 바와 같이 함수 호출로 취급하여
       20. // 표현식을 평가합니다.
       21.  
       22. // 1. 함수가 호출되기 전에, 모든 인자가
       23. // 평가되어야 하므로 단축평가는 이루어지지
       24. // 않습니다.
       25.  
       26. // 2. 함수 인자의 평가 순서는 표준으로
       27. // 정해져 있지 않습니다. 따라서
       28. // expression2가 먼저 평가될
       29. // 수도 있습니다.

       
       
       예제 코드 접기
       
       
       

     • 쉼표 연산자는 왼쪽 표현식이 먼저 평가된 후 오른쪽 표현식이 평가되며, 전체 표현식의 평가 결과는 오른쪽 표현식의 평가 결과값으로 정해집니다. 하지만 쉼표 연산자 역시 논리 연산자와 마찬가지의 이유로, 오버로딩을 하게 되면 왼쪽 표현식이 오른쪽 표현식보다 먼저 평가된다고 보장할 수 없게 됩니다.

  8. new와 delete의 의미를 정확히 구분하고 이해하자 / 81

     • new 연산자와 operator new 는 다릅니다. new 연산자는 오버로딩 할 수 없으며, 항상 요청한 객체를 담을 수 있는 크기의 메모리를 할당한 후 그 객체의 생성자를 호출하여 할당된 메모리에 객체 초기화를 수행하는 역할만 합니다.

       new 연산자 예제 코드 보기
       
       
       

       1. // 컴파일러는 다음 문장을 만나면,
       2.  
       3. string *ps = new string("Memory Management");
       4.  
       5. // 다음의 내용과 크게 어긋나지 않는 코드를
       6. // 만들어 내야 합니다.
       7.  
       8. void *memory = // string 타입의 객체를
       9. operator new(sizeof(string)); // 담을 크기의 미초기화
       10. // 메모리를 얻어냅니다.
       11.  
       12. *memory에 대해 // 그 메모리에 값을
       13. string::string("Memory Management")를 // 세팅하여(생성자호출)
       14. 호출한다. // 객체를 초기화합니다.
       15.  
       16. string *ps = // ps가 새 객체를 가리키게
       17. static_cast<string*>(memory); // 합니다.
       18.  
       19. // 생성자 호출 단계는 '일개' 프로그래머인
       20. // 여러분이 손 댈 수 있는 부분이 아닙니다.

       
       
       new 연산자 예제 코드 접기
       
       
       

     • operator new 는 new 연산자가 객체를 담을 메모리를 할당하기 위해 호출하는 함수입니다. operator new 를 오버로딩하여 new 연산자가 메모리를 할당하는 방법을 바꿀 수 있습니다.

       사실 operator new의 역할은 malloc과 마찬가지로 메모리만 할당하는 것뿐입니다.
       
       operator new 예제 코드 보기
       
       
       

       1. // operator new 함수는 대개
       2. // 다음과 같이 선언됩니다.
       3.  
       4. void * operator new(size_t size);
       5.  
       6. // operator new 함수를 직접 호출하려면
       7. // 다음과 같이 코드를 작성할 수 있습니다.
       8.  
       9. void *rawMemory = operator new(sizeof(string));
       10.  
       11. // 이렇게 하면, operator new 는
       12. // string타입의 객체를 담을 수 있는
       13. // 메모리 덩어리를 할당해서 그 메모리의
       14. // 포인터를 반환합니다.

       
       
       operator new 예제 코드 접기
       
       
       

     • 메모리 지정 new(Placement new) 함수를 이용하면 이미 가지고 있는 메모리(할당받은 미초기화 메모리)에 원하는 객체의 생성자를 호출하여 객체를 생성할 수 있습니다. 메모리 지정 new 가 사용되는 다른 예제는 항목 4 에서 찾을 수 있습니다.

       메모리 지정 new 예제 코드 보기
       
       
       

       1. // 메모리 지정 new(placement new)를
       2. // 사용하기 위해서 포함해야 하는 헤더입니다.
       3. #include <new>
       4.  
       5. class Widget {
       6. public:
       7. Widget(int widgetSize);
       8. ...
       9. };
       10.  
       11. Widget * constructWidgetInBuffer(void *buffer,
       12. int widgetSize)
       13. {
       14. return new (buffer) Widget(widgetSize); // 메모리 지정 new
       15. }
       16.  
       17. // buffer가 가리키는 메모리 공간을,
       18. // Widget의 생성자를 호출하여
       19. // 초기화 합니다.
       20.  
       21. // 메모리 지정 new의 선언 형태는
       22. // 다음과 같습니다.
       23.  
       24. void * operator new(size_t, void *location)
       25. {
       26. return location;
       27. }
       28.  
       29. // operator new의 첫 번째 인자는 항상
       30. // size_t 이어야 하기 때문에 size_t 인자를
       31. // 사용하지 않아도 넣어 줍니다.
       32. // 후위식 증감 연산자와 비슷하죠.
       33.  
       34. // 어떤 메모리에 객체를 생성하는 용도에
       35. // 메모리 지정 new를 사용한 경우에는,
       36. // 그 메모리에는 절대로 delete 연산자를
       37. // 써서는 안 됩니다.
       38.  
       39. // 위치지정 new가 반환하는 메모리는
       40. // 원천적으로 operator new에 의해
       41. // 할당된 메모리가 아닙니다.
       42.  
       43. // 위치 지정 new는 자신에게 넘어온
       44. // 포인터를 그냥 반환했을 뿐이고요.
       45.  
       46. // 이 포인터가 어디서 왔는지 누가 알겠습니까?
       47. // 생성자가 한 일을 되돌려 놓으려면
       48. // 그 객체의 소멸자를 직접 호출할 수밖에
       49. // 없습니다.
       50.  
       51.  
       52. // 공유 메모리에 메모리를 할당하고 해제하는
       53. // 함수
       54. void * mallocShared(size_t size);
       55. void freeShared(void *memory);
       56.  
       57. void *sharedMemory = mallocShared(sizeof(Widget));
       58.  
       59. Widget *pw = // 앞의 경우와 마찬가지로
       60. constructWidgetInBuffer(sharedMemory, 10) // 메모리 지정 new가
       61. // 사용됩니다.
       62. ...
       63. delete pw; // 결과 예측 불능! sharedMemory의 어머니는
       64. // operator new가 아닌 mallocShared입니다.
       65.  
       66. pw->~Widget(); // 문제없음. pw가 가리킨 Widget 객체에 대해
       67. // 소멸자를 호출하지만, 이 객체가 자리잡은
       68. // 메모리는 해제하지 않습니다.
       69.  
       70. freeShared(pw); // 문제없음. pw가 가리킨 메모리를 해제하지만,
       71. // 소멸자는 호출하지 않습니다.

       
       
       메모리 지정 new 예제 코드 접기
       
       
       

     • delete 연산자도 new 연산자와 마찬가지로 내부에서 operator delete 라는 함수를 호출합니다. new 연산자와 마찬가지로 delete 연산자도 오버로딩 할 수 없고 operator delete 함수를 오버로딩 하여, 메모리를 해제하는 방법을 변경할 수 있습니다.

       operator new와 operator delete는 말하자면, C++ 버전의 malloc 과 free 인 것입니다.
       
       예제 코드 보기
       
       
       

       1. string *ps;
       2. ...
       3. delete ps; // delete 연산자를 사용합니다.
       4.  
       5. // operator delete 함수는 다음과 같이
       6. // 선언되어 있습니다.
       7.  
       8. void operator delete(void *memoryToBeDeallocated);
       9.  
       10. // 컴파일러는 다음 문장
       11.  
       12. delete ps;
       13.  
       14. // 을 보고 다음과 비스무레한 코드를 만듭니다.
       15.  
       16. ps->~string(); // 그 객체의 소멸자를 호출합니다.
       17. operator delete(ps); // 그 객체가 자리잡은
       18. // 메모리를 해제합니다.
       19.  
       20. // 미초기화 메모리만을 가지고 어떤 일을
       21. // 할 때에는 new와 delete 연산자를
       22. // 건너 뛰어야 합니다. 그 대신에
       23. // 메모리를 얻을 때는 operator new를,
       24. // 그 메모리를 해제할 때에는 operator delete를
       25. // 호출하라는 뜻이죠.
       26.  
       27. void *buffer = // 50개의 문자를 담을 수 있는
       28. operator new(50 * sizeof(char)); // 메모리를 할당합니다. 그리고
       29. // 생성자는 호출하지 않습니다.
       30. ...
       31. operator delete(buffer); // 메모리를 해제합니다.
       32. // 소멸자는 호출하지 않습니다.

       
       
       예제 코드 접기
       
       
       

     • 배열을 할당하는 경우는 어떨까요? 배열을 할당하는 경우 사용되는 new 연산자는 단일 객체를 할당할 때 쓰는 new 연산자와 조금 다릅니다. 배열을 할당하는 new 연산자는 내부에서 operator new 대신에 operator new[] 를 호출합니다. 또 다른점은 배열의 각 요소에 대해 일일이 생성자를 호출해야 한다는 점이 있습니다. 배열을 해제하는 delete 연산자도 마찬가지로 내부적으로 operator delete 대신 operator delete[]를 호출하고, 배열의 각 요소에 대해 일일이 소멸자를 호출해야 합니다.

       operator new[]와 operator delete[]도 오버로딩하여 원하는 방법으로 메모리를 할당하고 해제하도록 변경할 수 있습니다. 하지만 오버로딩 방법에는 제한이 조금 있는데 여기에 대한 자세한 설명은 다른 좋은 C++ 책에서 찾는 게 좋겠습니다.

• Chapter 3   예외(Exceptions)

  9. 리소스 누수를 피하는 방법의 정공(正攻)은 소멸자이다 / 91

     • 할당받은 자원을 해제하기 전에 예외가 발생할 경우, 할당받은 자원의 누수가 발생하게 됩니다. 예외를 받아 할당받은 자원을 해제한 뒤 예외를 다시 전달하는 방법이 있지만, 그다지 깔끔한 방법은 아닙니다. 가장 좋은 방법은 자원 관리 객체의 소멸자를 이용해 자동으로 할당받은 자원을 해제하도록 만드는 것입니다.

       자원 관리 객체 예제 코드 보기
       
       
       

       1. // auto_ptr의 대략적인 구조는 다음과 같습니다.
       2. template <typename T>
       3. class auto_ptr {
       4. public:
       5. auto_ptr(T *p = 0) : ptr(p) {} // 객체에 대한 포인터를 ptr에 저장합니다.
       6. ~auto_ptr(void) { delete ptr; } // 객체에 대한 ptr을 삭제합니다.
       8. private:
       9. T *ptr; // 객체에 대한 미초기화 포인터
       10. };
       11.  
       12. // 실제로 표준 라이브러리에 구현된 auto_ptr은
       13. // 이것보다 훨씬 잘 만들어져 있습니다.
       14.  
       15. // 위의 코드를 제대로 쓰려면 복사 생성자,
       16. // 대입 연산자, 포인터 동작을 흉내내는 함수들을
       17. // 추가해야 합니다. 자세한 이야기는
       18. // 항목 28을 참고하세요.

       
       
       자원 관리 객체 예제 코드 접기
       
       
       

  10. 생성자에서는 리소스 누수가 일어나지 않게 하자 / 97

      • C++은 생성이 완료된(fully constructed) 객체만을 안전하게 소멸시킵니다(소멸자를 호출합니다). 그런데, 생성자가 실행을 마치기 전에는 생성 작업이 완료되었다고 간주하지 않습니다. 따라서, 어떤 객체의 생성자가 호출되어 객체가 생성되는 도중 예외가 발생하면 그 객체의 소멸자는 호출되지 않습니다. 포인터가 아닌 멤버의 경우에는, 클래스 생성자가 호출되기 전에 이미 데이터 멤버의 초기화가 이루어지기 때문에, 클래스 생성자의 몸체가 실행될 때는 이미 초기화(생성)가 완료되어 있습니다. 따라서 클래스가 소멸될 때 자동으로 소멸되므로 별도의 조치가 필요하지 않습니다.

        예제 코드 보기
        
        
        

        1. class Image { // 이미지 데이터를 위한 클래스
        2. public:
        3. Image(const string& imageDataFileName);
        4. ...
        5. };
        6.  
        7. class AudioClip { // 오디오 데이터를 위한 클래스
        8. public:
        9. AudioClip(const string& audioDataFileName);
        10. ...
        11. };
        12.  
        13. class PhoneNumber { ... }; // 전화번호를 저장하는 클래스
        14. class BookEntry { // 주소록의 주소 엔트리
        15. public: // 하나를 저장하는 클래스
        16. BookEntry(const string& name,
        17.   const string& address = "",
        18.   const string& imageFileName = "",
        19.   const string& audioClipFileName = "");
        20. ~BookEntry(void);
        22. // 전화 번호를 추가하는 함수
        23. void addPhoneNumber(const PhoneNumber& number);
        24. ...
        26. private:
        27. string theName; // 사람 이름
        28. string theAddress; // 주소
        29. list<PhoneNumber> thePhones // 전화 번호(여러 개)
        30. Image *theImage; // 사진 이미지
        31. AudioClip *theAudioClip; // 목소리 오디오 클립
        32. };
        33.  
        34. // BookEntry의 생성자와 소멸자는
        35. // 다음과 같이 생겼을 것입니다.
        36.  
        37. BookEntry::BookEntry(const string& name,
        38. const string& address,
        39. const string& imageFileName,
        40. const string& audioClipFileName)
        41. : theName(name), theAddress(address),
        42. theImage(0), theAudioClip(0)
        43. {
        44. if (imageFileName != "") {
        45. theImage = new Image(imageFileName);
        46. }
        47. if (audioClipFileName != "") {
        48. // 아래 문장에서 예외가 발생하면 메모리 누수가 발생합니다.
        49. theAudioClip = new AudioClip(audioClipFileName);
        50. }
        51. }
        52.  
        53. BookEntry::~BookEntry(void)
        54. {
        55. delete theImage;
        56. delete theAudioClip;
        57. }
        58.  
        59. // 이 때 생성자의 new AudioClip(audioClipFileName);
        60. // 부분에서 예외가 발생하면, theImage를 위해 할당한 동적 메모리가
        61. // 누출됩니다. 왜냐하면 BookEntry의 생성자가 동작하는
        62. // 도중에 예외가 발생하였기 때문에 BookEntry의 소멸자가
        63. // 호출되지 않기 때문입니다.
        64.  
        65. // 심지어 다음과 같은 경우에도 BookEntry의 소멸자는
        66. // 호출되지 않습니다.
        67.  
        68. void testBookEntryClass(void)
        69. {
        70. BookEntry *pb = 0;
        72. try {
        73. pb = new BookEntry("Addison-Wesley Publishing Company",
        74. "One Jacob Way, Reading, MA 01867");
        75. ...
        76. }
        77. catch (...) { // 모든 예외를 받아 처리합니다.
        79. delete pb; // 예외가 발생했을 때
        80. // pb를 삭제합니다.
        82. throw; // 이 함수를 호출한 곳으로
        83. } // 예외를 전파합니다.
        85. delete pb; // 정상적으로 pb를 삭제합니다.
        86. };
        87.  
        88. // new 연산자가 메모리를 할당하지 못하여 예외가 발생한 경우,
        89. // pb에 메모리의 주소가 대입조차 되지 않습니다.
        90. // 따라서 catch 블록의 delete 연산자는 널 포인터를
        91. // 해제(아무 일도 하지 않음)하고 pb의 소멸자는
        92. // 호출되지 않습니다.

        
        
        예제 코드 접기
        
        
        

      • 간단한 해결 방법 중 하나는, 가능한 모든 예외를 받고(catch) 마무리 코드를 작성한 다음, 받은 예외를 다시 전파하는 것입니다. 마무리 코드가 소멸자의 코드와 비슷하기 때문에 공통된 부분은 별도의 도우미 함수로 만들고, 소멸자와 생성자에서 이 함수를 호출하도록 만들 수 있습니다.

        예제 코드 보기
        
        
        

        1. BookEntry::BookEntry(const string& name,
        2. const string& address,
        3. const string& imageFileName,
        4. const string& audioClipFileName)
        5. : theName(name), theAddress(address),
        6. theImage(0), theAudioClip(0)
        7. {
        8. try { // 새로 만들어진 try 블록
        9. if (imageFileName != "") {
        10. theImage = new Image(imageFileName);
        11. }
        13. if (audioClipFileName != "") {
        14. theAudioClip = new AudioClip(audioClipFileName);
        15. }
        16. }
        17. catch (...) { // 모든 예외를 받습니다.
        19. delete theImage; // 필요한 마무리 동작을
        20. delete theAudioClip; // 취합니다.
        22. throw; // 받은 예외를 전파합니다.
        23. }
        24. }
        25.  
        26. // catch 블록에 쓰인 문장이 BookEntry의 소멸자와
        27. // 거의 똑같습니다. 즉 코드가 중복되고 있죠.
        28.  
        29. // 이것을 해결하기 위해 중복된 코드를 뽑아다가
        30. // 별도의 보조 함수안에 넣고, 생성자와 소멸자가
        31. // 이것을 호출하도록 만듭시다.
        32.  
        33. class BookEntry {
        34. public:
        35. ... // 이전과 같습니다.
        36. private:
        37. ...
        38. void cleanup(void); // 공통적인 마무리 작업용 함수
        39. };
        40.  
        41. void BookEntry::cleanup(void)
        42. {
        43. delete theImage;
        44. delete theAudioClip;
        45. }
        46.  
        47. BookEntry::BookEntry(const string& name,
        48. const string& address,
        49. const string& imageFileName,
        50. const string& audioClipFileName)
        51. : theName(name), theAddress(address),
        52. theImage(0), theAudioClip(0)
        53. {
        54. try {
        55. ... // 이전과 같습니다.
        56. }
        57. catch (...) {
        58. cleanup(); // 리소스를 해제합니다.
        59. throw; // 예외를 전파합니다.
        60. }
        61. }
        62.  
        63. BookEntry::~BookEntry(void)
        64. {
        65. cleanup();
        66. }

        
        
        예제 코드 접기
        
        
        

      • 만약 자원을 상수 포인터에 담아야 한다면 조금 이야기가 달라집니다. 상수 포인터는 초기화 할 때 딱 한 번만 값을 줄 수 있기 때문입니다. 이런 경우에는 포인터의 초기 값을 반환해주는 private 멤버 함수를 만들어 놓고, 그 함수안에 try-catch 블록을 넣어 처리하는 방법을 써야 합니다.

        예제 코드 보기
        
        
        

        1. //-------------------------------------------------------------------
        2. // 잘못된 예시
        3. class BookEntry {
        4. public:
        5. ...
        6. private:
        7. ...
        8. Image * const theImage;
        9. AudioClip * const theAudioClip;
        10. };
        11.  
        12. // 예외가 발생하면
        13. // 리소스 누수를 일으키는 구현 코드
        14. BookEntry::BookEntry(const string& name,
        15. const string& address,
        16. const string& imageFileName,
        17. const string& audioClipFileName)
        18. : theName(name), theAddress(address),
        19. theImage(imageFileName != ""
        20. ? new Image(imageFileName)
        21. : 0),
        22. theAudioClip(audioClipFileName != ""
        23. ? new AudioClip(audioClipFileName)
        24. : 0)
        25. {}
        26.  
        27. // 이 코드는 처음의 문제를 그대로 가지고 있습니다.
        28. // 게다가 try-catch 블록을 어떻게 넣어 해결할
        29. // 수도 없습니다.
        30.  
        31.  
        32. //-------------------------------------------------------------------
        33. // 이런 경우 상수 포인터를 초기화할 값을 반환하는
        34. // private 멤버 함수를 만들고,
        35. // 이 함수 안에 try-catch 블록을 넣어
        36. // 처리하도록 만들면 됩니다.
        37. class BookEntry {
        38. public:
        39. ... // 이전과 같습니다.
        40. private:
        41. ... // 데이터 멤버 역시 이전과 같습니다.
        42. Image * initImage(const string& imageFileName);
        43. AudioClip * initAudioClip(const string&
        44. audioClipFileName);
        45. };
        46.  
        47. BookEntry::BookEntry(const string& name,
        48. const string& address,
        49. const string& imageFileName,
        50. const string& audioClipFileName)
        51. : theName(name), theAddress(address),
        52. theImage(initImage(imageFileName)),
        53. theAudioClip(initAudioClip(audioClipFileName))
        54. {}
        55.  
        56. // theImage가 먼저 초기화 되기 때문에, 이 초기화가
        57. // 실패하더라도 리소스 누수가 생길 걱정은 안 해도 됩니다.
        58. // 결국 이 함수는 예외를 처리하지 않습니다.
        59. Image * BookEntry::initImage(const string& imageFileName)
        60. {
        61. if (imageFileName != "") return new Image(imageFileName);
        62. else return 0;
        63. }
        64.  
        65. // theAudioClip은 두 번째로 초기화되기 때문에,
        66. // theAudioClip이 초기화되는 도중에 예외가 발생하면
        67. // theImage의 리소스를 반드시 해제해야 합니다. 따라서
        68. // 이 함수에는 try...catch 구문이 쓰였습니다.
        69. AudioClip * BookEntry::initAudioClip(const string&
        70. audioClipFileName)
        71. {
        72. try {
        73. if (audioClipFileName != "") {
        74. return new AudioClip(audioClipFileName);
        75. }
        76. else return 0;
        77. }
        78. catch (...) {
        79. delete theImage;
        80. throw;
        81. }
        82. }

        
        
        예제 코드 접기
        
        
        

      • 이보다 더 좋은 해결책은 항목 9에서 제시한 방법을 따라, 자원 관리 객체를 이용하는 것입니다. 다시말해 위에서 살펴본 예제에서 theImage와 theAudioClip을 원시 포인터 타입 대신 auto_ptr로 바꾸어도 큰 문제가 없을 것입니다.

        예제 코드 보기
        
        
        

        1. class BookEntry {
        2. public:
        3. ...
        4. private:
        5. ...
        6. const auto_ptr<Image> theImage;
        7. const auto_ptr<AudioClip> theAudioClip;
        8. };
        9.  
        10. BookEntry::BookEntry(const string& name,
        11. const string& address,
        12. const string& imageFileName,
        13. const string& audioClipFileName)
        14. : theName(name), theAddress(address),
        15. theImage(imageFileName != ""
        16. ? new Image(imageFileName)
        17. : 0),
        18. theAudioClip(audioClipFileName != ""
        19. ? new AudioClip(audioClipFileName)
        20. : 0)
        21. {}
        22.  
        23. // theAudioClip을 초기화 하다가 예외가
        24. // 발생하더라도 theImage는 이미 생성 과정이
        25. // 완료된 객체이기 때문에, 자동으로 소멸됩니다.
        26.  
        27. // 게다가, theImage와 theAudioClip은
        28. // 엄연한 객체이기 때문에 BookEntry가 소멸될때
        29. // 자동으로 소멸됩니다. 따라서 BookEntry의
        30. // 소멸자가 할 일이 없어집니다.
        31.  
        32. BookEntry::~BookEntry(void)
        33. {} // 할 것이 젼혀 없네요!

        
        
        예제 코드 접기
        
        
        

  11. 소멸자에서는 예외가 탈출하지 못하게 하자 / 107

      • 소멸자가 호출되는 경우는 두 가지로 나눌 수 있습니다. 첫째 경우는 객체가 통상적인 조건에서 소멸되는 것인데, 통상적인 조건이란 지역변수로 선언된 객체가 유효범위(scope)를 벗어났을 때와 객체가 직접 삭제(delete)될 때입니다. 둘째 경우는 예외 처리 메커니즘에 의해 객체가 소멸되는 것인데, 예외 전파(exception propagation) 과정의 일부분으로 스택 되감기가 진행될 때가 여기에 속합니다. 즉 소멸자가 호출되었을 때 예외가 발생된 상태일 수도 있고 아닐 수도 있습니다.

      • 어떤 예외에 대한 처리가 진행되고 있는 동안 또 다른 예외 때문에 프로그램 흐름이 소멸자 함수를 떠나면, C++는 terminate란 함수를 호출하게 되어 있습니다. 이 함수가 하는 일은 이름 그대로 프로그램의 실행을 끝장내는(terminate) 것입니다. 게다가 아주 칼같이 끝내 버리기 때문에, 지역 객체조차도 소멸되지 않습니다. 이러한 이유로 소멸자에서는 예외가 탈출하지 못하도록 만들어야 합니다.

        예제 코드 보기
        
        
        

        1. class Session {
        2. public:
        3. Session(void);
        4. ~Session(void);
        5. ...
        6. private:
        7. static void logCreation(Session *objAddr);
        8. static void logDestruction(Session *objAddr);
        9. };
        10.  
        11. // logCreation과 logDestruction 함수는
        12. // 객체 생성과 소멸 시기를 기록해 놓는 데에 사용합니다.
        13. // 따라서 소멸자는 다음과 같이 생겼을 것입니다.
        14.  
        15. Session::~Session(void)
        16. {
        17. logDestruction(this);
        18. }
        19.  
        20. // 하지만 logDestruction 함수에서
        21. // 예외가 발생할 수 있다면 앞에서 설명한
        22. // 이유로 인해 문제가 될 수 있습니다.
        23.  
        24. // 한 가지 해결 방법은 try-catch 블록을
        25. // 사용하는 것입니다.
        26.  
        27. Session::~Session(void)
        28. {
        29. try {
        30. logDestruction();
        31. }
        32. catch (...) {
        33. cerr << "Unable to log destruction of Session object "
        34. << "at address "
        35. << this
        36. << ".\n";
        37. }
        38. }
        39.  
        40. // 하지만 operator<< 중의 하나에서 예외가
        41. // 발생할 수 있기 때문에 이 구현 역시 그다지
        42. // 좋지 못한 구현이라고 할 수 있습니다.
        43.  
        44. // 이런 경우 logDestruction이 예외를
        45. // 일으키면 그냥 로깅을 하지 않는 편이 바람직합니다.
        46.  
        47. Session::~Session(void)
        48. {
        49. try {
        50. logDestruction();
        51. }
        52. catch (...) {} // 이 catch 문이 예외가 소멸자 밖으로 빠져나가지 못하게 합니다.
        53. }

        
        
        예제 코드 접기
        
        
        

      • 예외가 소멸자를 떠나 전파되도록 내버려 두는 일이 나쁜 이유가 하나 더 있습니다. 소멸자에서 발생된 예외가 소멸자에서 처리되지 않으면, 소멸자는 실행이 끝나지 않은 상태로 남습니다(실제로, 예외가 발생된 그 지점에 딱 서 버리죠). 실행을 마치지 못한 소멸자는 자신에게 주어진 역할을 완수하지 못합니다.

        예제 코드 보기
        
        
        

        1. // 예를 들어 세션 생성과 함께
        2. // 데이터베이스 트랜잭션을 시작하고, 세션이
        3. // 소멸될 때 데이터베이스 트랜잭션을 끝내도록
        4. // Session 클래스가 수정되었다고 가정해 봅시다.
        5.  
        6. // 생성자와 소멸자는 다음과 같이 생겼을 것입니다.
        7.  
        8. Session::Session(void) // 주변 상황을 간단히 하기 위해
        9. { // 이 생성자는 예외 처리를 하지 않도록
        10. // 하였습니다.
        11. logCreation(this);
        12. startTransaction(); // DB 트랜잭션을 시작합니다.
        13. }
        14.  
        15. Session::~Session(void)
        16. {
        17. logDestruction(this);
        18. endTransaction(); // DB 트랜잭션을 끝냅니다.
        19. }
        20.  
        21. // 여기서 logDestruction이 예외를 일으키면
        22. // Session 생성자에서 시작된 데이터베이스
        23. // 트랜잭션은 끝나지 않은 채로 남습니다.
        24.  
        25. // 함수 호출 순서를 바꾸는 것은 의미가 없습니다.
        26. // endTransaction도 예외를 일으킬 수
        27. // 있기 때문입니다.
        28.  
        29. // 결국 try-catch 블록을 이용하는 수 밖에는
        30. // 답이 없습니다.

        
        
        예제 코드 접기
        
        
        

  12. 예외 발생이 매개변수 전달 혹은 가상 함수 호출과 어떻게 다른지를 이해하자 / 110

      • 예외 객체는 항상 복사됩니다. 특히 값에 의한 예외 처리의 경우에는 두 번 복사됩니다(함수 매개변수로 전달되는 객체보다 한번 더 복사가 일어납니다).

        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 스트림으로부터 Widget의 값을 읽는 함수
        3. istream operator>>(istream& s, Widget& w);
        4.  
        5. void passAndThrowWidget(void)
        6. {
        7. Widget localWidget;
        9. cin >> localWidget; // operator>>에 localWidget을 전달합니다.
        11. throw localWidget; // localWidget을 예외로 발생시킵니다.
        12. }
        13.  
        14. // 함수 호출과 달리 예외는 catch된 후,
        15. // throw한 위치로 되돌아 오지 않습니다.
        16.  
        17. // 때문에 localWidget은 던져진 후
        18. // passAndThrowWidget의 범위에서
        19. // 벗어나므로 소멸되어 버립니다.
        20.  
        21. // 따라서 예외를 던질 때에는 그 객체가 아닌
        22. // 객체의 복사본이 전달됩니다. 설령
        23.  
        24. // catch에서 참조자로 객체를 받는다고 해도
        25. // 마찬가지입니다.
        26.  
        27. // 이것은 지역 객체가 아니더라도 마찬가지로
        28. // 적용됩니다.
        29.  
        30. void passAndThrowWidget(void)
        31. {
        32. static Widget localWidget;
        34. cin >> localWidget;
        36. throw localWidget;
        37. }
        38.  
        39. // localWidget이 정적 객체가 되어서
        40. // 프로그램이 종료될 때 까지 소멸되지 않지만
        41. // 여전히 예외 발생시에는 localWidget의
        42. // 복사본이 던져집니다.
        43.  
        44.  
        45. //-----------------------------------------------------------------------------
        46. // C++의 객체 복사는 항상 정적 타입에 따라
        47. // 복사 생성자가 호출됩니다.
        48.  
        49. // 예를 들면
        50. class Widget { ... };
        51. class SpecialWidget: public Widget { ... };
        52. void passAndThrowWidget(void)
        53. {
        54. SpecialWidget localSpecialWidget;
        56. ...
        58. Widget& rw = localSpecialWidget; // rw는
        59. // SpecialWidget를 참조합니다.
        61. throw rw; // 이 throw 문으로 발생되는
        62. // 예외의 타입은 다름 아닌
        63. } // Widget입니다!!
        64.  
        65. // 이렇게 rw와 같이 기본 클래스 타입의
        66. // 참조자에 담긴 객체가 파생 클래스 타입이더라도
        67. // rw를 통해 호출되는 복사 생성자는
        68. // rw를 Widget타입의 객체로 간주합니다.
        69.  
        70. // 객체의 동적 타입에 따라 복사할 수 있는
        71. // 방법도 있는데 이는 항목 25를 참고하세요.
        72.  
        73.  
        74. //-----------------------------------------------------------------------------
        75. // "예외는 원래 객체의 사본으로서 발생된다"는
        76. // 사실 때문에, catch 블록에서 예외를 전파하는
        77. // 방법에도 신경쓸 수 밖에 없게 됩니다.
        78.  
        79. // 다음 두 catch 블록은 똑같은 일을 할 것
        80. // 같지만 실은 두번째 경우에는 쓸데없는
        81. // 객체의 복사가 한 번 더 일어납니다.
        82.  
        83. catch (Widget& w) // Widget& 예외를 받습니다.
        84. {
        85. ... // 이 예외를 처리합니다.
        86. throw; // 이 예외 자체를 "그대로" 중계하여
        87. } // 예외 전파가 이루어져 있도록 합니다.
        88.  
        89. catch (Widget& w) // Widget& 예외를 받습니다.
        90. {
        91. ... // 이 예외를 처리합니다.
        92. throw w; // 처리한 예외의 "사본"을 발생시켜
        93. } // 예외 전파가 이루어지도록 합니다.
        94.  
        95. // 불필요한 객체의 복사 외에도 차이점이 있습니다.
        96.  
        97. // 첫번째 경우에는 w에 담긴 객체가 SpecialWidget인
        98. // 경우 그대로 SpecialWidget이 예외로 전파됩니다.
        99.  
        100. // 반면 두번째 경우에는 예외를 전파하면서 w의 사본을
        101. // 만들게 되므로, 전파되는 예외의 타입은 Widget이
        102. // 됩니다.
        103.  
        104.  
        105. //-----------------------------------------------------------------------------
        106. // 정리해 봅시다. Widget 객체를 받아 내도록
        107. // 선언할 수 있는 catch 구문은 세가지가 있습니다.
        108.  
        109. catch (Widget w) ... // 값에 의한 예외 처리
        110. catch (Widget& w) ... // 참조에 의한 예외 처리
        111. catch (const Widget& w) ... // 상수 객체에 대한 참조자
        112. // (상수 참조자)에 의한 예외 처리
        113.  
        114. // 우선 예외로서 발생되는 객체(사본으로 만들어진 임시 객체)
        115. // 는 굳이 상수 참조자로서 넘어갈 필요가 없습니다.
        116.  
        117. // 비상수 참조자에 대한 임시 객체는 함수 호출 시의
        118. // 매개변수로 사용될 수 없지만(항목 19 참조),
        119. // 예외의 경우에는 가능합니다.
        120.  
        121. // 함수 호출에서 값에 의한 전달의 경우 매개변수 전달 시
        122. // 객체의 복사가 일어납니다. 이것은 예외 전달 시에도
        123. // 마찬가지로 적용됩니다.
        124.  
        125. // 즉 값에 의한 전달로 예외를 받게 되면,
        126. // 객체를 던질 때 그 객체의 복사본을 만들어 던지고
        127. // 받을때도 값에 의한 전달로 인해 복사가 일어나므로
        128. // 객체의 복사가 총 두 번 일어나게 됩니다.
        129.  
        130.  
        131. //-----------------------------------------------------------------------------
        132. // 포인터를 예외로 받는 경우에는
        133. // 함수 호출에서의 포인터에 의한 전달과
        134. // 마찬가지로 포인터의 사본(주소값)이 전달됩니다.
        135.  
        136. // 하지만 포인터는 이 예제 처음에서 보았듯이
        137. // catch쪽으로 보내봐야 이득이 없습니다.
        138.  
        139. // 어차피 예외에 의해 프로그램 흐름이
        140. // 지역 객체의 유효범위를 떠나면 그
        141. // 지역 객체는 소멸되니까요.
        142.  
        143. // 굳이 포인터를 써야 겠다면 new연산자로
        144. // 할당한 객체를 던지고, catch 블록에서
        145. // delete 해 줘야 합니다.

        
        
        예제 코드 접기
        
        
        

      • 발생되는 예외는 전달되는 매개변수에 비해 타입변환을 거치는 가지수가 적습니다. 예외에서 타입변환은 파생 클래스에서 기본 클래스로의 변환과, 타입이 있는 포인터에서 타입이 없는 포인터(void*)로의 변환만 이루어 집니다.

        예제 코드 보기
        
        
        

        1. // 함수 호출의 경우 다음 문장은
        2. // 아무런 문제를 일으키지 않습니다.
        3.  
        4. double sqrt(double);
        5.  
        6. int i;
        7. double sqrtOfi = sqrt(i);
        8.  
        9. // int 타입 i가 double 타입으로
        10. // 암시적으로 변환이 일어납니다.
        11.  
        12. // 하지만 예외를 전달할 때는 좀 다릅니다.
        13.  
        14. void f(int value)
        15. {
        16. try {
        17. if (someFunction()) { // someFunction()이 true를 반환하면
        18. throw value; // int 타입의 예외를 발생시킵니다.
        19. }
        20. ...
        21. }
        22. catch (double d) { // 여기서는 double 타입의 예외를
        23. ... // 처리합니다.
        24. }
        25. }
        26.  
        27. // 이 경우 double 타입의 예외를
        28. // 받는 catch 블록은 int 타입의
        29. // 예외를 받지 못합니다.
        30.  
        31. // 예외 전달시 타입 변환은 두가지만 허용됩니다.
        32.  
        33. // 첫번째는 상속 기반의 변환입니다.
        34. // 기본 클래스 타입의 객체를 예외를 받는
        35. // catch 블록은 파생 클래스 타입의
        36. // 객체를 예외로 받을 수 있습니다.
        37. // 예를 들어 다음 catch 블록은
        38.  
        39. catch (exception& e) { ... }
        40.  
        41. // exception으로부터 파생된 모든
        42. // 타입의 객체를 잡아냅니다.
        43.  
        44. // 두번째는 타입이 있는 포인터로부터
        45. // 타입이 없는 포인터(void*)로 바꾸는
        46. // 경우입니다.
        47. // 예를 들어 다음 catch 블록은
        48.  
        49. catch (const void*) { ... }
        50.  
        51. // 포인터이기만 하면 무조건 잡아냅니다.

        
        
        예제 코드 접기
        
        
        

      • catch 문은 소스 코드에 등장한 순서대로 동작하고, 예외를 처리할 수 있는 catch 문 중 가장 첫째 것이 선택됩니다. 하지만 어떤 객체를 통해서 가상 함수를 호출할 때에는, 소스 코드에 등장한 순서와 관계 없이 그 객체의 동적 타입에 가장 가까운 클래스에 정의된 가상 함수가 호출됩니다.

        예제 코드 보기
        
        
        

        1. // catch 문은 소스코드에 등장한 순서대로
        2. // 사용됩니다. 예를 들면
        3.  
        4. try {
        5. ...
        6. }
        7. catch (logic_error& ex) { // 이 블록은 logic_error 타입의
        8. ... // 예외를 모두 도맡아 처리합니다.
        9. } // 심지어 이 클래스의 파생 클래스
        10. // 타입의 예외까지 처리합니다.
        11.  
        12. catch (invalid_argument& ex) { // 이 블록은 절대로 실행되지
        13. ... // 않습니다. 왜냐하면
        14. } // invalid_argument 타입의 예외가
        15. // 처리되는 블록은 바로 위의
        16. // catch 블록이기 때문입니다.
        17.  
        18. // ※ invalid_argument 는 logic_error 로부터
        19. // 파생되었습니다.
        20.  
        21. // 위와 같이 코드를 짜면 컴파일러는 경고 혹은 오류를
        22. // 냅니다. 위의 코드를 정상적으로 작동하도록 수정하면
        23. // 다음과 같이 될 것입니다.
        24.  
        25. try {
        26. ...
        27. }
        28. catch (invalid_argument& ex) { // invalid_argument 예외를
        29. ... // 여기서 처리합니다.
        30. }
        31. catch (logic_error& ex) { // 모든 logic_error 예외를
        32. ... // 여기서 처리합니다.
        33. }

        
        
        예제 코드 접기
        
        
        

  13. 발생한 예외는 참조자로 받아내자 / 120

      • 이론상, 예외 객체를 catch 문으로 전달하는 데 있어서는 포인터에 의한 예외받기가 가장 효율적이어야 합니다(항목 15를 보세요). 왜냐하면, 예외를 포인터로 발생시키면 객체의 복사 없이도 전달이 이루어지기 때문입니다(항목 12에서 이야기 했습니다).

        하지만 포인터로 예외를 전달하는 경우, 비정적 지역 객체의 포인터를 전달할 수 있는 문제가 발생합니다. 비정적 지역 객체의 포인터를 받을 시점에는 이미 그 포인터가 가리키는 객체는 소멸되었을 것입니다. 이를 해결하기 위해서는 예외를 위한 정적 지역 객체(혹은 전역 객체)를 만들고 이 정적 지역 객체의 주소를 예외로 전달하거나, new 연산자로 예외 객체를 생성하여 전달해야 합니다. 하지만 이 경우 catch 블록에서 delete를 해야 할지 말아야 할지 또다시 고민해야 하는 문제가 발생합니다. catch 블록에서는 전달받은 포인터가 가리키는 객체가 new 연산자로 생성한 객체인지, 정적 지역 객체 혹은 전역 객체인지를 알 방법이 없습니다. 따라서 포인터로 예외를 전달하는 것은 그렇게 좋지 못한 생각입니다.

      • 포인터를 전달하지 않는 방법으로는 '값에 의한 예외받기(catch-by-value)' 가 있습니다. 하지만 값으로 예외를 전달하면 전달한 객체가 두 번이나 복사되어 비효율적이며, 공포의 슬라이스 문제(slicing problem)가 도사리고 있습니다.

        ※ 슬라이스 문제: 발생 시에는 파생 클래스의 객체였다가, 기본 클래스의 객체를 받는 catch 문에 들어가면서 파생 클래스 부분에 추가되었던 데이터가 싹둑 잘려져 나가는(sliced off) 현상으로, 파생 클래스의 객체가 기본 클래스의 객체로 복사되면서 발생한다.

      • 마지막으로 남은 방법은 '참조자에 의한 예외받기(catch-by-reference)' 입니다. 참조자로 예외를 받으면, catch 블록에서 객체를 delete 해야 할지를 고민할 필요도 없고, C++ 표준 예외를 처리하는 데에도 전혀 무리가 없으며, '값에 의한 예외받기' 와 달리 슬라이스 문제도 없고 예외 객체는 한 번만 복사됩니다.

  14. 예외 지정(exception specification) 기능은 냉철하게 사용하자 / 125

      • 예외 지정을 사용하면 어떤 함수가 어떤 예외를 발생시키는지가 드러나기 때문에, 코드 보기가 수월해집니다. 그 뿐만이 아니라, 예외 지정에 일관성이 없으면 컴파일러가 컴파일 도중에 발견해 줍니다. 게다가, 함수가 예외 지정 리스트에 없는 에외를 발생시킬 경우에는, 런타임 에러가 발생하면서 unexpected라는 특수 함수가 자동으로 호출됩니다. 즉 소스의 문서화를 돕는 역할과 예외 사용을 적절히 제약하는 역할을 동시에 해줍니다.

      • 하지만 unexpected 함수의 기본 동작은 terminate 를 호출하는 것인데, 항목 11에서 이미 본 바 있는 이 함수는 기본적으로 abort를 호출합니다. 이렇게 예외 지정을 어긴 프로그램은 기본적으로 바로 멈추어 버리고, 활성 스택 프레임에 만들어진 지역 변수는 없어지지 않은 채로 졸지에 구천을 해매야 합니다. 결국 개발자 입장에서 예외 지정을 어기는 일은 재앙을 부르는 일이나 마찬가지입니다.

      • 하지만 예외 지정을 어기는 함수를 만드는 일은 제법 쉽습니다. 예를 들어 예외 지정된 함수 내에서 예외 지정되지 않은 함수(예외를 지정하지 않는 것은 어떤 예외든 발생시킬 수 있음을 의미합니다)를 호출했을 때, 예외 지정되지 않은 함수에서 예외가 발생하여 예외 지정을 어길 수 있습니다. 예외 지정된 함수가 예외 지정되지 않은 함수를 호출하는 것이 문법적으로 적법한 이유는, 예외 지정된 새 코드와 예외 지정되지 않은 옛날의 코드가 섞일 수 있기 때문입니다.

      • 호출측 함수에서 예외 처리 코드가 준비된 상황에서조차도 unexpected가 호출될 수 있습니다.

        예제 코드 보기
        
        
        

        1. class Session {
        2. public:
        3. ~Session(void);
        4. ...
        5. private:
        6. static void logDestruction(Session *objAddr) throw();
        7. };
        8.  
        9. Session::~Session(void)
        10. {
        11. try {
        12. logDestruction(this);
        13. }
        14. catch (...) {}
        15. }
        16.  
        17. // 소멸자의 logDestruction함수를 호출하는
        18. // 코드는 try 블록 내에 넣고, catch 블록에서는
        19. // 어떤 예외든지 다 받아서 삼키도록 만들었습니다.
        20.  
        21. // 하지만 logDestruction 함수는 아무런 예외도
        22. // 발생시키지 않도록 에외 지정이 되어 있습니다.
        23. // 이렇게 만든 경우에도 logDestruction에서
        24. // 예외가 발생하면 unexpected가 호출됩니다.

        
        
        예제 코드 접기
        
        
        

      • 예외 지정 불일치 피하기의 첫걸음은 (보통 타입 인자를 받아들이는)템플릿에 예외 지정을 두지 않는 것입니다. 템플릿의 타입 매개변수에서 발생된 예외에 대해 알 방법이 전혀 없기 때문입니다.

        예제 코드 보기
        
        
        

        1. // 예외 지정에 대해 별로 신경쓰지 않고 편치 않게 설계한 템플릿
        2. template <typename T>
        3. bool operator==(const T& lhs, const T& rhs) throw()
        4. {
        5. return &lhs == &rhs;
        6. }
        7.  
        8. // 언뜻 보면 정말로 어떤 예외도 발생시키지 않을 것 같지만
        9. // T로 넘어간 타입이 operator& 함수를 오버로딩
        10. // 하고 있고 이곳에서 예외를 던질 수도 있기 때문에
        11. // 위의 경우에도 예외 지정을 어길 가능성이 있습니다.

        
        
        예제 코드 접기
        
        
        

      • unexpected가 호출되는 것을 막을 수 있는 둘째 걸음은, 예외 지정이 안 된 함수를 호출할 가능성을 가진 함수에는 예외 지정을 두지 않는 것입니다. 지극히 상식적인 아이디어라고 생각할지도 모르지만, 아주 쉽게 잊는 경우가 많습니다. 특히, 콜백 함수를 등록하도록 할 때 그렇습니다.

        예제 코드 보기
        
        
        

        1. // 어떤 윈도 시스템에 이벤트가 발생했을 때,
        2. // 윈도우 시스템 콜백을 위한 함수 포인터
        3. typedef void(*CallBackPtr)(int eventXLocation,
        4. int eventYLocation,
        5. void *dataToPassBack);
        6.  
        7. // 윈도우 시스템 개발자가 등록한 콜백 함수를
        8. // 담아두는 윈도우 시스템 클래스
        9. class CallBack {
        10. public:
        11. CallBack(CallBackPtr fPtr, void *dataToPassBack)
        12. : func(fPtr), data(dataToPassBack) {}
        14. void makeCallBack(int eventXLocation,
        15. int eventYLocation) const throw();
        16.  
        17. private:
        18. CallBackPtr func; // 콜백이 일어날 때
        19. // 호출되는 함수
        21. void *data; // 콜백 함수로 넘겨지는
        22. }; // 데이터
        23.  
        24. // 콜백을 구현하기 위해서 이벤트가 발생한 좌표와
        25. // 등록한 데이터를 사용하여 등록된 콜백 함수를 호출합니다.
        26. void CallBack::makeCallBack(int eventXLocation,
        27. int eventYLocation) const throw()
        28. {
        29. func(eventXLocation, eventYLocation, data);
        30. }
        31.  
        32. // 여기서 makeCallBack 안에서 호출되는 func는
        33. // 예외 지정을 어길 위험을 안고 있습니다.
        34.  
        35. // 이것은 typedef 타입인 CallBackPtr에
        36. // 예외 지정을 해둠으로써 해결됩니다.
        37.  
        38. typedef void(*CallBackPtr)(int eventXLocation,
        39. int eventYLocation,
        40. void *dataToPassBack) throw();
        41.  
        42. // 이렇게 해 두면, 예외를 발생시키지
        43. // 않는다는 보장이 안 되어 있는 콜백
        44. // 함수를 등록하려고 하면 컴파일러가
        45. // 에러를 냅니다.
        46.  
        47. // 예외 지정되지 않은 콜백 함수
        48. void callBackFcn1(int eventXLocation, int eventYLocation,
        49. void *dataToPassBack);
        50.  
        51. void *callBackData;
        52.  
        53. ...
        54.  
        55. CallBack c1(callBackFcn1, callBackData);
        56. // 에러입니다! callBackFcn1
        57. // 이 예외를 일으킬 수 있기 때문입니다.
        58.  
        59. // 예외 지정된 콜백 함수
        60. void callBackFcn2(int eventXLocation,
        61. int eventYLocation,
        62. void *dataToPassBack) throw();
        63.  
        64. CallBack c2(callBackFcn2, callBackData);
        65. // 문제없습니다. callBackFcn2은
        66. // 예외 지정을 따르고 있습니다.
        67.  
        68. // 하지만 이 방법은 상당수의 컴파일러가
        69. // 지원하는데도 불구하고, C++ 표준화
        70. // 위원회에서는 "예외 지정은 typedef에
        71. // 나오면 안 됩니다" 라고 정해버려서
        72. // 이식성이 떨어집니다.
        73.  
        74. // 이식성을 살리고 싶다면 CallBackPtr을
        75. // 매크로로 만들 수밖에 없습니다.

        
        
        예제 코드 접기
        
        
        

      • unexpected가 불리지 않도록 하는 세 번째 방법은 "시스템"이 일으킬 가능성이 있는 예외(C++ 표준 예외라고도 합니다)를 처리하는 것입니다.

        이런 예외 중 가장 흔한 것이 bad_alloc인데, 이 예외는 메모리 할당에 실패한 operator new와 operator new[]가 발생시킵니다(항목 8 참조). 어느 함수에서든 new 연산자를 쓸 때에는 이 함수에서 bad_alloc 예외가 꿈틀거릴 수 있다는 생각을 염두해 두시기 바랍니다.

      • 예기치 않은 예외를 막는 것이 어처구니 없이 비실용적이라면, "C++는 예기치 않은 예외를 다른 타입의 예외로 대체할 수 있는 장치를 마련해 놓았습니다" 라는 사실을 이용해 볼 수 있습니다.

        ※ set_unexpected 함수를 사용하여 unexpected 함수를 교체할 수 있습니다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. class UnexpectedException {}; // 모든 예기치 않은 예외는
        3. // 이 타입의 객체로 대체
        4. // 합니다.
        5.  
        6. void convertUnexpected(void) // 예기치 않은 예외가
        7. { // 발생되었을 때 호출되는
        8. throw UnexpectedException(); // 함수
        9. }
        10.  
        11. set_unexpected(convertUnexpected);
        12.  
        13. // 이렇게 하면, 이젠 예기치 않은 예외가 발생될 때마다
        14. // convertUnexpected가 호출되고, 어디서
        15. // 굴러먹다 온 건지도 모르는 이 예외는 throw에 의해
        16. // UnexpectedException이라는 새로운
        17. // 타입의 예외로 탈바꿈합니다.
        18.  
        19. // 예외 지정 리스트에 UnexpectedException이
        20. // 들어 있었다면, 예외 지정이 항상 만족되어 왔던 것처럼
        21. // 예외 전파가 계속됩니다.
        22.  
        23. // 예외 지정 리스트에 UnexpectedException이
        24. // 없으면, unexpected 함수를 바꾸지 않은 상황과
        25. // 똑같이 가차 없이 terminate가 호출됩니다.
        26.  
        27.  
        28. //-----------------------------------------------------------------------------
        29. // 예기치 않은 예외를 다른 잘 알려진 타입으로 바꾸는
        30. // 방법이 하나 더 있습니다.
        31.  
        32. void convertUnexpected(void) // 예기치 않은 예외가 발생할 때
        33. { // 호출되는 함수입니다. 여기서는
        34. throw; // 현재의 예외를 그대로
        35. } // 중계하기만 합니다.
        36.  
        37. set_unexpected(convertUnexpected); // convertUnexpected 함수를
        38. // unexpected 대신 호출되는 함수로
        39. // 세팅합니다.
        40.  
        41. // 이렇게 하면 예기치 않은 예외는 표준 타입인
        42. // bad_exception 객체로 바뀝니다.
        43.  
        44. // 즉 이렇게 한 후에 bad_exception
        45. // 혹은 이 객체의 기본 클래스인 exception
        46. // 을 예외 지정 리스트에 포함시키면, 예기치
        47. // 않은 예외가 발생해도 프로그램이 죽는 일은
        48. // 피할 수 있습니다.

        
        
        예제 코드 접기
        
        
        

  15. 예외 처리에 드는 비용에 대해 정확히 파악하자 / 132

      • 예외 처리 기능을 완전히 배제하고 컴파일한 프로그램은 예외 처리를 지원하도록 컴파일한 것에 비해 속도도 빠르고 크기도 작습니다. 예외 처리를 지원하는 대부분의 C++ 컴파일러 제작사에서 예외 처리를 지원할 것인지의 여부를 사용자가 조정할 수 있는 장치를 만들어 놓았습니다.

        시간이 지나고 라이브러리가 예외를 사용하는 것이 점점 일반화되면서 이런 방법도 설득력을 조금씩 잃어가고 있지만, 예외 기능 없이 컴파일 하는 것이 코드 최적화에 상당한 효과를 줄 수 있습니다. 라이브러리를 만들 때에도 마찬가지입니다. 사용자 코드에서 발생된 예외가 라이브러리 쪽으로 전파되지 않도록 보장해줄 수 있다면, 예외 없이 만든 라이브러리가 훨씬 작고 빠릅니다. 하지만 이 보장이 그렇게 쉬운 것만은 아닙니다. 왜냐하면, 라이브러리에서 선언한 가상 함수에 대한 사용자의 재정의를 허용하면 안 되고, 콜백함수도 쓰게 해서는 안 되기 때문입니다.

      • 예외 처리에 들어가는 두 번째 비용은 try 블록으로 인해 생기는 비용입니다. 이 비용은 try 블록이 소스에 들어가기만 하면, 무조건 지불해야 합니다. 이 비용을 줄이려면 쓸데 없이 try 블록을 남발하지 말아야 합니다.

        이 비용은 컴파일러마다 천차만별이긴 하지만 대략적으로 추정했을 때, try 블록을 썼을 경우 늘어나는 코드 크기와 실행 속도는 5-10% 정도입니다. 이 추정치는 예외가 전혀 발생되지 않았을 경우를 가정했을 때의 값, 즉 try 블록만 썼을 때의 값입니다.

      • 예외 지정(exception specification) 기능에 대해서도 try 블록과 비슷한 양의 코드가 생성되기 때문에, 예외 지정에 들어가는 비용도 try 블록과 비슷합니다.

      • 통상적인 함수 복귀(return)와 비교했을 때, 예외 발생(throw)에 의한 함수 복귀의 속도는 약 10의 세 제곱 배(1000배) 만큼 느리다고 합니다.

        사실 예외 발생시 소모되는 비용은 그다지 큰 관심거리가 되지 못합니다. 왜냐하면 예외가 발생되는 경우는 극히 드물기 때문입니다. 이와 같은 이유로 프로그램 처리 중에 꽤 자주 발생하는 상황을 나타내는 데에 예외를 남발해서는 안됩니다.

      • 정리해 봅시다. 예외에 관련된 비용을 최소화하려면, 우선 가능하다면 예외 기능을 사용하지 않도록 컴파일하십시오. 그리고 try 블록과 예외 지정은 꼭 필요한 부분에만 사용합니다. 예외를 발생시키는 일도 진짜 예외적인 상황이라고 판단될 때에만 해야 합니다.

        이렇게 했는데도 수행 성능 문제로 머리가 아프신 분은 여러분의 프로그램을 프로파일링(profiling)해서(항목 16 참조) 예외 기능이 진짜로 수행 성능의 발목을 잡는 주된 요인인지를 알아보세요. 만일 그렇다면, C++ 예외 처리 기능을 더 효율적으로 구현한 다른 컴파일러로 바꾸시는 것이 좋습니다.

• Chapter 4   효율(Efficiency)

  16. 뼛속까지 잊지 말자, 80-20 법칙! / 137

      • 80-20 법칙(80-20 rule)이란 이렇습니다. "프로그램 리소스의 80%는 전체 실행 코드의 약 20%만이 사용한다", "실행 시간의 80%는 실행 코드의 약 20%만이 소모한다", "메모리의 80%는 실행 코드의 약 20%만이 사용한다", "디스크 접근 회수의 80%는 실행코드의 약 20%가 접근한 회수이다", "프로그램 유지보수에 들어가는 수고의 80%는 실행 코드의 20%에 집중된다"라는, 생각할수록 짜증나는 현상을 일러주는 법칙입니다.

      • 프로그램의 성능을 향상시키려면 이 20%의 실행 코드를 찾아 이 코드를 최적화 해야 합니다. 나머지 80%의 코드를 최적화 하더라도 큰 성능 향상 효과를 보기는 어렵습니다. 가장 골치 아픈 일은 실행 병목현상을 일으키는 20%의 실행 코드를 찾는 것입니다. 방법은 두 가지가 있는데, 하나는 '대부분의 사람들이 하는 방법을' 따르는 것이고, 또 하나는 '제대로' 하는 것입니다.

        '대부분의 사람들이 하는 방법'은 어림짐작(guess) 인데, 보통 이 방법은 틀리는 경우가 많습니다. 80-20 법칙의 진짜 의미는 '아무 곳이나 골라잡고 효율을 향상시키려고 애쓰는 것은 별 도움이 안 된다'는 것입니다.

      • 성능 개선의 정도(正道)는 여러분의 가슴을 턱턱 막히게 하는 20%의 코드를 경험적으로 판별하는 것입니다. 그리고 지긋지긋한 20%를 판별하는 방법은 프로그램 프로파일러(program profiler)를 사용하는 것입니다.

        하지만 아무 프로파일러나 다 쓴다고 해서 되는 것은 아니고, 여러분이 관심을 두고 있는 리소스를 직접 측정해 주는 도구가 필요합니다. 예를 들어, 프로그램이 너무 느리다면 실행 영역별로 시간 측정을 해 주는 프로파일러를 써야 합니다. 프로파일러로 찾은 특정한 부분만 제대로 개선하면 전체 효율도 엄청나게 향상됩니다.

      • 문장이 몇 번 실행되고 함수가 몇 번 호출되는지를 알려 주는 프로파일러도 있는데, 이런 것들은 그렇게 많이 사용되진 않습니다. 여러분이 만든 제품이 충분히 빠르기만 하면, 1045번 호출되든 10450번 호출되든 아무도 전혀 신경쓰지 않기 때문입니다.

        하지만 얼마나 자주 문장이 실행되고 함수가 호출되는지를 파악해 두면, 여러분이 만든 프로그램의 동작 원리를 좀더 잘 알 수 있게 됩니다. 예를 들어 여러분이 특정 타입의 객체가 생성되는 회수를 파악하고 싶다면 그 객체의 생성자가 호출되는 회수를 세면 됩니다. 게다가 문장 및 함수 호출 회수는 여러분이 직접 측정할 수 없는 프로그램의 동작 메커니즘을 간접적으로 이해하는 데에 유용합니다. 이를테면 동적 메모리 사용을 직접 점검할 수 없는 상황에 있다면 메모리 할당과 헤제용 함수(operator new, new[], delete, delete[] - 항목 8 참조)의 호출 횟수를 세어 사용하면 됩니다.

      • 프로세스가 의외의 입력 데이터를 처리하는 동안에 프로파일링이 수행되는 경우에는, 프로파일러가 전체 성능에 별 영향을 끼치지 않는 미세 튜닝 부분(바로 80%의 코드입니다) 에 병목이 있다고 가르쳐 주더라도 불평해선 안 됩니다. 이런 경우는 예외적인 상황에서의 프로그램 동작을 최적화할 수 있는 좋은 기회라고 보시면 됩니다. 일반적인 상황에서의 최적화 기법이 오히려 이런 경우에는 반대로 작용할 수 있습니다.

      • 어쨌든, 이런 종류의 수행 성능 문제에 대처하는 최선의 길은 가능한 많은 데이터를 사용해서 소프트웨어를 프로파일링하는 것입니다.

        덧붙여서, 데이터는 사용자(최소한 가장 중요한 사용자)가 그 소프트웨어에 잘 입력하는 형태의 것으로 준비하셔야 합니다.

  17. 효율 향상에 있어 지연 평가(lazy evaluation)는 충분히 고려해 볼 만하다 / 140

      • 지연 평가란 가능한 한 계산을 미루다가, 꼭 계산 결과 값이 필요해질 때 비로소 계산을 수행하는 방법을 말합니다. 지연 평가를 적용할 수 있는 분야는 마음만 먹으면 수백 가지도 만들 수 있겠지만, 일반적인 것을 네 가지로 정리해서 살펴봅시다.

        • 참조 카운팅(Reference Counting)
          어떤 객체를 복사할 때 즉시 복사를 하지 않고, 복사 작업을 최대한 늦추는 방법입니다. 만일 객체를 복사하는 코드를 만나면 그 즉시 복사 작업을 하지 않고, 사본 객체가 원본 객체의 값을 공유하도록 만듭니다. 이때 사본 객체의 값을 읽기만 한다면 값의 복사 작업을 할 필요가 없습니다. 만약 둘중 하나의 값을 변경하게 된다면, 이제야 비로소 복사 작업을 수행하는 것입니다.
          
          예제 코드 보기
          
          
          

          1. class String { ... }; // 문자열 클래스
          2.  
          3. String s1 = "Hello";
          4. String s2 = s1; // String의 복사 생성자를 호출합니다.
          5.  
          6. // 이 때 s1의 값을 s2로 복사하지 않고
          7. // s1의 값을 s2와 공유하도록 만듭니다.
          8.  
          9. cout << s1; // s1의 값을 읽습니다.
          10. cout << s1 + s2; // s1과 s2의 값을 읽습니다.
          11.  
          12. // 이런 경우 s1의 값을 s2로 복사할
          13. // 필요가 없습니다. 읽기만 하기 때문에
          14. // 하나의 값을 공유하고 있어도 문제없습니다.
          15.  
          16. s2.convertToUpperCase(); // s2의 모든 문자를 대문자로 만듭니다.
          17.  
          18. // s2의 값만 바뀌고 s1의 값은 바뀌면
          19. // 안되므로, 이제 s1의 값을 s2로
          20. // 복사합니다. 그 후, s2의 모든 문자를
          21. // 대문자로 바꿉니다.
          22.  
          23. // 만일 운이 좋아서 s2와 s1의 값을
          24. // 영원히 읽기만 한다면, 문자열의 복사도
          25. // 영원히 할 필요가 없을 것입니다.

          
          
          예제 코드 접기
          
          
          
        • 데이터 읽기와 쓰기를 구분하기
          앞에서 살펴본 참조 카운팅의 경우 값을 읽기만 할 때는 복사를 할 필요가 없고, 쓰기를 할 때 비로소 복사를 해야 하므로, 값을 읽는것과 쓰는 것을 구분해야 합니다. 그런데, operator[]와 같은 함수들은 값을 읽기 위해 호출될 수도 있고, 쓰기 위해 호출될 수도 있습니다. 안타깝게도 operator[]와 같은 함수들이 값을 읽기 위해 호출되었는지 쓰기 위해 호출되었는지 알 방법은 없습니다. 하지만, 항목 30에서 설명한 지연 평가와 프록시 클래스를 사용하면, 읽기가 맞는지 쓰기가 맞는지를 정확히 결정할 수 있을 때까지 읽기 동작과 쓰기 동작을 구별하는 것을 늦출 수도 있습니다.
          
          예제 코드 보기
          
          
          

          1. String s = "Homer's Iliad"; // s는 참조 카운팅으로 운영
          2. // 되는 문자열이라고 가정합니다.
          3. ...
          4. cout << s[3]; // s[3]을 읽기 위해 operator[]를 호출합니다.
          5. s[3] = 'x'; // s[3]에 쓰기 위해 operator[]를 호출합니다.
          6.  
          7. // 두 가지 경우를 구분해서 쓰기 위해 operator[]를
          8. // 호출했을 때만 문자열의 복사 작업이 이루어지도록
          9. // 합니다.
          10.  
          11. // 하지만 operator[]는 하나이므로
          12. // 구현이 조금 까다로워집니다.

          
          
          예제 코드 접기
          
          
          
        • 지연 방식의 데이터 가져오기(Lazy Fetching)
          구성 필드를 많이 가지고 있는 대규모의 객체를 사용하는 어떤 프로그램이 하나 있습니다. 이 객체는 구성 필드들을 데이터베이스에 저장해 둡니다. 그런데 이 객체를 사용할 때 항상 모든 필드값을 사용할까요? 아마도 그렇지 않고 특정 필드값만 사용하는 경우도 많을 것입니다. 하지만 데이터베이스에서 필드값을 읽어오는 데는 많은 시간이 필요하죠. 이럴 때 데이터베이스에서 모든 필드값을 한꺼번에 읽어오지 않고, 필요한 필드값만 읽어와서 사용하는 것입니다.
          
          예제 코드 보기
          
          
          

          1. class LargeObject { // 지속성을 지닌 아주 '큰' 객체
          2. public:
          3. LargeObject(ObjectID id); // 디스크에서 객체를 가져옵니다.
          5. const string& field1(void) const; // 필드 1의 값
          6. int field2(void) const; // 필드 2의 값
          7. double field3(void) const; // 등...
          8. const string& field4(void) const;
          9. const string& field5(void) const;
          10. ...
          11. };
          12.  
          13. // 이제 LargeObject를 디스크에서 가져오는
          14. // 비용을 생각해 보도록 하죠.
          15.  
          16. // LargeObject는 매우 크기 때문에
          17. // 모든 필드값을 읽어오려면 많은 시간이 걸립니다.
          18.  
          19. void restoreAndProcessObject(ObjectID id)
          20. {
          21. LargeObject object(id); // 객체를 가져옵니다.
          23. if (object.field2() == 0) {
          24. cout << "Object " << id << ": null field2.\n";
          25. }
          26. }
          27.  
          28. // 하지만 위의 경우 필드 2 만을 사용합니다.
          29. // 때문에 다른 필드를 읽는데 시간을 허비할
          30. // 필요가 없습니다.
          31.  
          32. // 따라서 LargeObject를 '요구기반(demand-paged)'
          33. // 방식의 객체 초기화 방법으로 구현하면 더
          34. // 효율적일 것입니다.
          35.  
          36. class LargeObject {
          37. public:
          38. LargeObject(ObjectID id);
          40. const string& field1(void) const;
          41. int field2(void) const;
          42. double field3(void) const;
          43. const string& field4(void) const;
          44. ...
          46. private:
          47. ObjectID oid;
          49. mutable string *field1Value;
          50. mutable int *field2Value;
          51. mutable double *field3Value;
          52. mutable string *field4Value;
          53. ...
          54. };
          55.  
          56. LargeObject::LargeObject(ObjectID id)
          57. : oid(id), field1Value(0), field2Value(0), field2Value(0), ...
          58. {}
          59.  
          60. const string& LargeObject::field1(void) const
          61. {
          62. if (field1Value == 0) {
          63. 데이터베이스에서 필드 1의 데이터를 읽고, field1Value가
          64. 이 데이터를 가리키게 합니다.
          65. }
          67. return *field1Value;
          68. }
          69.  
          70. // 상수 멤버 함수에서 field1Value의 값을
          71. // 수정해야 하므로 mutable로 선언되었습니다.
          72. // (나머지 필드값을 가리킬 포인터도 마찬가지)
          73.  
          74. // 하지만 만약 mutable을 지원하지 않는
          75. // 컴파일러를 쓴다면 "this 흉내내기(fake this)"
          76. // 방법을 써야 합니다.
          77.  
          78. class LargeObject {
          79. public:
          80. const string& field1(void) const; // 바뀐 것 없습니다.
          81. ...
          83. private:
          84. string *field1Value; // mutable로 선언되지 않았기 때문에
          85. ... // 조금 구닥다리 컴파일러에서도
          86. }; // 통합니다.
          87.  
          88. const string& LargeObject::field1(void) const
          89. {
          90. // fakeThis라는 포인터를 하나 선언합니다.
          91. // 이 포인터는 this가 가리키는 것을 가리키고,
          92. // 상수성은 const_cast를 통해 제거합니다.
          93. LargeObject * const fakeThis =
          94. const_cast<LargeObject* const>(this);
          96. if (field1Value == 0) {
          97. fakeThis->field1Value = // 이 대입 연산은 문제없습니다.
          98. 데이터베이스에서 뽑은 // 왜냐하면, fakeThis가 가리키는
          99. 적절한 데이터 // 객체는 상수 객체가 아니기 때문입니다.
          100. }
          102. return *field1Value;
          103. }
          104.  
          105. // 만일 컴파일러가 const_cast조차 지원하지 않는다면
          106. // C스타일의 캐스트를 씁시다.
          107.  
          108. // mutable 흉내내기 위해 C 스타일의 캐스팅을 사용합니다.
          109. const string& LargeObject::field1(void) const
          110. {
          111. LargeObject * const fakeThis = (LargeObject* const)this;
          113. ... // 앞에서와 같습니다.
          114. }
          115.  
          116. // 사용하기 전에 널인지 점검하는 과정이 왠지
          117. // 무식하다고 생각될 수 있습니다.
          118. // 잘못하면 에러를 낼 가능성도 높습니다.
          119. // 이는 스마트 포인터를 사용함으로써
          120. // 말끔히 해결할 수 있습니다(항목 28 참조).

          
          
          예제 코드 접기
          
          
          
        • 지연 방식의 표현식 평가(Lazy Expression Evaluation)
          지연 평가의 마지막 예제는 수치 연산입니다. 행렬을 예로 들어 보겠습니다. 아시다시피 행렬 연산은 비용이 매우 많이 듭니다. 그러므로 이러한 행렬 연산을 수행하는 코드를 만나면 즉시 연산을 수행하지 않고 연산자와 피연산자에 대한 정보만을 기록해 둡니다. 그리고 연산 결과가 필요하게 되면 그제서야 연산을 수행합니다. 행렬의 경우 계산 결과의 모든 원소를 사용하지 않는다면, 사용할 원소만을 계산하는 방법을 쓸 수도 있습니다.
          
          예제 코드 보기
          
          
          

          1. template <typename T>
          2. class Matrix { ... }; // 균등 행렬(homogeneous matrix)용
          3.  
          4. Matrix<int> m1(1000, 1000); // 1000 * 1000 행렬
          5. Matrix<int> m2(1000, 1000); // 역시 1000 * 1000 행렬
          6.  
          7. ...
          8. Matrix<int> m3 = m1 + m2; // m1과 m2를 더합니다.
          9.  
          10. // m3에는 m1과 m2를 더한 값이 아닌
          11. // "m3의 값은 m1과 m2의 합이다"라는
          12. // 표시만 해 두는 것입니다.
          13.  
          14. // 그리고 m3의 값을 사용하려고 하면
          15. // 그제서야 m1과 m2의 합을 구해
          16. // m3에 담는 것이죠.
          17.  
          18. // 만일 m3이 사용되기 전에 다음의 코드가
          19. // 실행된다면
          20.  
          21. Matrix<int> m4(1000, 1000);
          22.  
          23. ... // m4에 몇 개의 값을 줍니다.
          24. m3 = m4 * m1;
          25.  
          26. // m3는 m1과 m2의 합이라는 것도 기억할 필요가
          27. // 없습니다(따라서 계산 비용이 들지 않습니다).
          28.  
          29. cout << m3[4]; // m3의 네 번째 행을 콘솔에 출력합니다.
          30.  
          31. // 이제는 더 이상 계산을 미룰 수 없습니다.
          32. // 하지만 여전히 네 번째 행 이외의 행은
          33. // 계산할 필요가 없습니다.
          34.  
          35. cout << m3; // m3을 모두 콘솔에 출력합니다.
          36.  
          37. // 이제는 진짜로 더 이상 계산을 미룰 수
          38. // 없습니다. m3의 모든 요소를 계산하여
          39. // 콘솔에 출력해야 합니다.
          40.  
          41. m3 = m1 + m2; // m3은 m1과 m2의 합입니다.
          42. // 잊지 않았겠죠?
          43. m1 = m4; // 이제 m3은 m2와 이전 m1의
          44. // 합이 됩니다!
          45.  
          46. // 위와 같은 경우 때문에, Matrix<int>의
          47. // 대입 연산자 안에는 m1을 변경하기 전의 m3의
          48. // 값을 계산해 놓든지, m1의 이전 값을 복사해
          49. // 놓고 m3의 자료구조를 그 이전 값에 맞추어
          50. // 업데이트해야 할 것입니다.

          
          
          예제 코드 접기
          
          
          

      • 지연 평가 기법은 만병 통치약이 아닙니다. 만약 모든 계산 결과를 즉시에 사용해야 하는 경우에는 지연 평가로 얻을 수 있는 것이 없습니다. 심지어 빠른 처리에 걸림돌이 되거나 메모리 사용량을 늘리기도 합니다. 왜냐하면, 여러분이 피하려고 했던 계산을 모두 해야 할 뿐만 아니라, 지연 평가에 쓰려고 만들어 둔 자료구조마저도 조작해야 하기 때문입니다. 계산을 바로 하지 않아도 되는 경우가 잦은 소프트웨어를 만들 때에 지연 평가의 효과를 톡톡히 볼 수 있습니다.

      • 지연 평가 기법은 C++만의 특징이 아니라서 어떤 프로그래밍 언어를 쓰더라도 적용할 수 있고, 특히 APL, LISP의 변종들을 포함한 데이터처리 언어는 지연 평가 메커니즘을 언어의 일부로 만들어 놓았습니다. C++ 언어와 같은 시스템 개발의 주류 언어들 대부분은 즉시 평가를 사용합니다. 하지만 C++는 사용자가 직접 지연 평가를 구현해서 쓸 수가 있습니다.

      • 이번 항목에 사용한 예제를 다시 잘 살펴보면, 클래스 인터페이스의 어느 부분에서도 즉시 평가나 지연 평가가 이루어진다는 표시나 흔적을 찾을 수 없을 것입니다. 즉, 일반적인 즉시 평가 메커니즘을 써서 클래스를 구현했다가 프로파일링 과정에서 병목 현상이 발견되면, 문제되는 부분을 지연 평가 메커니즘으로 교체하더라도 사용자 쪽에서 전혀 불편을 느끼지 않는다는 것입니다.

  18. 예상되는 계산 결과를 미리 준비하면 처리비용을 깎을 수 있다 / 150

      • 현재 요구된 것 이외에 더 많은 작업을 미리 해 둠으로써 소프트웨어의 성능을 향상시킬 수 있습니다. 이런 스타일의 작업을 과도선행 평가(over-eager evaluation)라고 부릅니다. 과도선행 평가 방법의 기본 아이디어는, 상당히 자주 요구될 것 같은 계산이 있다면, 그 요구를 효율적으로 처리할 수 있는 자료구조를 설계하여 비용을 낮추자는 것입니다.

      • 가장 간단하게 과도선행 평가를 구현할 수 있는 방법 중 하나는, 이미 계산이 끝났고 또다시 사용될 것 같은 값을 캐싱(caching)하는 것입니다. 예를 들어 자주 사용하는 데이터를 매번 데이터베이스 질의를 통해 얻어오는 대신, 데이터베이스 질의를 통해 한 번 얻은 데이터를 메인 메모리에 넣어 두고 필요할 때마다 메인 메모리에서 가져다 쓰도록 만들면 훨씬 효율적으로 작동하는 프로그램을 만들 수 있습니다.

        예제 코드 보기
        
        
        

        1. int findCubicleNumber(const string& employeeName)
        2. {
        3. // (직원이름, 작업칸 번호) 페어(pair, 쌍)를 저장하는 맵 객체를
        4. // 정적 변수로 정의합니다. 이 맵이 내부 캐시입니다.
        5. typedef map<string, int> CubicleMap;
        6. static CubicleMap cubes;
        8. // employeeName에 대한 엔트리를 캐시에서 찾습니다.
        9. // 엔트리가 발견되면, STL 반복자인 "it"은 탐색된 엔트리를
        10. // 가리킵니다(항목 35 참조).
        11. CubicleMap::iterator it = cubes.find(employeeName);
        13. // 엔트리의 탐색에 실패하면 "it"의 값은 cubes.end()가
        14. // 됩니다(STL의 통상적인 동작방식입니다).
        15. // 이 경우에는 데이터베이스에서 작업칸 번호를 찾아,
        16. // 그 결과를 캐시에 넣습니다.
        17. if (it == cubes.end()) {
        18. int cubicle =
        19. 데이터베이스에서 employeeName의 작업칸 번호를
        20. 찾은 결과;
        22. cubes[employeeName] = cubicle // 내부 캐시에
        23. // (employeeName, cubicle)
        24. // 페어를 추가합니다.
        25. return cubicle;
        26. }
        27. else {
        28. // "it"은 맵에서 찾은 엔트리를 가리키고 있습니다. 이 엔트리는
        29. // (employee name, cubicle number) 페어입니다. 우리가 원하는
        30. // 것은 이 페어의 두 번째 요소인데, second라는 멤버를 사용하여
        31. // 뽑아낼 수 있습니다.
        33. return (*it).second;
        34. }
        35. }
        36.  
        37. // return (*it).second; 부분은
        38. // return it->second; 로 바꿀 수 있으나,
        39. // 일부 오래된 컴파일러의 경우 반복자에
        40. // operator-> 함수가 재정의되어 있지 않은
        41. // 경우가 있어서, 이런 컴파일러를 사용하시는
        42. // 분들은 (*it).second를 써야 이식 문제로
        43. // 고민하지 않습니다.

        
        
        예제 코드 접기
        
        
        

      • 캐싱 이외의 방법으로 미리가져오기(Prefetching)란 방법도 있습니다. 이 방법은 참조 위치의 근접성(locality of reference)을 이용합니다. 쉽게 말하면, "어떤 곳의 데이터를 참조했다면, 가까운 시일 내에 그 주변의 데이터도 참조할 가능성이 높다" 라는 것을 이용하는 것입니다. 예를 들어 디스크에서 어떤 데이터를 읽을 때 그 데이터 주위에 있는 데이터도 한꺼번에 읽어 오도록 만들면 훨씬 효율적으로 작동하도록 만들 수 있습니다. 또 다른 예로 동적 배열을 만들 때 딱 필요한 만큼만의 메모리를 할당하는 것이 아니라 여분의 메모리를 미리 할당하여, 가까운 시일 내에 동적 배열이 확장되더라도 미리 할당한 범위 내라면 동적 할당을 하지 않음으로써 효율적으로 작동하도록 만들 수 있습니다.

        예제 코드 보기
        
        
        

        1. template <typename T> // T 타입의 동적 배열
        2. class DynArray { ... }; // 을 나타내는 템플릿
        3.  
        4. DynArray<double> a; // 여기서는 a[0]만이
        5. // 유효한 배열 요소
        6. // 입니다.
        7.  
        8. a[22] = 3.5; // a는 자동으로 확장됩니다.
        9. // 이 배열에서 유효한 인덱스는
        10. // 0부터 22까지 되었습니다.
        11.  
        12. a[32] = 0; // 다시 확장됩니다.
        13. // 이제는 a[0]-a[32]가 유효합니다.
        14.  
        15. // DynArray의 operator[]는 아마도
        16. // 다음과 같이 구현되었을 것입니다.
        17.  
        18. template <typename T>
        19. T& DynArray<T>::operator[](int index)
        20. {
        21. if (index < 0) {
        22. throw an exception; // 음수의 인덱스는
        23. } // 여전히 안 됩니다.
        25. if (index > the current maximum index value) {
        26. new를 사용하여, 주어진 인덱스가 유효할 만큼
        27. 추가 메모리를 할당합니다.
        28. }
        30. return 배열 내의 index 번째의 요소;
        31. }
        32.  
        33. // 만약 동적 배열의 크기가 확장 되었다면
        34. // 조만간 또 다시 확장이 일어날 가능성이 큽니다.
        35. // 따라서 딱 필요한 만큼만 확장하는 것이 아니라
        36. // 여분의 메모리를 미리 확장해 놓는 방법을
        37. // 쓸 수 있습니다.
        38.  
        39. template <typename T>
        40. T& DynArray<T>::operator[](int index)
        41. {
        42. if (index < 0) throw an exception;
        44. if (index > 현재의 최대 인덱스) {
        45. int diff = index - 현재의 최대 인덱스값;
        47. index에 diff를 더한 만큼의 인덱스가 유효하도록
        48. 메모리를 할당합니다.
        49. }
        51. return 배열 내의 index 번째의 요소;
        52. }
        53.  
        54. DynArray<double> a; // a[0]만이 유효한 상태
        55.  
        56. a[22] = 3.5; // new가 호출되는데, 이제는 인덱스 44가
        57. // 유효하도록 메모리가 할당됩니다.
        58. // a의 실제 배열 크기는
        59. // 23이 됩니다.
        60.  
        61. a[32] = 0; // a의 실제 배열크기(총 용량이 아닌)
        62. // 는 a[32]가 유효하도록 변합니다.
        63. // 하지만 new는 호출되지 않습니다.

        
        
        예제 코드 접기
        
        
        

      • 이번 항목은 항목 17에서 강조한 내용과 상반되는 개념이 절대로 아닙니다. 지연 평가는 "어떤 작업의 결과가 항상 사용되는 것은 아니라면 그 작업을 미리 하지 않음으로써 프로그램의 효율을 높이는" 방법이고, 과도선행 평가는 "어떤 작업의 결과가 거의 항상 사용되거나 한 번 이상 자주 사용된다면 그 작업을 미리 해둠으로써 프로그램의 효율을 높이는" 방법입니다.

  19. 임시 객체의 원류(原流)를 정확히 이해하자 / 156

      • 일반적으로 말하는 임시 객체와 C++에서 말하는 진짜 '임시 객체'는 좀 다릅니다. C++에서의 진짜 '임시 객체'는 우리 눈에 보이지 않습니다. 소스 코드에도 없습니다. C++에서의 진짜 임시 객체(이후 임시 객체)는 힙 이외의 공간에 생성되는 '이름 없는' 객체입니다. 이런 이름 없는 객체가 만들어지는 상황은 두 가지입니다. 첫째는 함수 호출을 성사시키기 위해 암시적 타입변환이 적용될 때이고, 둘째는 함수가 객체를 값으로 반환(return by value)할 때입니다.

        임시 객체가 어떻게, 그리고 왜 생성되고 소멸되는지 정확하게 파악하는 것은, 어쩌면 C++ 코더에서 C++ 프로그래머로 발돋음하기 위한 중요한 요구사항일지도 모릅니다. 왜냐하면, 임시 객체가 생성되고 소멸되는데 드는 비용이 프로그램 전체 성능에 미치는 영향이 꽤 쏠쏠한 수준이기 때문입니다.

      • 우선, 함수 호출을 성사시키기 위해 임시 객체가 생성되는 첫째 경우를 생각해 보죠. 함수에 전달되는 객체의 타입과 바인딩되어야 하는(원래의 함수 선언에 들어 있었던) 매개변수의 타입이 다를 때 이런 일이 일어납니다.

        예제 코드 보기
        
        
        

        1. // str 안에 들어 있는 ch의 출현회수를 반환합니다.
        2. size_t countChar(const string& str, char ch);
        3.  
        4. char buffer[MAX_STRING_LEN];
        5. char c;
        6.  
        7. // 문자와 문자열을 읽습니다. 문자열을 읽을 때 버퍼가
        8. // 넘치는 것을 막기 위해 setw를 사용했습니다.
        9. cin >> c >> setw(MAX_STRING_LEN) >> buffer;
        10.  
        11. cout << "There are " << countChar(buffer, c)
        12. << " occurrences of the character " << c
        13. << " in " << buffer << endl;
        14.  
        15. // countChar 함수는 첫 번째 매개변수로 string
        16. // 타입의 상수 참조자를 받지만, 넘겨진 첫 번째 인자는
        17. // char 타입의 배열입니다.
        18.  
        19. // 이 함수 호출을 성사시키기 위해 컴파일러는
        20. // char 타입의 배열로부터 string 타입의
        21. // 임시 객체를 생성합니다.
        22.  
        23. // 이렇게 만들어진 임시 객체는 countChar함수가
        24. // 복귀할 때 자동으로 소멸됩니다.
        25.  
        26. void uppercasify(string& str); // str 안의 모든 문자를
        27. // 대문자로 바꿉니다.
        28.  
        29. char subtleBookPlug[] = "Effective C++";
        30.  
        31. uppercasify(subtleBookPlug); // 가차 없이 에러!
        32.  
        33. // 하지만 이 경우처럼 상수 객체 참조자가 아닌
        34. // 비상수 객체 참조자 타입의 매개변수로 객체가
        35. // 전달될 때에는 임시 객체가 생성되지 않습니다.
        36.  
        37. // 만일 임시 객체를 생성한다면, uppercasify
        38. // 함수가 변경하는 객체는 subtleBookPlug이
        39. // 아니라 subtleBookPlug으로부터 생성된
        40. // 임시 객체고, 결과적으로 subtleBookPlug는
        41. // 원하는대로 변경되지 않기 때문에 비직관적입니다.
        42.  
        43. // 반면 상수 객체 참조자의 경우, 상수라서
        44. // 임시 객체를 읽기만 하므로 이러한 문제가
        45. // 발생하지 않습니다.
        46.  
        47. // 그래서 상수 객체 참조자 타입의 매개변수로
        48. // 객체가 전달될 때에만 임시 객체가 생성됩니다.

        
        
        예제 코드 접기
        
        
        

      • 임시 객체가 생성되는 두 번째 경우는 함수가 객체를 (값으로) 반환할 때라고 했습니다. 예를 들어, operator+는 두 피연산자의 합을 나타내는 객체를 반환해야 합니다.

        Number라는 타입의 객체에 대해 덧셈을 수행하는 operator+가 있다면 다음과 비슷할 것입니다.
        
        const Number operator+(const Number& lhs, const Number& rhs);
        
        이 함수의 반환값은 임시 객체입니다. 왜냐하면, 이 객체는 이름이 없기 때문입니다. 그냥 함수의 반환값일 뿐이죠. 임시 객체를 반환하는 이상, operator+를 호출할 때마다 이 객체는 만들어졌다가 없어지는 일을 반복할 수밖에 없습니다(반환값이 상수(const)인 이유는 항목 6에서 확인하세요).

  20. 반환값 최적화(return value optimization)가 가능하게 하자 / 160

      • 반드시 값을 통해 반환(return by value)해야 하는 함수들도 있습니다. 대표적인 예를 들면 operator*가 있습니다. 이런 함수들을 억지로 값이 아닌 참조자나 포인터를 반환하도록 만드려고 하면 문제가 생길 수 밖에 없습니다.

        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 값에 의한 반환 대신 포인터를 반환하는 경우의 문제점
        3.  
        4. // 값에 의한 객체 반환을 피하기 위해 짜냈지만 별로 안 좋은 방법
        5. const Rational * operator*(const Rational& lhs,
        6. const Rational& rhs);
        7.  
        8. Rational a = 10;
        9. Rational b(1, 2);
        10.  
        11. Rational c = *(a * b); // a와 b를 곱하는 이 문장이
        12. // 자연스러워 보이세요?
        13.  
        14. // 또한 이 경우 받은 포인터를 삭제(delete) 해야
        15. // 할지도 고민해야 합니다. 보통은 삭제하는게 정답이고,
        16. // 삭제해야 하는 경우 리소스 누수를 일으킬지도 모릅니다.
        17.  
        18.  
        19. //-----------------------------------------------------------------------------
        20. // 값에 의한 반환 대신 참조자를 반환하는 경우의 문제점
        21.  
        22. // 값에 의한 객체 반환을 피하는 위험한(그리고 틀린)
        23. // 방법
        24. const Rational& operator*(const Rational& lhs,
        25. const Rational& rhs);
        26.  
        27. Rational a = 10;
        28. Rational b(1, 2);
        29.  
        30. Rational c = a * b; // 이상하지 않은 문장
        31.  
        32. const Rational& operator*(const Rational& lhs,
        33. const Rational& rhs)
        34. {
        35. Rational result(lhs.numerator() * rhs.numerator(),
        36. lhs.denominator() * rhs.denominator());
        37. return result;
        38. }
        39.  
        40. // 이 객체가 반환하는 참조자가 가리키는 객체는
        41. // 함수가 종료될 시점에는 이미 이 세상에는
        42. // 존재하지 않습니다. 즉 말도 안되는 코드입니다.

        
        
        예제 코드 접기
        
        
        

      • 값을 반환할 수 밖에 없는 함수는 어쩔 수 없이 값을 반환할 때 임시 객체를 만들게 됩니다(항목 19 참조). 물론 그에 대한 비용도 지불해야 합니다. 하지만 객체 대신에 생성자 인자를 반환하도록 만들면 컴파일러가 최적화를 해 줍니다. 이러한 최적화를 "반환값 최적화(return value optimization: RVO)" 라고 합니다. 반환값 최적화는 대부분의 컴파일러가 지원합니다.

        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 반환값 최적화 예제
        3.  
        4. // 객체를 반환하는 함수를 작성하는
        5. // 효율적이면서도 정확한 방법
        6. const Rational operator*(const Rational& lhs,
        7. const Rational& rhs)
        8. {
        9. return Rational(lhs.numerator() * rhs.numerator(),
        10. lhs.denominator() * rhs.denominator());
        11. }
        12.  
        13. // 반환하는 표현식을 잘 보시면 Rational의 생성자가
        14. // 호출되고 있는 것을 볼 수 있습니다.
        15.  
        16. Rational a = 10;
        17. Rational b(1, 2);
        18.  
        19. Rational c = a * b; // operator*가 여기서 호출됩니다.
        20.  
        21. // 컴파일러는 operator* 안에서 생기는 임시 객체와
        22. // operator*가 반환하는 임시 객체를 모두 없애고,
        23. // 계산 결과값을 객체 c에 대해 할당된 메모리에다
        24. // 직접 넣어 초기화해 줍니다.
        25.  
        26. // 대부분의 컴파일러가 이런 기능을 가지고 있고,
        27. // 이런 경우 operator*를 호출했을 때
        28. // 소모되는 임시 객체의 총 비용은 제로가 됩니다.
        29.  
        30.  
        31. //-----------------------------------------------------------------------------
        32. // 위의 예제에서 c는 이름이 붙은 객체인데,
        33. // 이름이 붙은 객체는 컴파일러의 최적화 혜택을
        34. // 받을 수 없게 되어 있습니다(항목 22 참조).
        35.  
        36. // 하지만, 이에 대한 오버헤드는 operator*를
        37. // 인라인 함수로 선언하면 간단히 없앨 수 있습니다.
        38.  
        39. // 객체를 반환하는 함수를 작성하는
        40. // 가장 효율적인 방법
        41. inline const Rational operator*(const Rational& lhs,
        42. const Rational& rhs)
        43. {
        44. return Rational(lhs.numerator() * rhs.numerator(),
        45. lhs.denominator() * rhs.denominator());
        46. }
        47.  
        48. // 하지만 1996년에, C++ 표준위원회는 이름을 가진 객체와
        49. // 이름이 없는 객체 모두 반환값 최적화 기능에 의해
        50. // 최적화될 수 있다고 발표했습니다.
        51.  
        52. // 따라서 바로 앞에서 인라인으로 선언하지 않고
        53. // 만든 operator*함수도 동일한(최적화된)
        54. // 코드를 만들어 낼 수 있습니다.

        
        
        예제 코드 접기
        
        
        

  21. 오버로딩은 불필요한 암시적 타입변환을 막는 한 방법이다 / 164

      • Unlimited Precision Integer를 나타내기 위한 클래스 UPInt가 있다고 생각해 봅시다. 이 클래스에는 operator+ 함수가 마련되어 있습니다. 그리고 UPInt는 int 타입의 객체로부터 암시적 변환 생성이 가능합니다. UPInt끼리 더할때는 아무런 문제가 생기지 않습니다. 하지만 UPInt + int 혹은 int + UPInt를 하면 어떻게 될까요? 물론 정상적으로 컴파일이 되고 실행도 됩니다. 하지만 int 타입의 객체를 UPInt 타입의 객체로 암시적 변환을 하는 과정에서 임시 객체가 생성됩니다. 물론 임시 객체를 생성하고 소멸하는 비용이 들게 됩니다. 이 비용을 피하려면 UPInt 타입의 객체와 int 타입의 객체를 직접 더할 수 있는 operator+를 오버로딩 하면 됩니다.

        예제 코드 보기
        
        
        

        1. class UPInt { // Unlimited Precision Integer를
        2. public: // 나타내기 위한 클래스
        3. UPInt(void);
        4. UPInt(int value);
        5. ...
        6. };
        7.  
        8. const UPInt operator+(const UPInt& lhs, const UPInt& rhs);
        9.  
        10. UPInt upi1, upi2;
        11.  
        12. ...
        13. UPInt upi3 = upi1 + upi2;
        14.  
        15. // 여기서는 효율 문제가 발생하지 않습니다.
        16. // 다음 코드가 문제입니다.
        17.  
        18. upi3 = upi1 + 10;
        19. upi3 = 10 + upi2;
        20.  
        21. // 실행은 되지만 int 타입의 객체(값: 10)가
        22. // UPInt 타입의 객체로 암시적 변환이 일어날 때
        23. // 임시 객체가 생성됩니다.
        24.  
        25. // 임시 객체를 생성하지 않게 만들어, 임시 객체에
        26. // 대한 비용을 없애고 싶으면 다음과 같이 operator+의
        27. // 오버로딩 버전을 추가합니다.
        28.  
        29. const UPInt operator+(const UPInt& lhs, // UPInt와 UPInt를
        30.   const UPInt& rhs); // 더합니다.
        31.  
        32. const UPInt operator+(const UPInt& lhs, // UPInt와 int를
        33.   int rhs); // 더합니다.
        34.  
        35. const UPInt operator+(int lhs, // int와 UPInt를
        36.   const UPInt& rhs); // 더합니다.
        37.  
        38. UPInt upi1, upi2;
        39.  
        40. ...
        41. UPInt upi3 = upi1 + upi2; // 좋습니다. upi1 혹은 upi2에 대해
        42. // 임시 객체가 만들어지지 않습니다.
        43.  
        44. upi3 = upi1 + 10; // 좋습니다. upi1 혹은 10에 대해
        45. // 임시 객체가 만들어지지 않습니다.
        46.  
        47. upi3 = 10 + upi2; // 좋습니다. 10 혹은 upi2에 대해
        48. // 임시 객체가 만들어지지 않습니다.
        49.  
        50. // 하지만 다음은 에러입니다.
        51.  
        52. const UPInt operator+(int lhs, int rhs); // 딱 걸렸습니다. 에러!
        53.  
        54. // 정수형 끼리의 덧셈과 같은 기본 연산의 의미가 바뀌면
        55. // 심각한 혼란을 초래할 수 있어서, C++에서 연산자
        56. // 오버로딩은 '오버로딩되는 연산자 함수는 반드시 최소한
        57. // 한 개의 사용자 정의 타입을 매개변수로 가져야 한다'
        58. // 는 규칙을 따라야 합니다.

        
        
        예제 코드 접기
        
        
        

      • 물론 80-20 법칙(항목 16 참조)은 어디서든 고려 대상입니다. 프로파일링 결과 operator+가 성능에 큰 영향을 주지 않음에도 불구하고 함수를 오버로딩해서 쌓아 두는 것은 아무 의미도 없습니다.

  22. 단독 연산자(op) 대신에 =이 붙은 연산자(op=)를 사용하는 것이 좋을 때가 있다 / 166

      • 단독 연산자는 임시 객체를 생성하는 반면(항목 20 참조), 대입 형태 연산자는 임시 객체를 생성하지 않습니다. 따라서 단독 연산자와 대입 형태 연산자를 바꿔 써도 문제가 없는 상황이라면, 대입 형태 연산자를 쓰는 것이 효율적일 때가 많습니다. 예를 들어 x = x + y; 와 같이 쓰는 것 보다는 x += y;와 같이 쓰는 것이 더 효율적입니다.

        왜냐하면 단독 연산자는 두 피연산자를 변경하지 않고 두 피연산자를 연산한 값을 반환해야 하지만, 대입 형태 연산자는 좌측 피연산자의 값에 연산 결과를 저장하고 좌측 피연산자의 참조자를 반환하면 되기 때문입니다.
        
        예제 코드 보기
        
        
        

        1. Rational a, b, c, d, result;
        2. ...
        3. result = a + b + c + d; // 세 개의 임시 객체가 사용되는데,
        4. // 임시 객체 하나마다 operator+가
        5. // 호출됩니다.
        6.  
        7. result = a; // 임시 객체가 필요없습니다.
        8. result += b; // 임시 객체가 필요없습니다.
        9. result += c; // 임시 객체가 필요없습니다.
        10. result += d; // 임시 객체가 필요없습니다.
        11.  
        12. // +를 연달아 쓴 첫번째 코드는 작성하기도 좋고,
        13. // 디버깅하거나 유지보수하기에도 좋습니다.
        14.  
        15. // 그리고 실행시간의 80%를 잡아먹는 문제의
        16. // 부루주아 코드입니다(항목 16 참조).
        17.  
        18. // +=를 활용한 두번째 코드는 훨씬 효율적이고,
        19. // 어셈블리 언어 프로그래머의 눈에는 무척 읽기
        20. // 좋습니다.

        
        
        예제 코드 접기
        
        
        

      • 단독 연산자의 구현은 대입 형태 연산자를 사용하는 것이 좋습니다. 예를 들어 operator+의 구현에 operator+=를 사용하는 것입니다. 이렇게 하면 코드 중복을 줄여 유지 보수가 편해집니다. 또한 대입 형태의 연산자를 public으로 선언했다면, 단독 연산자를 프렌드로 지정하지 않아도 됩니다.

        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. class Rational {
        3. public:
        4. ...
        5. Rational& operator+=(const Rational& rhs);
        6. Rational& operator-=(const Rational& rhs);
        7. };
        8.  
        9. // operator+=를 사용해서 구현한 operator+입니다.
        10. const Rational operator+(const Rational& lhs,
        11. const Rational& rhs)
        12. {
        13. return Rational(lhs) += rhs;
        14. }
        15.  
        16. // operator-=을 사용해서 구현한 operator-
        17. const Rational operator-(const Rational& lhs,
        18. const Rational& rhs)
        19. {
        20. return Rational(lhs) -= rhs;
        21. }
        22.  
        23.  
        24. //-----------------------------------------------------------------------------
        25. // 단독 형태의 연산자를 모두 전역 유효범위(global scope)에
        26. // 두어도 크게 신경쓰지 않는다면, 다음과 같에 템플릿을
        27. // 만들어 두면, 클래스 안에다 단독 형태의 연산자 함수를
        28. // 구현할 필요 자체를 없앨 수 있습니다.
        29.  
        30. template <typename T>
        31. const T operator+(const T& lhs, const T& rhs)
        32. {
        33. return T(lhs) += rhs;
        34. }
        35.  
        36. template <typename T>
        37. const T operator-(const T& lhs, const T& rhs)
        38. {
        39. return T(lhs) -= rhs;
        40. }
        41.  
        42. ...
        43.  
        44. // 안타깝게도 어떤 컴파일러는 T(lhs)를 lhs의
        45. // 상수성을 제거한 캐스팅 결과로 취급해서,
        46. // rhs를 lhs에 더하고 값이 바뀐 lhs의
        47. // 참조자를 반환해 버리고 맙니다!
        48.  
        49.  
        50. //-----------------------------------------------------------------------------
        51. // 다음과 같은 코드는 구버전의 컴파일러에서
        52. // 효율 문제를 일으킬 수 있습니다.
        53.  
        54. template <typename T>
        55. const T operator+(const T& lhs, const T& rhs)
        56. {
        57. T result(lhs); // lhs를 result에 복사합니다.
        58. return result += rhs; // 여기에 rhs를 더하고 그것을 반환합니다.
        59. }
        60.  
        61. // result는 이름이 있는 객체라서 구버전의 컴파일러에서
        62. // 반환값 최적화가 제대로 안 될 수도 있습니다.

        
        
        예제 코드 접기
        
        
        

  23. 정 안 되면 다른 라이브러리를 사용하자! / 171

      • 라이브러리마다 효율, 확장성, 이식성, 타입 안전성 등에 대하여 다른 설계 철학을 가지고 구현되었기 때문에, 다른 사항보다 수행 성능 쪽에 많은 무게를 두어 설계한 라이브러리를 구할 수 있으면, 그것을 바꾸는 것만으로 손쉽게 소프트웨어의 효율을 향상시킬 수 있습니다.

        예를 들어 프로파일링 결과, 입·출력에 병목 현상이 있으면 iostream 대신에 stdio를 써서 성능을 개선할 수 있습니다(대개 iostream보다 stdio가 효율적입니다). 동적 메모리 할당이나 해제에 시간이 많이 걸리면 operator new와 operator delete(항목 8 참조)를 대신할 만한 것을 찾아 보셔도 좋습니다.

  24. 가상 함수, 다중 상속, 가상 기본 클래스, RTTI에 들어가는 비용을 제대로 파악하자 / 174

      • 어떤 클래스에 가상 함수가 하나 이상 있는 경우 그 클래스의 가상 함수 테이블(vtbl)이 하나 만들어 집니다. 가상 함수 테이블은 클래스에 있는 모든 가상 함수들의 (함수)포인터를 모아둔 배열입니다.

        가상 함수 테이블의 크기는 그 클래스가 갖는 가상 함수의 개수(기본 클래스에서 상속받는 것까지 합해서)에 비례하며, 가상 함수를 갖는 클래스 마다 하나씩 만들어 집니다. 프로그램에 들어가는 클래스의 수가 매우 많거나, 클래스에 가상 함수의 수가 매우 많은 경우, 결코 무시 못 할 정도의 메모리 부담이 들어갈 수 있습니다.

      • 가상 함수를 하나 이상 갖는 클래스 타입의 객체마다, 가상 함수 테이블의 시작 주소를 가리키는 멤버 포인터(가상 테이블 포인터: vptr)가 추가됩니다.

        크기가 작은 객체일수록 가상 테이블 포인터의 크기가 부담스러워 질 수 있습니다. 예를 들어 포인터 하나의 크기가 4 바이트라고 하면, 데이터 멤버의 크기가 4 바이트밖에 안되는 작은 객체는 가상 테이블 포인터 때문에 크기가 두 배 증가하게 됩니다. 소량의 한정된 메모리를 갖는 시스템에서는 이 비용이 치명적입니다.
        
        메모리를 걱정 없이 쓸 수 있는 시스템이라고 해도 소프트웨어의 수행 성능에서 손해를 봅니다. 덩치가 큰 객체는 캐시나 가상 메모리 페이지에 잘 맞지 않게 되는데, 결국 운영체제가 메모리 페이징을 더 많이 하는 결과를 낳기 때문입니다.

      • 가상 함수는 인라인으로 만들 수 없습니다. 왜냐하면 "인라인(inline)"이라 함은 "컴파일 도중에, 호출 위치에 호출되는 함수의 몸체를 끼워 넣는다"라는 뜻인데 반해, "가상(virtual)"이라 함은 "호출할 함수를 런타임까지 기다려 결정한다"라는 뜻이기 때문입니다.

        객체를 통해 가상 함수를 호출하는 경우에는 정적 바인딩이 일어나므로 가상 함수도 인라이닝을 할 수 있지만, 가상 함수는 대부분 포인터나 참조자를 통해 호출됩니다. 즉, 사실상 함수의 인라인 효과를 포기해야 합니다.

      • 가상 함수를 호출할때도 비가상 함수를 호출할 때 보다 많은 비용이 듭니다.

        C1클래스(혹은 C1의 파생 클래스)의 가상 함수 f1을, C1 타입의 포인터 pC1으로부터 호출하는 과정은 다음과 같습니다.
        
        
        1. pC1이 가리키는 객체의 vptr을 따라 vtbl로 갑니다.
        2. vtbl을 뒤져서 지금 호출해야 하는 함수(이 경우엔 f1)에 해당하는 포인터를 찾아옵니다.
        3. 2단계에서 가져온 포인터가 가리키는 함수를 호출합니다.
        
        종합해 봅시다. 가상 테이블이 vptr이고 f1의 가상 테이블 내 인덱스는 i라고 가정하면, 아래의 호출문은
        
        pC1->f1();
        
        다음과 같이 해석됩니다.
        
        (*pC1->vptr[i])(pC1);
        
        (pC1은 그 함수에 "this" 포인터로 넘겨집니다)

      • 지금까지 알아본 사항은 단일 상속과 다중 상속 모두 적용되는 것이었는데, 다중 상속까지 생각하면 더 복잡해 집니다. 그 결과, 클래스별 오버헤드와 객체별 오버헤드가 동시에 늘어나고, 런타임 생성 혹은 호출에 들어가는 비용도 그만큼 늘어납니다.

        다중 상속을 받은 경우 vptr의 위치를 찾는 오프셋 계산이 더욱 복잡해 집니다. 한 객체 안에 vptr이 여러개 들어있고(상속받은 클래스에서 하나씩 가져온 결과), 파생 클래스에 대한 vtbl 외에 기본 클래스에 대한 vtbl까지 꼬여 있어서 아주 심난할 지경입니다.

      • 다중 상속에 그림자처럼 따라오는 것이 가상 기본 클래스(virtual base class)입니다. 가상 기본 클래스도 그 나름대로의 비용 부담을 가져옵니다. 데이터 멤버의 중복을 피하기 위해 가상 기본 클래스 부분에 대한 포인터를 객체에 넣어 둔다던지 해야 하기 때문입니다.

        상세 내용 보기
        
        
        다음 코드와 같은 다중 상속 관계가 있다고 가정합시다.
        
        class A { ... };
        class B: virtual public A { ... };
        class C: virtual public A { ... };
        
        class D: public B, public C { ... };
        
        이 때 D 클래스 객체가 메모리에 올라간 구조는 대략 다음과 같을 것입니다(순서는 중요하지 않습니다. 포인터가 추가되었음이 중요합니다).
        
        
        
        실제로 저렇게 메모리에 올라갈지는 모릅니다. 컴파일러 구현에 따라 다르거든요. 심지어 어떤 컴파일러는 포인터를 추가하지 않는 경우도 있습니다(이런 경우에는 vptr과 vtbl이 맡은 부담이 2배로 늘어납니다).
        
        여기에 가상 테이블 포인터까지 표현하면 다음과 같이 될 것입니다(역시 순서는 중요하지 않습니다).
        
        
        
        컴파일러가 추가해 준 부분은 회색으로 칠했습니다. 들어간 포인터들과 데이터 멤버들이 차지하는 비율은 데이터 멤버가 얼마나 많으냐에 따라 달라질 수 있으므로, 이 그림을 너무 맹신하면 안됩니다.
        
        특이한 점은, 네 개의 클래스가 들어갔는데 vptr은 세 개뿐입니다. 이것은 컴파일러가 B와 D가 vptr을 공유할 수 있음을 이용하여 최적화를 한 결과입니다.
        
        상세 내용 접기
        
        
        

      • 보통 RTTI에 사용되는 타입 정보는 vtbl의 요소로 포함시킵니다(예를 들어 객체의 타입 정보를 vtbl의 첫 번째 요소로 집어넣습니다). 따라서 RTTI를 사용하게 되면 vtbl의 크기가 약간 늘어납니다.

        vtbl을 이용하여 RTTI를 구현하기 때문에 RTTI를 사용하려면 그 클래스에 가상 함수가 적어도 하나 이상은 있어야 합니다.
        
        가상 함수, 다중 상속, 가상 기본 클래스, RTTI에 들어가는 비용에 대해 찔러보면서 알아낸 것들을 다음의 표에 정리해 보았습니다.
        
        표 보기
        
        
        

        
        
        표 접기
        
        
        

• Chapter 5   유용하고 재미있는 프로그래밍 기법들(Techniques)

  25. 생성자 함수와 비(非)멤버 함수를 가상 함수처럼 만드는 방법 / 186

      • 가상 생성자란, 자신이 받은 입력 데이터에 의존하여 다른 타입의 객체를 생성하는 함수를 일컫습니다.

        예제 코드 보기
        
        
        

        1. class NLComponent { // 뉴스레터의 구성요소를
        2. public: // 나타내는 추상 기본 클래스
        3.  
        4. ... // 추상 클래스이므로, 순수 가상 함수가
        5. }; // 최소한 하나는 들어 있습니다.
        6.  
        7. class TextBlock: public NLComponent {
        8. public:
        9. ... // 순수 가상 함수가
        10. }; // 없습니다.
        11.  
        12. class Graphic: public NLComponent {
        13. public:
        14. ... // 순수 가상 함수가
        15. }; // 없습니다.
        16.  
        17. class NewsLetter { // 뉴스레터 객체 하나에는 뉴스레터 구성요소
        18. public: // 를 나타내는 NLComponent 객체가
        19. ... // 리스트로 관리됩니다.
        21. private:
        22. list<NLComponent*> components;
        23. };
        24.  
        25. // NewsLetter 객체는 컴퓨터의 메모리에 올라와
        26. // 쓰이지 않을 때에는 디스크에 저장해 두는 것이 대개
        27. // 일반적입니다. 그렇다면 istream을 취하는 생성자를
        28. // NewsLetter에 넣어 두는 것이 꽤 괜찮을
        29. // 것입니다.
        30.  
        31. class NewsLetter {
        32. public:
        33. ...
        34. private:
        35. // str에서 바로 다음의 NLComponent 데이터를 읽고,
        36. // 메모리에 객체를 생성하고 데이터를 세팅한 후에 포인터를 반환합니다.
        37. static NLComponent * readComponent(istream& str);
        38. ...
        39. };
        40.  
        41. // NewsLetter의 생성자
        42. NewsLetter::NewsLetter(istream& str)
        43. {
        44. while (str) {
        45. // readComponent에서 반환된 포인터를 뉴스레터 구성요소 리스트
        46. // 의 끝에 추가합니다.
        47. components.push_back(readComponent(str));
        48. }
        49. }
        50.  
        51. // readComponent 함수는 런타임에 디스크에서 읽은
        52. // 정보에 따라 다른 타입의 객체를 만들기 때문에 이 함수를
        53. // 가상 생성자(virtual constructor)라고 부를 수
        54. // 있습니다.

        
        
        예제 코드 접기
        
        
        

      • 가상 생성자 중 특히 널리 쓰이는 놈이 가상 복사 생성자(virtual copy constructor)입니다. 가상 복사 생성자는 이것을 호출한 객체를 그대로 본 뜬 사본의 포인터를 반환합니다. 이런 성질 때문에 copySelf, cloneSelf 아니면 예제와 같이 간단하게 clone 등으로 불리기도 합니다.

        예제 코드 보기
        
        
        

        1. class NLComponent {
        2. public:
        3. // 가상 복사 생성자의 선언
        4. virtual NLComponent * clone(void) const = 0;
        5. ...
        6. };
        7.  
        8. class TextBlock: public NLComponent {
        9. public:
        10. virtual TextBlock * clone(void) const {
        11. return new TextBlock(*this); // 가상 복사
        12. } // 생성자
        13. ...
        14. };
        15.  
        16. class Graphic: public NLComponent {
        17. public:
        18. virtual Graphic * clone(void) const {
        19. return new Graphic(*this); // 가상 복사
        20. } // 생성자
        21. ...
        22. };
        23.  
        24. // C++의 가상 복사 생성자는 비교적 최근에 완화된
        25. // 가상 함수의 반환 타입 규칙을 사용한 기법입니다.
        26.  
        27. // 완화된 규칙에 의하면, 기본 클래스의 가상 함수를
        28. // 재정의한 파생 클래스의 가상 함수는 똑같은 반환
        29. // 타입을 갖지 않아도 됩니다.
        30.  
        31. // NLComponent에 가상 복사 생성자가 들어가고 나면,
        32. // NewsLetter의 (보통) 복사 생성자도 훨씬 쉽게
        33. // 구현할 수 있게 됩니다.
        34.  
        35. class NewsLetter {
        36. public:
        37. NewsLetter(const NewsLetter& rhs);
        38. ...
        39. private:
        40. list<NLComponent*> components;
        41. };
        42.  
        43. NewsLetter::NewsLetter(const NewsLetter& rhs)
        44. {
        45. // rhs 안에 있는 리스트에 대해 루프를 돌면서, 각 리스트 요소의
        46. // 가상 복사 생성자를 호출하여 해당되는 뉴스레터 구성요소를
        47. // 복사합니다.
        48. for (list<NLComponent*>::const_iterator it =
        49. rhs.components.begin();
        50. it != rhs.components.end();
        51. ++it) {
        52. components.push_back((*it)->clone());
        53. }
        54. }

        
        
        예제 코드 접기
        
        
        

      • 비멤버 함수를 가상 함수처럼 동작하도록 만들고 싶다면, 해당 기능을 하는 가상 멤버 함수를 만들고, 비멤버 함수가 그 가상 멤버 함수를 호출하도록 만듭니다.

        예제 코드 보기
        
        
        

        1. class NLComponent {
        2. public:
        3. virtual ostream& print(ostream& s) const = 0;
        4. ...
        5. };
        6.  
        7. class TextBlock: public NLComponent {
        8. public:
        9. virtual ostream& print(ostream& s) const;
        10. ...
        11. };
        12.  
        13. class Graphic: public NLComponent {
        14. public:
        15. virtual ostream& print(ostream& s) const;
        16. ...
        17. };
        18.  
        19. inline ostream& operator<<(ostream& s, const NLComponent& c)
        20. {
        21. return c.print(s);
        22. }

        
        
        예제 코드 접기
        
        
        

  26. 클래스 인스턴스의 개수를 의도대로 제한하는 방법 / 193

      • 객체를 전혀 생성하지 않거나 한 개만 생성하기

        특정한 클래스의 객체가 만들어지지 않게 하는 가장 쉬운 방법은 그 클래스의 생성자를 private로 선언하는 것입니다. 이것을 출발점으로 해서 조금씩 제약을 풀어 가는 것입니다.
        
        만일 프린터를 제어하는 클래스의 객체를 만들어야 하는데, 사용 가능한 프린터 객체의 개수를 한 개로 제한하고 싶다면, 프린터 객체를 생성자 함수 안에 그냥 넣는 것입니다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. class PrintJob;
        3.  
        4. class Printer {
        5. public:
        6. void submitJob(const PrintJob& job);
        7. void reset(void);
        8. void performSelfTest(void);
        9. ...
        10. friend Printer& thePrinter(void);
        11. private:
        12. printer(void);
        13. printer(const Printer& rhs);
        14. ...
        15. };
        16.  
        17. Printer& thePrinter(void)
        18. {
        19. static Printer p; // 프린터 객체는 하나입니다.
        20. return p;
        21. }
        22.  
        23. // 사용자는 프린터 객체를 쓰고 싶을 때마다 언제나
        24. // thePrinter를 불러 낼 수 있습니다.
        25.  
        26. class PrintJob {
        27. public:
        28. PrintJob(const string& whatToPrint);
        29. ...
        30. };
        31.  
        32. string buffer;
        33. ... // buffer에 출력할 것을 채웁니다.
        34. thePrinter().reset();
        35. thePrinter().submitJob(buffer);
        36.  
        37.  
        38. //-----------------------------------------------------------------------------
        39. // 전역에 thePrinter함수를 놓는 것이 걱정된다면,
        40. // thePrinter함수를 Printer 클래스의 정적 멤버 함수로
        41. // 만들면 됩니다.
        42. class Printer {
        43. public:
        44. static Printer& thePrinter(void);
        45. ...
        46. private:
        47. Printer(void);
        48. Printer(const Printer& rhs);
        49. ...
        50. };
        51.  
        52. Printer& Printer::thePrinter(void)
        53. {
        54. static Printer p;
        55. return p;
        56. }
        57.  
        58. Printer::thePrinter().reset();
        59. Printer::thePrinter().submitJob(buffer);
        60.  
        61.  
        62. //-----------------------------------------------------------------------------
        63. // thePrinter함수를 네임스페이스 안에
        64. // 넣어버리는 방법도 있습니다.
        65. namespace PrintingStuff {
        66. class Printer { // 이 클래스가 PrintingStuff
        67. public: // 네임스페이스에 들어가게 되었습니다.
        68. void submitJob(const PrintJob& job);
        69. void reset(void);
        70. void performSelfTest(void);
        71. ...
        72. friend Printer& thePrinter(void);
        73. private:
        74. Printer(void);
        75. Printer(const Printer& rhs);
        76. ...
        77. };
        79. // 이 함수도 마찬가지
        80. Printer& thePrinter(void)
        81. {
        82. static Printer p;
        83. return p;
        84. }
        85. }
        86.  
        87. PrintingStuff::thePrinter().reset();
        88. PrintingStuff::thePrinter().submitJob(buffer);
        89.  
        90. // 네임스페이스를 일일히 타이핑하기 힘들다면
        91. // using 선언(using declaration)을
        92. // 활용할 수 있습니다.
        93.  
        94. using PrintingStuff::thePrinter;
        95.  
        96. thePrinter().reset();
        97. thePrinter().submitJob(buffer);
        98.  
        99.  
        100. //-----------------------------------------------------------------------------
        101. // thePrinter 함수 안에 Printer의 정적 객체를 만드는 기법은
        102. // Printer의 정적 데이터 멤버로 만드는 것 보다 두 가지 장점이
        103. // 있습니다.
        104.  
        105. // 1. 정적 데이터 멤버는, 그것이 사용되든 사용되지 않든 상관없이
        106. //　　생성되고 소멸됩니다. 반면, 함수 안에서 정적 변수로 선언된
        107. //　　객체는 그 함수가 최소한 한 번 호출되어야 생성됩니다.
        108.  
        109. // 2. 클래스에 정적 데이터 멤버로 선언된 객체의 초기화 시점은
        110. //　　명확하게 정의되어 있지 않습니다. C++은 하나의 컴파일 단위
        111. //　　안에 선언된 정적 객체들의 초기화 순서는 엄격하게 보장하고
        112. //　　있지만, 서로 다른 컴파일 단위마다 뿔뿔이 흩어진 정적 객체의
        113. //　　초기화 순서는 명확하게 정해져 있지 않습니다. 이로 인해
        114. //　　많은 문제가 발생할 수 있습니다. 반면, 함수 안에서 정적
        115. //　　변수로 선언된 객체는 그 함수가 호출될 때 반드시 초기화
        116. //　　됩니다.
        117.  
        118. // 또 한가지 주의해야 할 점은 thePrinter함수와 같이 정적 객체를
        119. // 선언한 비멤버 함수는 절대로 인라인으로 선언하면 안 됩니다.
        120.  
        121. // 왜냐하면 비멤버 함수에 있어서 inline은 "이 함수는 내부 연결
        122. // (internal linked)을 가진다."라는 뜻인데,
        123. // 내부 연결을 갖는 함수는 한 프로그램 내에서 중복되어 존재할 수
        124. // 있습니다. 즉 내부의 정적 변수도 두 개 이상 존재할 수 있게 됩니다.
        125.  
        126. // 하지만 1996년 7월 ISO/ANSI의 C++표준 위원회에서는 인라인
        127. // 함수가 갖는 연결 형태를 외부(external) 연결로 변경하였습니다.
        128. // 즉 이후에 만들어진 컴파일러를 사용한다면 이러한 문제는 발생하지 않으나,
        129. // 오래된 컴파일러를 사용한다면, 정적 데이터를 인라인 함수에 집어 넣는
        130. // 일은 피해야 합니다.

        
        
        예제 코드 접기
        
        
        '숨겨진' 객체의 참조자를 반환하는 방법이 '좀 마음에 안 든다' 라고 생각하신다면 생성된 객체의 개수를 직접 세어서, 일정한 개수가 넘어갔을 때 예외를 일으키는 방법을 사용할 수도 있습니다.
        
        예제 코드 보기
        
        
        

        1. class Printer {
        2. public:
        3. class TooManyObjects{}; // 너무 많은 객체가
        4. // 요구될 때 발생시키려고
        5. // 만든 예외 클래스
        7. Printer(void);
        8. ~Printer(void);
        9. ...
        10. private:
        11. static size_t numObjects;
        12. Printer(const Printer& rhs); // 프린터 객체는 한 개로
        13. // 제한했으므로, 복사는
        14. }; // 금지합니다.
        15.  
        16. // 클래스의 정적 멤버 변수이므로 초기화가 필요합니다.
        17. size_t Printer::numObjects = 0;
        18.  
        19. Printer::Printer(void)
        20. {
        21. if (numObjects >= 1) {
        22. throw TooManyObjects();
        23. }
        24. 여느 때와 같은 객체 생성(필드 세팅) 과정을 진행합니다;
        25. ++numObjects;
        26. }
        27.  
        28. Printer::~Printer(void)
        29. {
        30. 여느 때와 같은 객체 소멸 과정을 수행합니다;
        31. --numObjects;
        32. }

        
        
        예제 코드 접기
        
        
        

      • 객체 생성이 이루어지는 세 가지 상황

        하지만 생성자와 소멸자를 이용해 객체의 수를 세는 방법에도 문제가 숨어 있습니다. 만일 Printer로부터 상속받아 만든 새로운 클래스가 있다면 새로운 클래스를 생성할때도 Printer 객체의 생성자고 호출되어 Printer 객체의 수를 제대로 셀 수 없게 됩니다. Printer 객체가 다른 객체에 포함될 때에도 비슷한 문제가 발생합니다.
        
        여기서 문제가 되는 점은 Printer 객체가 세 가지 상황에서 생성될 수 있다는 점입니다.
        • 첫 번째: 그 자체로 생성될 때
        • 두 번째: 파생된 객체의 기본 클래스 부분으로 만들어질 때
        • 세 번째: 다른 객체의 클래스 멤버로서 만들어질 때
        
        이런 경우에는 앞서 보여드렸던 생성자를 private로 선언하는 방법을 사용하면 소기의 목적을 간단히 달성할 수 있습니다. 왜냐하면, 생성자가 private로 선언된 클래스는 기본 클래스로 사용될 수 없으며, 다른 객체의 클래스 멤버로 들어갈 수도 없기 때문입니다. private 생성자를 가진 클래스를 기본 클래스로 쓸 수 없다는 사실은, 클래스 상속을 막는 일반적인 방법으로 끌어 낼 수도 있습니다.
        
        예제 코드 보기
        
        
        

        1. // 유한 상태 오토마타(finite state automata)
        2. // 를 C++로 만들기 위해 FSA라는 클래스를
        3. // 하나 정의했다고 가정합시다.
        4.  
        5. // 이 FSA클래스는 객체 생성은 몇 개라도
        6. // 할 수 있지만, 이 클래스로부터의 상속은
        7. // 절대로 할 수 없도록 만들고 싶습니다.
        8.  
        9. class FSA {
        10. public:
        11. // 유사 생성자(pseudo-constructor)
        12. static FSA * makeFSA(void);
        13. static FSA * makeFSA(const FSA& rhs);
        14. ...
        15. private:
        16. FSA(void);
        17. FSA(const FSA& rhs);
        18. ...
        19. };
        20.  
        21. FSA * FSA::makeFSA(void)
        22. { return new FSA(); }
        23.  
        24. FSA * FSA::makeFSA(const FSA& rhs)
        25. { return new FSA(rhs); }
        26.  
        27. // 유사 생성자가 호출될 때마다 new가
        28. // 호출된다는 사실에는, 이 함수를 호출한
        29. // 쪽에서 반드시 delete를 호출해야 한다는
        30. // 의미가 배어 있습니다.
        31.  
        32. // 이를 좀 더 개선하려면
        33. // auto_ptr이나 shared_ptr과 같은
        34. // 스마트 포인터를 사용하면 됩니다.

        
        
        예제 코드 접기
        
        
        

      • 객체를 불러냈다가 들여보내는것도 자유롭게 하고 싶다!

        thePrinter 함수를 설계한 방법은 Printer 객체의 개수를 딱 한 개로 묶어버리는 것이지만, 이 방법은 실행되는 프로그램 하나에 사용되는 Printer 객체의 개수를 딱 한 개로 묶어버리기도 합니다. 즉 다음과 같은 코드를 쓸 수 없습니다.
        
        
        Printer 객체 p1을 생성합니다;
        p1을 사용합니다;
        p1을 소멸시킵니다;
        
        Printer 객체 p2를 생성합니다;
        p2를 사용합니다;
        p2를 소멸시킵니다;
        
        이를 해결하기 위한 방법도 당연히 있습니다. 방금 전에 보았던 유사 생성자와 앞에서 사용했던 카운팅 코드를 합치면 일은 끝납니다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. class Printer {
        3. public:
        4. class TooManyObjects{};
        6. // 유사 생성자 두 개
        7. static Printer * makePrinter(void);
        9. ~Printer(void);
        10. void submitJob(const PrintJob& job);
        11. void reset(void);
        12. void performSelfTest(void);
        13. ...
        14. private:
        15. static size_t numObjects;
        16. Printer(void);
        17. Printer(const Printer& rhs); // 이 함수는 정의하지 않습니다.
        18. }; // 왜냐하면 객체의 복사를
        19. // 허용하지 않을 테니까요.
        20. // 클래스의 정적 멤버이기 때문에 꼭 정의해야 합니다.
        21. size_t Printer::numObjects = 0;
        22.  
        23. Printer::Printer(void)
        24. {
        25. if (numObjects >= 1) {
        26. throw TooManyObjects();
        27. }
        28. 여느 때와 같은 객체 생성(필드 세팅) 과정을 진행합니다;
        29. ++numObjects;
        30. }
        31.  
        32. Printer * Printer::makePrinter(void)
        33. { return new Printer; }
        34.  
        35. // 객체 생성이 요청된 횟수가 일정 횟수를 초과할 때,
        36. // 예외를 일으키는 방법 대신 널 포인터를 반환하도록
        37. // 만들 수도 있습니다. 물론, 클래스 사용자로 하여금
        38. // 포인터의 널 체크를 통해 상태를 파악하도록 해야
        39. // 하겠지요.
        40.  
        41. Printer p1; // 에러입니다! 기본 생성자는
        42. // private입니다.
        43.  
        44. Printer *p2 = // 문제없습니다. 기본 생성자를
        45. Printer::makePrinter(); // 간접적으로 호출합니다.
        46.  
        47. Printer p3 = *p2; // 에러입니다! 복사 생성자는
        48. // private입니다.
        49.  
        50. p2->performSelfTest(); // 이외의 다른 함수들은
        51. p2->reset(); // 보통처럼 호출됩니다.
        52. ...
        53. delete p2; // 리소스 누수를 막습니다.
        54. // 만약 p2가 스마트 포인터의 인스턴스였으면,
        55. // 이런 삭제도 필요없습니다.
        56.  
        57.  
        58. //-----------------------------------------------------------------------------
        59. // 이 방법은 객체의 생성 개수를 임의의 개수로
        60. // 제한하는 쪽으로 간단히 일반화 할 수 있습니다.
        61.  
        62. class Printer {
        63. public:
        64. class TooManyObjects{};
        66. // 유사 생성자
        67. static Printer * makePrinter(void);
        68. static Printer * makePrinter(const Printer& rhs);
        69. ...
        70. private:
        71. static size_t numObjects;
        72. static const size_t maxObjects = 10;
        74. Printer(void);
        75. Printer(const Printer& rhs);
        76. };
        77.  
        78. // 클래스의 정적 멤버이기 때문에 꼭 정의해야 합니다.
        79. size_t Printer::numObjects = 0;
        80. const size_t Printer::maxObjects;
        81.  
        82. Printer::Printer(void)
        83. {
        84. if (numObjects >= maxObjects) {
        85. throw TooManyObjects();
        86. }
        87. ...
        88. ++numObjects;
        89. }
        90.  
        91. Printer::Printer(const Printer& rhs)
        92. {
        93. if (numObjects >= maxObjects) {
        94. throw TooManyObjects();
        95. }
        96. ...
        97. ++numObjects;
        98. }
        99.  
        100. Printer * Printer::makePrinter(void)
        101. { return new Printer; }
        102.  
        103. Printer * Printer::makePrinter(const Printer& rhs)
        104. { return new Printer(rhs); }

        
        
        예제 코드 접기
        
        
        

      • 인스턴스 카운팅(Object-Counting) 기능을 가진 기본 클래스

        Printer와 같이 객체의 개수를 제한해야 하는 클래스가 매우 많이 필요하다면 관련 코드에 많은 중복이 일어날 것은 불을 보듯 뻔합니다. 물론, 인스턴스 카운팅 기능을 가진 기본 클래스를 만들어서 Printer같은 클래스에서 이것을 상속하게 하면, 눈앞의 불은 끌 수 있습니다. 하지만 조금만 더 생각하면 좀더 깔끔하고 더 좋은 기능을 뽑아낼 수도 있습니다.
        
        Printer 클래스의 객체 개수를 유지하는 값은 정적 변수로 선언된 numObjects에 저장됩니다. 따라서 이 변수를 인스턴스 카운팅 클래스에 넣으면 될 것 같습니다. 하지만, 인스턴스의 수를 세는 클래스마다 별도의 카운터를 두어야 한다는 점도 염두해 두어야 합니다. 이런 고민의 결과로 만든 것이 예제의 클래스 템플릿입니다. 인스턴스 카운터는 이 클래스 템플릿으로부터 만들어진 클래스의 정적 멤버로 들어가기 때문에, 원하는 개수만큼의 카운터를 자동으로 만들 수 있습니다.
        
        예제 코드 보기
        
        
        

        1. template <class BeingCounted>
        2. class Counted {
        3. public:
        4. class TooManyObjects{}; // 예외를 일으킬 때 사용하는 객체
        5. static size_t objectCount(void) {
        6. return numObjects;
        7. }
        9. protected:
        10. Counted(void);
        11. Counted(const Counted& rhs);
        13. ~Counted(void) {
        14. --numObjects;
        15. }
        17. private:
        18. static size_t numObjects;
        19. static const size_t maxObjects;
        20. void init(void); // 생성자 코드를 중복해서 작성하는
        21. }; // 일을 막기 위해 만든 함수
        22.  
        23. template <class BeingCounted>
        24. Counted<BeingCounted>::Counted(void)
        25. { init(); }
        26.  
        27. template <class BeingCounted>
        28. Counted<BeingCounted>::Counted(const Counted<BeingCounted>&)
        29. { init(); }
        30.  
        31. template <class BeingCounted>
        32. void Counted<BeingCounted>::init(void)
        33. {
        34. if (numObjects >= maxObjects) {
        35. throw TooManyObjects();
        36. }
        37. ++numObjects;
        38. }
        39.  
        40. // 이 템플릿으로부터 만들어지는 클래스는 기본 클래스로만
        41. // 사용되도록 설계되었기 때문에, 생성자와 소멸자가 모두
        42. // protected로 선언되어 있습니다.
        43.  
        44. // 이제 Printer 클래스를 Counted 템플릿을
        45. // 사용하도록 고쳐보겠습니다.
        46.  
        47. class Printer: private Counted<Printer> {
        48. public:
        49. // 유사 생성자들
        50. static Printer * makePrinter(void);
        51. static Printer * makePrinter(const Printer& rhs);
        52. ~Printer(void);
        53. void submitJob(const PrintJob& job);
        54. void reset(void);
        55. void performSelfTest(void);
        56. ...
        57. using Counted<Printer>::ObjectCount; // 다음을 보세요.
        58. using Counted<Printer>::TooManyObjects; // 다음을 보세요.
        59. private:
        60. Printer(void);
        61. Printer(const Printer& rhs);
        62. };
        63.  
        64. // 만일 Printer클래스가 Counted<Printer>를
        65. // public 상속한다면 Counted의 소멸자가
        66. // 가상 소멸자가 되어야 할 것입니다. 항목 24에서 보았듯
        67. // 그에 따른 비용도 지불해야 하죠. private 상속은
        68. // 이런 문제를 해결해 줍니다.
        69.  
        70. // private 상속 때문에 Counted의 public으로 선언된
        71. // 멤버함수 마저 private가 되어 버렸습니다.
        72. // 따라서, 이 함수가 원래 가지고 있는 public 성질(접근성)을
        73. // 되돌리기 위해 using 선언이 사용되었습니다.
        74.  
        75. // 예외가 발생했을 때 받을 수도 있어야 하므로
        76. // TooManyObjects도 마찬가지로
        77. // using 선언을 사용해 줍니다.
        78.  
        79. // 이제 Printer는 더 이상 객체의 개수에 대해
        80. // 신경쓰지 않아도 됩니다. 인스턴스 카운팅은 Counted<Printer>가
        81. // 알아서 해 주기 때문입니다.
        82.  
        83. // 마무리지어야 할 부분이 아직 남아 있습니다.
        84. // 무엇인고 하니, Counted 안에 선언되어 있는
        85. // 정적 상수 멤버를 두고 하는 말입니다.
        86.  
        87. // 일단 numObjects는 처리하기 쉽습니다.
        88. // Counted의 구현 파일에 다음과 같이 쓰기만 하면 됩니다.
        89.  
        90. template <class BeingCounted> // numObjects를 구현 파일에
        91. size_t Counted<BeingCounted>::numObjects; // 정의하면, 자동으로 0으로
        92. // 초기화됩니다. 구식의 컴파일러는
        93. // 0으로 초기화 하지 않을 수도 있으니
        94. // 주의하기 바랍니다.
        95.  
        96. // maxObjects의 경우에는 BeingCounted의 타입에
        97. // 따라 다른 값으로 초기화 되어야 합니다. 이럴땐 고민하지
        98. // 말고 클래스 사용자에게 초기화를 맡겨 버립시다. 즉,
        99. // Printer 클래스의 경우에는 Printer를 만드는 사람이
        100. // 직접 구현 파일에 다음과 같은 초기화 문장을 넣어야 합니다.
        101.  
        102. const size_t Counted<Printer>::maxObjects = 10;

        
        
        예제 코드 접기
        
        
        

  27. 힙(heap)에만 생성되거나 힙에는 만들어지지 않는 특수한 클래스를 만드는 방법 / 212

      • 객체가 힙에만 생성되게 하기

        개발자(사용자)들이 new 이외의 방법으로는 객체를 생성할 수 없도록 하면 됩니다. 힙에 만들어지지 않는(Non-heap) 객체는 소스 코드에 선언된 위치에서 자동으로 생성되고, 자신의 유효범위(scope)가 끝나는 위치에서 자동으로 소멸되기 때문에, 이런 방식의 암시적(implicit) 객체 생성/소멸을 불법(illegal)화 시키면 간단히 해결됩니다.
        
        생성자와 소멸자를 private로 선언하고 대신 유사 생성/소멸자(항목 26 참조)를 통해 간접적으로 호출할 수 있도록 하면, 가장 확실히 소기의 목적을 달성할 수 있습니다. 하지만 굳이 생성자와 소멸자를 모두 private로 선언할 필요는 없고 소멸자만 private로 선언해도 목적을 달성할 수 있습니다. 생성자는 개수가 많을 수도 있기 때문에 모든 생성자를 private로 선언하기가 번거로울 수도 있어서, 소멸자만 private로 만드는 편이 더 낫습니다.
        
        예제 코드 보기
        
        
        

        1. class UPNumber {
        2. public:
        3. UPNumber(void);
        4. UPNumber(int initValue);
        5. UPNumber(double initValue);
        6. UPNumber(const UPNumber& rhs);
        8. // 유사 소멸자(const 멤버 함수입니다. 왜냐하면
        9. // 상수 객체도 소멸될 수 있기 때문입니다).
        10. void destroy(void) const {
        11. delete this;
        12. }
        13. ...
        14. private:
        15. ~UPNumber(void);
        16. };
        17.  
        18. UPNumber n; // 에러입니다! (지금은 불법이 아니지만,
        19. // 나중에 n의 소멸자가 암시적으로
        20. // 호출될 때 불법이 됩니다)
        21.  
        22. UPNumber *p = new UPNumber; // 문제없습니다.
        23. ...
        24. delete p; // 에러입니다! private로 선언된
        25. // 소멸자는 호출할 수 없습니다.
        26.  
        27. p->destroy(); // 문제없습니다.

        
        
        예제 코드 접기
        
        
        하지만 생성자나 소멸자를 private로 선언하면 항목 26에서 이야기했듯이 이 클래스를 상속하거나 이 클래스 인스턴스를 다른 객체의 멤버로 넣는 일을 모두 할 수 없게 됩니다.
        
        이런 문제는 어렵지 않게 해결할 수 있습니다. 상속이 안 되는 문제는 소멸자를 protected로 바꾸면 해결할 수 있고(생성자는 public으로 유지하고요), 힙에만 생성되는 객체를 다른 객체에 넣지 못하는 문제는 객체 대신에 그 객체의 포인터를 넣으면 간단히 해결할 수 있습니다.
        
        예제 코드 보기
        
        
        

        1. class UPNumber { ... }; // 소멸자를 protected로 선언한 클래스
        2.  
        3. class NonNegativeUPNumber: // 이젠 문제없습니다. 파생
        4. public UPNumber { ... }; // 클래스는 protected 멤버에
        5. // 접근할 수 있습니다.
        6.  
        7. class Asset {
        8. public:
        9. Asset(int initValue);
        10. ~Asset(void);
        11. ...
        12. private:
        13. UPNumber *value;
        14. };
        15.  
        16. Asset::Asset(int initValue)
        17. : value(new UPNumber(initValue)) // 문제없습니다.
        18. { ... }
        19. Asset::~Asset(void)
        20. { value->destroy(); } // 역시 문제없습니다.

        
        
        예제 코드 접기
        
        
        

      • 어떤 객체가 힙에 생성되었는지, 그렇지 않은지를 알아내는 방법

        소멸자를 protected로 선언하여 객체가 힙에만 생성되도록 만든 클래스 UPNumber를 상속받아 구현된 클래스 NonNegativeUPNumber가 있고, NonNegativeUPNumber의 객체는 힙에만 생성된다는 보장이 없는 경우에 NonNegativeUPNumber의 UPNumber부분 역시 힙에만 생성된다고 보장할 수 없게 됩니다. 이 때 UPNumber가 힙에 생성되었는지, 혹은 그렇지 않은지를 알아내는 방법이 있을까요?
        
        다음 몇 가지 방법은 어떤 객체가 힙에 생성되었는지, 혹은 그렇지 않은지를 알아내는 바람직하지 못한 예시입니다.
        1. operator new 함수와 operator new[] 함수를 오버로딩해서 동적 할당시에, bool 타입의 정적 변수의 값을 true로 만들고 생성자에서 이 값을 점검하는 방법이 있습니다. 이 방법은 동적 배열 생성과 같은 상황 등에서 제대로 작동하지 않습니다.
           
           바람직하지 않은 예제 코드 보기
           
           
           

           1. class UPNumber {
           2. public:
           3. // 힙 기반이 아닌 객체가 생성될 때 일으킬 예외 클래스
           4. class HeapConstraintViolation {};
           6. static void * operator new(size_t size);
           8. UPNumber(void);
           9. ...
           10. private:
           11. static bool onTheHeap; // 객체가 힙에서 만들어지든
           12. ... // 그렇지 않든 생성자는
           13. }; // 호출됩니다.
           14.  
           15. // 클래스 정적 멤버는 반드시 정의해야 합니다.
           16. bool UPNumber::onTheHeap = false;
           17.  
           18. void *UPNumber::operator new(size_t size)
           19. {
           20. onTheHeap = true;
           21. return ::operator new(size);
           22. }
           23.  
           24. UPNumber::UPNumber(void)
           25. {
           26. if (!onTheHeap) {
           27. throw HeapConstraintViolation();
           28. }
           30. 여느 때와 같은 객체 생성(필드 세팅) 과정을 진행합니다;
           32. onTheHeap = false; // 다음 객체를 위하여 플래그를 초기화합니다.
           33. }
           34.  
           35. // 이런 식의 구현이죠.
           36.  
           37. // 여기서는 operator new[]를 오버로딩 하지
           38. // 않았지만 오버로딩 해도 마찬가지입니다.
           39.  
           40. // 다음을 보세요.
           41.  
           42. UPNumber *numberArray = new UPNumber[100];
           43.  
           44. // operator new[]를 오버로딩 했다고 하더라도
           45. // operator new[]는 처음 메모리를 할당할 때
           46. // 딱 한 번만 불립니다. 따라서 배열의 첫 객체는
           47. // 제대로 생성자가 호출되지만 그 다음 객체부터는
           48. // onTheHeap이 false가 되어 생성자에서
           49. // 예외가 발생할 것입니다.
           50.  
           51. // 배열의 경우가 아니더라도 다음과 같은 코드를 작성한 경우
           52. // 문제가 생길 수 있습니다.
           53.  
           54. UPNumber *pn = new UPNumber(*new UPNumber);
           55.  
           56. // 이 코드는 자원이 누출되지만 지금 보고자 하는 것은
           57. // 자원의 누출이 아닙니다.
           58.  
           59. // 위의 코드를 작성한 프로그래머는 다음과 같은 순서대로
           60. // 작동할 것이라고 생각했을 것입니다.
           61.  
           62. // 1. 첫째 객체(가장 왼쪽 것)에 대해 operator new를 호출함
           63. // 2. 첫째 객체에 대해 생성자를 호출함
           64. // 3. 둘째 객체에 대해 operator new를 호출함
           65. // 4. 둘째 객체에 대해 생성자를 호출함
           66.  
           67.  
           68. // 하지만 C++ 언어 스펙에서는 반드시 이 순서대로 작동한다고
           69. // 못박은 규정을 찾아볼 수 없습니다. 즉 컴파일러에 따라
           70. // 다음과 같은 순서대로 작동할 가능성도 있습니다.
           71.  
           72. // 1. 첫째 객체에 대해 operator new를 호출함
           73. // 2. 둘째 객체에 대해 operator new를 호출함
           74. // 3. 첫째 객체에 대해 생성자를 호출함
           75. // 4. 둘째 객체에 대해 생성자를 호출함
           76.  
           77.  
           78. // 이렇게 되면 배열을 생성할 때와 마찬가지로
           79. // 두 번째 객체의 생성자가 불릴 때에는 onTheHeap의 값이
           80. // false일 것이므로 예외가 발생할 것입니다.
           81.  

           
           
           바람직하지 않은 예제 코드 접기
           
           
           
        2. 프로그램에서 스택 영역과 힙 영역의 위치가 분리되어 있다는 점(대부분의 시스템은 상위 주소의 스택 영역이 아래로 자라고, 하위 주소의 힙 영역이 위로 자랍니다)을 이용하여 객체가 할당된 주소의 크기를 비교하는 방법을 쓸 수 있습니다. 이 방법의 문제는 두 가지가 있는데, 우선 이식성이 떨어집니다. 드물지만 어떤 시스템에서는 메모리에서 힙과 스택의 주소가 반대로 배치되어 있는 경우도 있다고 합니다.
           
           이식성 이외의 다른 문제는, 바로 객체가 생성되는 장소가 세 가지라는 점입니다. 스택과 힙 이외에 정적 객체(static이 붙은 객체 혹은 전역이나 네임스페이스 안에 선언된 객체)가 만들어지는 메모리 공간이 따로 있는데, 이 공간의 위치는 시스템 마다 다릅니다. 하지만 스택과 힙 영역이 상대방 쪽으로 자라도록 하는 시스템에서는 대개 정적 객체를 힙의 아래쪽에 둡니다. 즉 단순히 스택에 생성된 객체와의 객체 주소 비교를 통해서는 힙에 생성되었는지, 정적 객체의 영역에 생성되었는지를 구별할 수 없게 됩니다.
           
           바람직하지 않은 예제 코드 보기
           
           
           

           1. // 어떤 주소값이 힙 영역에 있는지 알아내는
           2. // 바람직하지 않은 방법
           3. bool onHeap(const void *address)
           4. {
           5. char onTheStack; // 스택에 만들어지는 지역 변수
           7. return address < &onTheStack;
           8. }
           9.  
           10. void allocateSomeObject(void)
           11. {
           12. char *pc = new char; // 힙 객체입니다. 따라서
           13. // onHeap(pc)는 true를 반환합니다.
           15. char c; // 스택 객체입니다. 따라서
           16. // onHeap(&c)는 false를 반환합니다.
           18. static char sc; // 정적 객체입니다. 그런데
           19. // onHeap(&sc)는 true를 반환합니다.
           20. ...
           21. }

           
           
           바람직하지 않은 예제 코드 접기
           
           
           
        3. 이렇게, 어떤 객체가 힙에 생성되었는지, 혹은 그렇지 않은지를 알아내기란 힘듭니다. 그럼에도 불구하고 어떤 객체가 힙에 생성되었는지를 알아내려고 하는 가장 그럴듯한 이유는 어떤 포인터에 delete를 해도 괜찮은지 확실히 알고 싶기 때문이라는 겁니다. 하지만 힙에 생성되었다고 하더라도 항상 100% 안전하게 delete를 할 수 있는 것은 아닙니다. 다음의 예를 보세요.
           
           class Asset {
           private:
           UPNumber value;
           ...
           };
           Asset *pa = new Asset;
           
           이 경우 pa->value는 힙에 생성된 것이 분명하지만, new를 통해 생성되지 않았기 때문에 delete를 하면 재앙이 온다는 사실도 확실합니다.
           
           다행스러운 사실은 어떤 포인터가 힙 주소를 가리키는지 알아내는 방법보다, 어떤 포인터가 삭제(delete)해도 괜찮은 포인터인지를 알아내는 것이 더 쉽다는 것입니다. operator new에서 지금 까지 할당된 주소들의 콜렉션을 유지하면 구현이 가능하기 때문입니다.
           
           바람직하지 않은 예제 코드 보기
           
           
           

           1. void *operator new(size_t size)
           2. {
           3. void *p = getMemory(size); // 메모리를 할당하고
           4. // 가용 메모리가 없는
           5. // 상황을 처리해 주는
           6. // 함수를 호출합니다.
           7. p를 할당된 주소 콜렉션에 추가합니다;
           8. return p;
           9. }
           10.  
           11. void operator delete(void *ptr)
           12. {
           13. releaseMemory(ptr); // 관리 장치에게
           14. // 현재의 메모리를 돌려 줍니다.
           15. 할당된 주소 콜렉션에서 ptr을 제거합니다;
           16. }
           17.  
           18. bool isSafeToDelete(const void *address)
           19. {
           20. address가 할당된 주소 콜렉션에 있는지 없는지의 여부를
           21. 반환합니다;
           22. }

           
           
           바람직하지 않은 예제 코드 접기
           
           
           하지만 이 방법에도 세 가지 문제점이 있습니다.
           
           첫째는, '전역 함수는 객체지향의 세계에선 아무래도 껄끄럽다'라는 것입니다. 특히 operator new와 operator delete는 미리 정의된 동작이 있기 때문에 더욱 그렇습니다. 앞에서와 같이 만들어진 소프트웨어는 operator new와 operator delete의 전역 함수를 구현한 또 다른 소프트웨어(많은 객체지향 데이터베이스 시스템)와 잘 작동하지 않게 됩니다.
           
           두 번째 걸림돌은 효율입니다. 힙 할당을 할 때마다 매번 할당된 주소의 정보를 갱신하고 유지해야 하는데, 이 오버헤드를 무시하지 못한다는 것은 분명한 부담이 됩니다.
           
           마지막 걸림돌은, 평범하지만 아주 중요한 문제입니다. isSafeToDelete 함수를 모든 경우에 대해 동작하도록 구현하기가 사실상 불가능하다는 것입니다. 왜냐하면, 다중 상속으로 만들어진 객체나 가상 기본 클래스로부터 만들어진 객체는 주소도 여러 개이기 때문에, isSafeToDelete로 넘어간 address 인자가 operator new로부터 반환된 것과 똑같으리라는 보장을 할 수 없기 때문입니다(항목 24와 31 참조).
        
        
        다행스럽게도 전역 네임스페이스, 효율 오버헤드, 부정확한 동작 등의 세 가지 걸림돌을 피하고 앞의 함수가 제공하는 기능을 그대로 쓸 수 있는 기법이 있습니다. 바로 '추상 믹스인 기본 클래스(abstract mixin base class)'라는 것입니다.
        
        추상 믹스인 기본 클래스 예제 코드 보기
        
        
        

        1. class HeapTracked { // 믹스인 클래스입니다. 이 클래스는
        2. public: // operator new에서 반환된 ptr을 관리합니다.
        4. class MissingAddress {}; // 예외 클래스입니다.
        6. virtual ~HeapTracked(void) = 0;
        8. static void *operator new(size_t size);
        9. static void operator delete(void *ptr);
        11. bool isOnHeap(void) const;
        13. private:
        14. typedef const void* RawAddress;
        15. static list<RawAddress> addresses;
        16. };
        17.  
        18. // 정적 클래스 멤버이기 때문에 반드시 정의해야 합니다.
        19. list<RawAddress> HeapTracked::addresses;
        20.  
        21. // HeapTracked의 소멸자는 순수 가상 함수로 선언하여 이 클래스를
        22. // 추상 클래스로 만듭니다. 하지만 이 클래스도 여전히 정의해야
        23. // 하기 때문에, 빈 블록이나마 만들었습니다.
        24. HeapTracked::~HeapTracked(void) {}
        25.  
        26. void * HeapTracked::operator new(size_t size)
        27. {
        28. void *memPtr = ::operator new(size); // 메모리를 얻어냅니다.
        30. address.push_front(memPtr); // 얻은 메모리 주소를
        31. // 리스트의 앞에 추가합니다.
        32. return memPtr;
        33. }
        34.  
        35. void HeapTracked::operator delete(void *ptr)
        36. {
        37. // ptr을 가지고 있는 리스트 엔트리를 가리키는 '반복자'를 얻어냅니다.
        38. list<RawAddress>::iterator it =
        39. find(addresses.begin(), addresses.end(), ptr);
        40. if (it != addresses.end()) { // 포인터가 발견되면
        41. addresses.erase(it); // 그 포인터를 제거합니다.
        42. ::operator delete(ptr); // 그리고 메모리를 해제합니다.
        43. }
        44. else { // 그렇지 않으면
        45. throw MissingAddress(); // ptr은 operator new에서
        46. } // 할당된 것이 아니므로,
        47. } // 예외를 일으킵니다.
        48.  
        49. bool HeapTracked::isOnHeap(void) const
        50. {
        51. // *this가 차지한 메모리의 첫 부분을 가리키는 포인터를
        52. // 얻어냅니다.
        53. const void *rawAddress = dynamic_cast<const void*>(this);
        55. // operator new에서 할당된 주소의 리스트에서 이 포인터를
        56. // 찾습니다.
        57. list<RawAddress>::iterator it =
        58. find(addresses.begin(), addresses.end(), rawAddress);
        60. return it != addresses.end(); // 포인터를 찾았는지 못 찾았는지의
        61. } // 여부를 반환합니다.
        62.  
        63. // 앞에서 isSafeToDelete는 만들기가 조금 복잡하다고
        64. // 했습니다. isOnHeap도 마찬가지의 문제를 가지고 있는데,
        65. // isOnHeap은 HeapTracked 객체에 대해서만 적용되기 때문에,
        66. // dynamic_cast 연산자의 힘을 빌어 이 문제점을 없애볼 수
        67. // 있습니다.
        68.  
        69. // dynamic_cast연산자를 적용할 수 있는 객체는
        70. // 가상 함수를 최소한 한 개 가져야 합니다.
        71. // 저주받은 isSafeToDelete 함수는 모든 타입의
        72. // 포인터에 대해 동작해야 했기 때문에, dynamic_cast로
        73. // 어떻게 해 볼 수가 없었죠.
        74.  
        75. // 하지만 isOnHeap은 HeapTracked 타입만 책임지면
        76. // 되므로 현재 객체가 자리잡은 메모리의 시작 주소를 얻을 수
        77. // 있는 것입니다.
        78.  
        79. // 위 클래스의 사용 방법은 아주 간단합니다. 다음을 보세요.
        80.  
        81. class Asset: public HeapTracked {
        82. private:
        83. UPNumber value;
        84. ...
        85. };
        86.  
        87. // 이제 Asset* 포인터가 힙 기반 객체를 가리키는지 알아보려면
        88. // 다음과 같이 합니다.
        89.  
        90. void inventoryAsset(const Asset *ap)
        91. {
        92. if (ap->isOnHeap()) {
        93. ap는 힙 기반 asset 객체입니다 - 그대로 저장해 둡니다.
        94. }
        95. else {
        96. ap는 힙 기반 객체가 아닙니다 - 다른 방법으로 기록합니다.
        97. }
        98. }

        
        
        추상 믹스인 기본 클래스 예제 코드 접기
        
        
        

      • 객체가 힙에 생성되지 않게 하기

        객체가 힙에 만들어지는 경우를 막는 방법은 아주 쉽습니다. 왜냐하면 힙 할당은 new를 통하지 않으면 이루어지지 않고, new의 사용을 막아버리기란 쉽기 때문입니다. 물론 new 연산자 자체를 어떻게 해 볼 수는 없지만 new 연산자가 내부적으로 operator new를 호출한다는 점과, 이 함수를 우리가 선언할 수 있다는 사실을 이용하면 됩니다. 바로 operator new를 private로 선언해 버리는 것입니다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. class UPNumber {
        3. private:
        4. static void *operator new(size_t size);
        5. static void operator delete(void *ptr);
        6. ...
        7. };
        8.  
        9. UPNumber n1; // 문제 없습니다.
        10. static UPNumber n2; // 또 문제 없습니다.
        11. UPNumber *p = new UPNumber; // 앗, 에러! private로 선언된
        12. // operator new의 호출을 시도했습니다.
        13.  
        14. // operator new와 operator delete를 찢어 놓을
        15. // 피치 못 할 이유가 없는 한 두 함수는 같은 성질로 선언하는 것이
        16. // 좋습니다. 또 하나, UPNumber 객체의 배열을 힙에
        17. // 만들지 못하게 하려면, operator new[]와
        18. // operator delete[]도 private로 선언해야 합니다.
        19.  
        20.  
        21. //-----------------------------------------------------------------------------
        22. // 이렇게 만들면, 파생 클래스 객체의 기본 클래스 부분으로
        23. // 객체가 인스턴스화되는 경우에도 힙에 생성되는 것을 막을 수 있습니다.
        24. // 왜냐하면 operator new와 operator delete는
        25. // 상속이 가능하기 때문에 기본 클래스에서 private였다면,
        26. // 파생 클래스 역시 이를 고스란히 물려받기 때문입니다.
        27.  
        28. class NonNegativeUPNumber: // 이 클래스에서는 operator new를
        29. public UPNumber { // 선언하지 않았다고 가정합니다.
        30. ...
        31. };
        32.  
        33. NonNegativeUPNumber n1; // 문제 없습니다.
        34.  
        35. static NonNegativeUPNumber n2; // 또 문제 없습니다.
        36.  
        37. NonNegativeUPNumber *p = // 앗, 에러! private로 선언된
        38. new NonNegativeUPNumber; // operator new의 호출을 시도했습니다.
        39.  
        40.  
        41. //-----------------------------------------------------------------------------
        42. // 파생 클래스가 자신만의 operator new를 또 선언하면,
        43. // 파생 클래스의 객체를 힙에 할당할 때 이 함수가
        44. // 호출된다는 사실에 주의해야 합니다.
        45.  
        46. // 비슷하게 UPNumber의 operator new가
        47. // private라고 해서 UPNumber 객체를 멤버로
        48. // 가지고 있는 다른 객체의 할당 방식까지 영향을 주는
        49. // 것은 아니라는 점도 유념해야 하겠습니다.
        50.  
        51. class Asset {
        52. public:
        53. Asset(int initValue);
        54. ...
        55. private:
        56. UPNumber value;
        57. };
        58.  
        59. Asset *pa = new Asset(100); // 별 문제없습니다.
        60. // Asset::operator new 혹은
        61. // ::operator new가 호출되지,
        62. // UPNumber::operator new는 아닙니다.
        63.  
        64.  
        65. //-----------------------------------------------------------------------------
        66. // 객체가 힙에 생성되지 못하게 하는 방법을 알았으니,
        67. // 객체가 힙에 있을 때 예외를 일으키는 방법을 찾고
        68. // 싶은 것이 인지상정입니다.
        69.  
        70. // 하지만 어떤 주소가 힙 영역에 있는지를 알아낼 수
        71. // 있고 이식성까지 갖춘 방법을 찾을 수 없었던 것과
        72. // 마찬가지로, 어떤 주소가 힙 영역에 없는지를 알아내는
        73. // 이식성 있는 방법은 없습니다.

        
        
        예제 코드 접기
        
        
        

  28. 스마트 포인터(Smart Pointer) / 229

      • 스마트 포인터는 C++언어에서 사용되는 보통의 포인터처럼 생겼고, 보통의 포인터처럼 동작하고, 보통의 포인터처럼 느껴지지만, 실상은 엄청난 기능을 제공하도록 설계된 C++ 객체입니다.

        C++의 기본 제공(built-in) 포인터(시쳇말로 벙어리(dumb) 포인터) 대신에 스마트 포인터를 사용하는 이유는 다음의 세 가지로 요악할 수 있습니다.
        1. 생성(construction)과 소멸(destruction) 작업을 조절할 수 있습니다.
           스마트 포인터가 생성되고 소멸되는 시기를 조절할 수 있고, 생성될 때 기본값으로 0(널)을 가지기 때문에 쓰레기 값으로 인한 문제를 해결할 수 있으며, 어떤 객체를 가리키고 있는 최후의 스마트 포인터가 소멸될 때 자동으로 그 객체를 삭제하는 기능도 가지고 있습니다.
        2. 복사(copy)와 대입(assignment) 동작을 조절할 수 있습니다.
           스마트 포인터가 복사되거나 대입될 때 일어나는 일을 여러분이 결정할 수 있습니다. 어떤 경우에는 깊은 복사(대입)를 할 수도 있고, 어떤 경우에는 얕은 복사(대입)를 할 수도 있으며, 어떤 경우에는 복사(대입)을 금지할 수도 있습니다.
        3. 역참조(dereferencing) 동작을 조절할 수 있습니다.
           사용자가 스마트 포인터가 가리키는 객체를 가져오려고 할때의 동작도 여러분이 결정할 수 있습니다. 항목 17에서 이야기한 지연방식의 데이터/명령어 가져오기(fetching)를 구현하는데 스마트 포인터를 사용할 수 있습니다.
        
        스마트 포인터는 엄격한 타입 제약을 위해 템플릿으로 만들어집니다. 다음 예제에서 스마트 포인터가 생긴 모습을 대략적으로 볼 수 있습니다.
        
        스마트 포인터 예제 코드 보기
        
        
        

        1. template <class T> // 스마트 포인터 객체의
        2. class SmartPtr { // 템플릿
        3. public:
        4. SmartPtr(T* realPtr = 0); // 스마트 포인터를 생성하는데,
        5. // 벙어리 포인터가 가리키는 객체를
        6. // 가리키도록 초기화됩니다.
        7. // 값이 주어지지 않으면 0(널)입니다.
        8.  
        9. SmartPtr(const SmartPtr& rhs); // 스마트 포인터를 복사합니다.
        10.  
        11. ~SmartPtr(void); // 스마트 포인터를 소멸시킵니다.
        13. // 스마트 포인터에 대입 연산을 수행합니다.
        14. SmartPtr& operator=(const SmartPtr& rhs);
        16. T* operator->(void) const; // 스마트 포인터를 역참조하여
        17. // 스마트 포인터가 가리키는
        18. // 멤버에 접근합니다.
        20. T& operator*(void) const; // 스마트 포인터를 역참조합니다.
        22. private:
        23. T *pointee; // 스마트 포인터가 가리키는
        24. }; // 실제 객체의 주소
        25.  
        26. // 스마트 포인터의 복사를 허용하지 않으려면,
        27. // 복사 생성자와 대입 연산자를 모두 private로
        28. // 선언해야 할 것입니다.
        29.  
        30. // 역참조 연산자가 모두 const로 선언되어
        31. // 있는 것은 포인터를 역참조 한다고 해서
        32. // 스마트 포인터의 내부 데이터가 바뀌진
        33. // 않기 때문입니다.

        
        
        스마트 포인터 예제 코드 접기
        
        
        스마트 포인터의 사용 예를 하나 봅시다. 객체들이 여러 컴퓨터에 흩어져 있는 분산 시스템이 있다고 가정합시다. 어플리케이션 코드를 작성하는 사용자의 입장에서는 로컬 객체와 원격 객체의 처리방법이 달라야 한다는 점이 마음에 들 리가 없습니다. 실제로는 그렇지 않더라도 모든 객체는 같은 장소에 있는 것처럼 보이는 것이 편리합니다. 이렇게 하는데 스마트 포인터를 쓸 수 있습니다.
        
        스마트 포인터 사용 예제 코드 보기
        
        
        

        1. template <class T> // 분산 데이터베이스에
        2. class DBPtr { // 저장되는 객체를 나타내는
        3. public: // 스마트 포인터의 템플릿
        4.  
        5. DBPtr(T *realPtr = 0); // 벙어리 포인터가 가리키는
        6. // DB 객체를 가리키도록
        7. // 스마트 포인터를 생성합니다.
        9. DBPtr(DataBaseID id); // 스마트 포인터를 생성하되,
        10. // DB 객체에 대한 유일 식별자
        11. // 를 생성자 인자로 넘깁니다.
        13. ... // 스마트 포인터의 다른 기능은
        14. }; // 이전과 똑같습니다.
        15.  
        16. class Tuple { // 데이터베이스 튜플(Tuple)을
        17. public: // 나타내는 클래스
        18. ...
        19. void displayEditDialog(void); // 사용자가 튜플을 편집할 수
        20. // 있게 하는 그래픽 대화상자를
        21. // 띄웁니다.
        23. bool isValid(void) const; // *this가 유효성 점검을
        24. }; // 통과했는지 못 했는지를 반환합니다.
        25.  
        26. // T 객체의 내용이 바뀔 때마다 로깅되는 내용인 로그 엔트리의
        27. // 클래스 템플릿
        28. template <class T>
        29. class LogEntry {
        30. public:
        31. LogEntry(const T& objectToBeModified);
        32. ~LogEntry(void);
        33. };
        34.  
        35. void editTuple(DBPtr<Tuple>& pt)
        36. {
        37. LogEntry<Tuple> entry(*pt); // 튜플 편집을 가리키는 로그
        38. // 엔트리를 생성합니다. 자세한
        39. // 내용은 다음에서 확인하세요.
        40. // 유효한 값이 주어질 때까지 편집 대화상자를
        41. // 반복적으로 표시합니다.
        42. do {
        43. pt->displayEditDialog();
        44. } while(pt->isValid() == false);
        45. }
        46.  
        47. // editTuple 함수 안에서 편집되는 튜플은
        48. // 물리적으로는 원격 컴퓨터에 들어 있을 수
        49. // 있습니다. 하지만, 시스템의 내부 특징은
        50. // 스마트 포인터 클래스가 모두 감추어 주므로
        51. // editTuple을 작성하는 프로그래머는 그런
        52. // 문제까지 신경쓸 필요가 없습니다.
        53.  
        54. // editTuple 함수에서 LogEntry가 사용되는
        55. // 부분을 잘 보면, displayEditDialog를
        56. // 호출하는 부분의 앞에서 로그 엔트리를 시작하고,
        57. // displayEditDialog의 호출이 끝날 때
        58. // 로그 엔트리를 끝내는 것이 편리할 것 같은데,
        59. // 바로 그렇게 만들어진 코드입니다.
        60.  
        61. // LogEntry의 생성자가 로그 엔트리를 시작하고
        62. // 소멸자가 로그 엔트리를 끝내고 있죠.

        
        
        스마트 포인터 사용 예제 코드 접기
        
        
        

      • 스마트 포인터의 생성, 대입, 소멸

        스마트 포인터를 생성하는 방법은 사실 아무 것도 아닙니다. 가리킬 객체를 하나 준비하고, 스마트 포인터의 내부에 있는 벙어리 포인터를 그 객체의 주소로 세팅하면 됩니다. 가리킬 객체가 없으면 내부 포인터를 0(널)으로 놓든가 에러를 알립니다(예외를 일으킨다든지...).
        
        스마트 포인터의 복사 생성자, 대입 연산자(여러 버전), 그리고 소멸자를 구현하는 방법은 소유권(ownership)이라는 것 때문에 꽤 복잡합니다. 스마트 포인터가 자신이 가리키는 객체(동적으로 할당되었다고 가정)를 가지고 있는 경우에는 스마트 포인터가 소멸될 때 이 객체도 삭제해야 합니다. 표준 C++라이브러리에 들어 있는 auto_ptr 템플릿을 예로 들어 봅시다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // auto_ptr 객체는 소멸될 때 소멸자가 호출되면서
        3. // 자신이 가리키는 객체를 삭제합니다.
        4.  
        5. // 이 auto_ptr 템플릿의 내부는 다음과 같이
        6. // 생겼을 것입니다.
        7. template <class T>
        8. class auto_ptr {
        9. public:
        10. auto_ptr(T *ptr = 0): pointee(ptr) {}
        11. ~auto_ptr(void) { delete pointee; }
        12. ...
        13. private:
        14. T *pointee;
        15. };
        16.  
        17.  
        18. //-----------------------------------------------------------------------------
        19. // 사실 한 개의 auto_ptr이 한 개의 객체를
        20. // 맡고 있으면 이 동작은 별 문제가 없습니다.
        21.  
        22. // 그러나 auto_ptr이 복사되거나 대입될 때는
        23. // 어떻게 되어야 할까요?
        24.  
        25. auto_ptr<TreeNode> ptn1(new TreeNode);
        26.  
        27. auto_ptr<TreeNode> ptn2 = ptn1; // 복사 생성자를 호출합니다.
        28. // 어떻게 되어야 할까요?
        29. auto_ptr<TreeNode> ptn3;
        30. ptn3 = ptn2; // operator=를 호출합니다.
        31. // 어떻게 되어야 할까요?
        32.  
        33. // 내부의 벙어리 포인터를 단순히 복사해 버리면,
        34. // 결국 두 개의 auto_ptr이 같은 객체를
        35. // 가리키게 됩니다.
        36.  
        37. // 이렇게 되면 첫 번째 auto_ptr이
        38. // 소멸되면서 객체를 삭제하고, 두 번째
        39. // auto_ptr이 소멸되면서 같은 객체를
        40. // 한 번 더 삭제하여 예측할 수 없는
        41. // 결과를 낳습니다.
        42.  
        43. // 이를 해결하기 위해 깊은 복사를 하는 방법이
        44. // 있지만, 이 방법은 객체를 생성하고 소멸하는
        45. // 데에 있어 납득하기 힘든 수행 성능의 저하를
        46. // 불러올 수 있습니다.
        47.  
        48. // 게다가 스마트 포인터를 생성할 때 객체의
        49. // 타입을 꼭 알아야할 필요는 없습니다.
        50.  
        51. // auto_ptr<T>는 T 타입의 객체를 가리키지
        52. // 않아도 되기 때문입니다. 실상은 T에서 파생된
        53. // 객체를 가리켜도 의미구조에 문제가 없다는
        54. // 것입니다.
        55.  
        56. // 다른 쓸만한 방법으로는 auto_ptr에서는
        57. // 복사나 대입을 못하게 하여 문제를 해결하는
        58. // 방법이 있습니다.
        59.  
        60.  
        61. //-----------------------------------------------------------------------------
        62. // 하지만 auto_ptr에서는 더 괜찮은
        63. // 해결책이 사용되었습니다. 바로 auto_ptr이
        64. // 복사 혹은 대입될 때 소유 관계를 옮기는 것입니다.
        65. template <class T>
        66. class auto_ptr {
        67. public:
        68. ...
        69. auto_ptr(auto_ptr<T>& rhs); // 복사 생성자
        71. auto_ptr<T>& // auto_ptr용
        72. operator=(auto_ptr<T> &rhs); // 대입 연산자
        73. ...
        74. };
        75.  
        76. template <class T>
        77. auto_ptr<T>::auto_ptr(auto_ptr<T>& rhs)
        78. {
        79. pointee = rhs.pointee; // *pointee의 소유권을
        80. // rhs에서 *this로 옮깁니다.
        81.  
        82. rhs.pointee = 0; // rhs는 이제 그 객체를
        83. } // 갖지 않습니다.
        84.  
        85. template <class T>
        86. auto_ptr<T>& auto_ptr<T>::operator=(auto_ptr<T>& rhs)
        87. {
        88. if (this == &rhs) // 자기 자신에게 대입되는
        89. return *this; // 경우에는 아무 일도
        90. // 하지 않습니다.
        92. delete pointee; // 현재 자신이 가지고 있는
        93. // 객체를 삭제합니다.
        95. pointee = rhs.pointee; // *pointee의 소유권을
        96. rhs.pointee = 0; // rhs에서 *this로 옮깁니다.
        98. return *this;
        99. }
        100.  
        101. // 복사 생성자와 대입 연산자의 인자로
        102. // 상수 객체를 받지 않는 이유는
        103. // auto_ptr의 복사 생성자나
        104. // 대입 연산자의 우변이 될 때는
        105. // 내부의 데이터가 바뀌기 때문입니다
        106. // (널값으로 변경됨).
        107.  
        108.  
        109. //-----------------------------------------------------------------------------
        110. // 복사 생성자도 객체 소유권을 옮기는 방법으로
        111. // 구현했기 때문에, auto_ptr을 함수의
        112. // 매개변수로서 값으로 넘기면 진짜로 안 됩니다.
        113.  
        114. // 재앙을 부르는 함수
        115. void printTreeNode(ostream& s, auto_ptr<TreeNode> p)
        116. { s << *p; }
        117.  
        118. int main(void)
        119. {
        120. auto_ptr<TreeNode> ptn(new TreeNode);
        121. ...
        122. printTreeNode(cout, ptn); // auto_ptr를 값으로 전달합니다.
        124. ... // 이 부분에서 ptn이 가리키던
        125. // 객체는 이미 소멸되었습니다.
        126. }
        127.  
        128. // auto_ptr을 함수의 매개변수로 넘겨야 한다면,
        129. // 값으로 넘기지 말고 상수 객체 참조자에 의한 전달
        130. // (Pass-by-reference-to-const)
        131. // 방식으로 넘겨야 합니다.
        132.  
        133. // 정상적으로 동작하는 함수
        134. void printTreeNode(ostream& s,
        135. const auto_ptr<TreeNode>& p)
        136. { s << *p; }

        
        
        예제 코드 접기
        
        
        auto_ptr에 대해 흥미가 있어서 완전한 구현 코드를 보고 싶으신 분들도 있을텐데, 이런 분들을 위해 "auto_ptr의 상세 구현 코드"를 따로 준비해 놓았습니다. 표준 C++ 라이브러리에 들어 있는 auto_ptr 템플릿이 여기서 설명한 것보다, 훨씬 유연하게 만들어진 복사 생성자와 대입 연산자를 가지고 있다는 사실을 확인하실 수 있을 것입니다. 사실 이 함수들은 그냥 멤버 함수가 아니라 멤버 함수 템플릿으로 만들어져 있습니다.
        
        auto_ptr 클래스 템플릿의 구현 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 여기에 실은 auto_ptr은 공식 발표 버전의
        3. // 내용 중 몇 가지를 가지고 있지 않습니다.
        4.  
        5. // 예를 들면, auto_ptr은 std 네임스페이스에
        6. // 들어 있다는 사실이나 auto_ptr의 멤버 함수는
        7. // 예외를 발생시키지 않게 되어 있다는 사실 등 입니다.
        8.  
        9.  
        10. //-----------------------------------------------------------------------------
        11. // 첫째 것은 클래스 인터페이스에 주석문을 붙이고
        12. // 멤버 함수를 클래스 선언문의 바깥쪽에서 모두
        13. // 구현한 것입니다.
        14.  
        15. template <class T>
        16. class auto_ptr {
        17. public:
        18. explicit auto_ptr(T *p = 0); // "explicit"에 대한 설명은
        19. // 항목 5에서 찾을 수 있습니다.
        21. template <class U> // 복사 생성자용 멤버 템플릿
        22. auto_ptr(auto_ptr<U>& rhs); // (항목 28을 참고하세요).
        23. // 새로 생성되는 auto_ptr을 다른
        24. // auto_ptr(물론 U가 같아야 함)을
        25. // 써서 초기화합니다.
        27. ~auto_ptr(void);
        29. template <class U> // 대입 연산자용 멤버 템플릿
        30. auto_ptr<T>& // (항목 28을 보세요).
        31. operator=(auto_ptr<U>& rhs); // 다른 auto_ptr을 이 auto_ptr에
        32. // 대입합니다.
        34. T& operator*(void) const; // 항목 28을 참고하세요.
        35. T* operator->(void) const; // 항목 28을 참고하세요.
        37. T* get(void) const; // 현재의 벙어리 포인터를
        38. // 반환합니다.
        40. T* release(void); // 현재의 벙어리 포인터에 대한
        41. // 소유권을 박탈하고 그 포인터값을
        42. // 반환합니다.
        44. void reset(T *p = 0); // 가지고 있는 포인터를 삭제합니다
        45. // (p의 소유권을 가지고 있다는 가정 하에).
        46. private:
        47. T *pointee;
        49. template <class U> // auto_ptr 클래스끼리 서로의
        50. friend class auto_ptr<U>; // 프렌드가 되도록 합니다.
        51. };
        52.  
        53. template <class T>
        54. inline auto_ptr<T>::auto_ptr(T *p)
        55. : pointee(p);
        56. {}
        57.  
        58. template <class T>
        59. template <class U>
        60. inline auto_ptr<T>::auto_ptr(auto_ptr<U>& rhs)
        61. : pointee(rhs.release())
        62. {}
        63.  
        64. template <class T>
        65. inline auto_ptr<T>::~auto_ptr(void)
        66. { delete pointee; }
        67.  
        68. template <class T>
        69. template <class U>
        70. inline auto_ptr<T>& auto_ptr<T>::operator=(auto_ptr<U>& rhs)
        71. {
        72. if (this != &rhs) reset(rhs.release());
        73. return *this;
        74. }
        75.  
        76. template <class T>
        77. inline T& auto_ptr<T>::operator*(void) const
        78. { return *pointee; }
        79.  
        80. template <class T>
        81. inline T* auto_ptr<T>::operator->(void) const
        82. { return pointee; }
        83.  
        84. template <class T>
        85. inline T* auto_ptr<T>::get(void) const
        86. { return pointee; }
        87.  
        88. template <class T>
        89. inline T* auto_ptr<T>::release(void)
        90. {
        91. T *oldPointee = pointee;
        92. pointee = 0;
        93. return oldPointee;
        94. }
        95.  
        96. template <class T>
        97. inline void auto_ptr<T>::reset(T *p)
        98. {
        99. if (pointee != p) {
        100. delete pointee;
        101. pointee = p;
        102. }
        103. }
        104.  
        105.  
        106. //-----------------------------------------------------------------------------
        107. // 둘째 것은 클래스 선언과 멤버 함수 구현을
        108. // 동시에 한 것입니다. 원칙적인 스타일로 보면
        109. // 둘째 것이 뒤쳐집니다.
        110.  
        111. // 하지만 auto_ptr은 간단한 클래스이기 때문에,
        112. // 전체적으로 보면 첫째 것보다 둘째 것이 깔끔합니다.
        113. template <class T>
        114. class auto_ptr {
        115. public:
        116. explicit auto_ptr(T *p = 0): pointee(p) {}
        118. template <class U>
        119. auto_ptr(auto_ptr<U>& rhs): pointee(rhs.release()) {}
        121. ~auto_ptr(void) { delete pointee; }
        123. template <class U>
        124. auto_ptr<T>& operator=(auto_ptr<U>& rhs)
        125. {
        126. if (this != &rhs) reset(rhs.release());
        127. return *this;
        128. }
        130. T& operator*(void) const { return *pointee; }
        132. T* operator->(void) const { return pointee; }
        134. T* get(void) const { return pointee; }
        136. T* release(void)
        137. {
        138. T *oldPointee = pointee;
        139. pointee = 0;
        140. return oldPointee;
        141. }
        143. void reset(T *p = 0)
        144. {
        145. if (pointee != p) {
        146. delete pointee;
        147. pointee = p;
        148. }
        149. }
        151. private:
        152. T *pointee;
        154. template <class U> friend class auto_ptr<U>;
        155. };

        
        
        auto_ptr 클래스 템플릿의 구현 접기
        
        
        

      • 역참조(Dereferencing) 연산자 구현하기

        역참조 연산자란 operator*와 operator-> 함수를 말합니다. 우선 operator*부터 알아보죠. 이 함수는 스마트 포인터가 가리키는 객체를 반환하는데, 개념적으로는 지극히 단순합니다.
        
        operator* 예제 코드 보기
        
        
        

        1. template <class T>
        2. T& SmartPtr<T>::operator*(void) const
        3. {
        4. "스마트 포인터" 처리를 수행합니다;
        6. return *pointee;
        7. }
        8.  
        9. // 먼저 이 함수는 pointee를 초기화하든지
        10. // pointee를 유효하게 하는 일을 닥치는 대로
        11. // 합니다.
        12.  
        13. // 이를테면, 지연 방식의 가져오기(항목 17 참조)가
        14. // 사용되는 상태에서는 pointee가 가리키는
        15. // 객체를 불러와야 하겠습니다.
        16.  
        17. // 어쨌든 일단 pointee가 유효하다고 판정되면,
        18. // operator* 함수는 스마트 포인터가
        19. // 가리키는 객체의 참조자를 반환합니다.
        20.  
        21. // 여기서 반환 타입이 참조자라는 점이 중요합니다.
        22.  
        23. // 절대로 operator*의 반환 타입을
        24. // 참조자가 아닌 값으로 해서는 안됩니다.
        25.  
        26. // 왜냐하면 스마트 포인터가 가리키는 객체는
        27. // T가 아니라 T에서 파생된 객체일 수도
        28. // 있기 때문이죠. 이런 경우 바로 슬라이스
        29. // 문제가 발생합니다(항목 13 참조).
        30.  
        31. // 거기에다 추가로 값을 반환하는것 보다
        32. // 참조자를 반환하는 것이 훨씬 효율적입니다.
        33. // 임시 객체를 만들지 않기 때문입니다
        34. // (항목 19 참조).
        35.  
        36. // 만일 널(null)값을 가진 스마트 포인터에
        37. // 대해 operator*를 호출하는 상황이라면
        38. // 주저하지 말고 원하는 대로 오류 처리를 하면 됩니다.
        39. // 예외를 던질 수도 있고, abort를 호출할 수도
        40. // 있습니다.

        
        
        operator* 예제 코드 접기
        
        
        operator->의 동작도 operator*의 동작과 별반 다르지 않습니다(참조자 대신 포인터를 반환하는것 외엔 똑같습니다).
        
        operator-> 예제 코드 보기
        
        
        

        1. // operator->에 대한 이야기를 하기 전에
        2. // 이 함수의 호출에 관련된 이상한 의미를 함께
        3. // 고민해 볼 필요가 있습니다.
        4.  
        5. // 앞의 예제에서 등장했던 editTuple 함수를
        6. // 다시 가지고 왔습니다.
        7.  
        8. void editTuple(DBPtr<Tuple>& pt)
        9. {
        10. LogEntry<Tuple> entry(*pt);
        11. do {
        12. pt->displayEditDialog();
        13. } while (pt->isValid() == false);
        14. }
        15.  
        16. // 여기서 이 문장은,
        17.  
        18. pt->displayEditDialog();
        19.  
        20. //컴파일러에 의해 다음과 같이 해석됩니다.
        21.  
        22. (pt.operator->())->displayEditDialog();
        23.  
        24. // 앞 문장은 operator->가 반환하는 것이
        25. // 무엇이든 간에, 멤버 지정 연산자(->)를 그것에
        26. // 대해 적용해도 상관 없어야 한다는 뜻을 담고
        27. // 있습니다.
        28.  
        29. // operator->가 반환할 수 있는 것은 오로지
        30. // 벙어리 포인터 아니면, 스마트 포인터 객체
        31. // 중 하나입니다.
        32.  
        33. // 보통의 경우 벙어리 포인터를 반환하는 경우가
        34. // 대부분일 것입니다.
        35.  
        36. template <class T>
        37. T* SmartPtr<T>::operator->(void) const
        38. {
        39. "스마트 포인터" 처리를 수행합니다;
        40. return pointee;
        41. }

        
        
        operator-> 예제 코드 접기
        
        
        

      • 스마트 포인터가 널(null)인지 점검하기

        지금까지 알아본 것만 잘 잊지 않으면, 스마트 포인터의 기본적인 사용은 가능합니다. 그러나 아직 가능하지 않은 것 중 하나가 '스마트 포인터가 널인지 확인하는 방법'입니다.
        
        SmartPtr<TreeNode> ptn;
        ...
        // 다음의 세 if 문은 모두 오류입니다.
        if (ptn == 0) ...
        if (ptn) ...
        if (!ptn) ...
        
        
        스마트 포인터를 가지고 앞에서와 같은 코딩을 할 수 없다는 것은 심각한 한계입니다. 얕은 생각으로는 isNull 같은 멤버 함수를 추가하면 간단히 해결될 것 같지만, 그렇게 했다간 스마트 포인터가 벙어리 포인터와 똑같이 동작할 수 없다는 문제가 그대로 남게 되므로 별로 좋지 않습니다.
        
        적합한 방법은 앞의 코드가 그대로 컴파일되도록 암시적 타입변환 연산자를 넣어주는 것입니다. 이런 목적으로 타입변환을 할 때에는 대개 void*로 바꿉니다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. template <class T>
        3. class SmartPtr {
        4. public:
        5. ...
        6. operator void*(void); // 스마트 포인터가 널이면
        7. ... // 0을 반환하고, 아니면 0이
        8. }; // 아닌 값을 반환합니다.
        9.  
        10. SmartPtr<TreeNode> ptn;
        11. ...
        12. // 이제는 다음 세 if문이 모두 컴파일됩니다.
        13. if (ptn == 0) ...
        14. if (ptn) ...
        15. if (!ptn) ...
        16.  
        17. // 다른 타입 변환 함수들이 그러하듯이
        18. // 이 방법도 단점을 안고 있습니다.
        19.  
        20. // 바로 대부분의 프로그래머가 실패할 것
        21. // 같다고 생각하는 함수 호출을 실패시키지
        22. // 않는다는 것입니다(항목 5 참조).
        23.  
        24. SmartPtr<Apple> pa;
        25. SmartPtr<Orange> po;
        26. ...
        27. if (pa == po) ... // 이게 컴파일된다니까요!
        28.  
        29.  
        30. //-----------------------------------------------------------------------------
        31. // 'void*로 변환하기' 방법을 응용한 것들도 꽤 있습니다.
        32.  
        33. // 어떤 쪽에서는 const void*로 바꾸는 것이 옹호되는 반면,
        34. // 또 다른 쪽에서는 bool로 바꿔야 한다고 주장합니다.
        35.  
        36. // 하지만 어떤 방법을 쓰더라도 다른 타입끼리의 비교가
        37. // 허용되는 문제는 없앨 수 없습니다.
        38.  
        39. // 완전하지는 않지만, 다른 타입의 스마트 포인터를
        40. // 비교하는 경우를 최소화하면서 스마트 포인터가
        41. // 널인지 확인하는 괜찮은 방법이 있습니다.
        42.  
        43. // operator! 연산자를 오버로딩해서,
        44. // 이 연산자가 호출된 스마트 포인터가 널일 때에만
        45. // true를 반환하도록 하는 것입니다.
        46.  
        47. template <class T>
        48. class SmartPtr {
        49. public:
        50. ...
        51. bool operator!(void) const;
        52. ...
        53. };
        54.  
        55. SmartPtr<TreeNode> ptn;
        56. ...
        57. if (!ptn) { // 문제없습니다.
        58. ... // ptn이 널입니다.
        59. }
        60. else {
        61. ... // ptn이 널이 아닙니다.
        62. }
        63.  
        64. // 다음의 코드는 컴파일되지 않습니다.
        65. if (ptn == 0) ... // 여전히 에러입니다.
        66. if (ptn) ... // 아.. 에러라니까요.
        67.  
        68. // 전혀 다른 타입의 스마트 포인터를 비교할 때에는
        69. // 오로지 다음의 경우만 조심하면 됩니다.
        70. SmartPtr<Apple> pa;
        71. SmartPtr<Orange> po;
        72. ...
        73. if (!pa == !po) ... // 안타깝지만, 컴파일됩니다.
        74.  
        75. // 단 이렇게 코딩하는 경우는 상당히 드물기 때문에,
        76. // 크게 문제가 되지는 않습니다.

        
        
        예제 코드 접기
        
        
        

      • 스마트 포인터를 벙어리 포인터로 변환하기

        스마트 포인터를 사용하더라도 여전히 벙어리 포인터가 필요한 경우가 있습니다. 대표적인 예로 스마트 포인터를 사용하지 않고 설계된 라이브러리를 사용해야 할 때입니다. 이런 경우에도 스마트 포인터를 사용하기 위해서, 스마트 포인터가 가리키고 있는 객체의 벙어리 포인터를 얻는 방법이 필요합니다.
        
        이것을 해결하는 끔찍한 방법 중의 하나는, 스마트 포인터 객체를 벙어리 포인터 타입으로 변환하는 암시적 타입 변환 연산자를 추가하는 것입니다. 암시적 변환을 허용하게 되면, 스마트 포인터가 마치 벙어리 포인터인 것 마냥 쓸 수 있게 되고, 스마트 포인터의 널 점검에 대한 고민도 날아갑니다. 하지만 이 방법은 중대한 단점을 여럿 가지고 있습니다.
        
        암시적 타입 변환의 문제 예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 스마트 포인터를 벙어리 포인터로
        3. // 암시적 타입 변환 연산자를
        4. // 추가한 경우에 스마트 포인터가
        5. // 주려고 했던 혜택을
        6. // 받지 못할 수 있습니다.
        7.  
        8. void processTuple(DBPtr<Tuple>& pt)
        9. {
        10. Tuple *rawTuplePtr = pt; // DBPtr<Tuple> 타입을
        11. // Tuple*로 변환합니다.
        12. rawTuplePtr을 써서 튜플 데이터를 바꿉니다;
        13. }
        14.  
        15. // 만일 DBPtr에 참조 카운팅 기능이
        16. // 들어 있다면 rawTuplePtr이
        17. // 참조 카운팅에 필요한 내부 정보를
        18. // 조정하지 않아 문제가 발생할 수 있습니다.
        19.  
        20.  
        21. //-----------------------------------------------------------------------------
        22. // 위와 같은 경우까지 고려해서 암시적
        23. // 타입 변환 연산자를 만들었다고 해도,
        24. // 스마트 포인터는 벙어리 포인터가 있던
        25. // 자리를 전부 대신할 수는 없는 존재입니다.
        26.  
        27. // 예를 봅시다.
        28.  
        29. class TupleAccessors {
        30. public:
        31. TupleAccessors(const Tuple *pt); // pt는 사용자들이
        32. ... // 액세스하고 있는
        33. }; // 튜플을 가리킵니다.
        34.  
        35. TupleAccessors merge(const TupleAccessors& ta1,
        36. const TupleAccessors& ta2);
        37.  
        38. Tuple *pt1, *pt2;
        39. ...
        40. merge(pt1, pt2); // 문제 없습니다. 두 포인터가
        41. // TupleAccessors로 바뀌니까요.
        42.  
        43. DBPtr<Tuple> pt1, pt2;
        44. ...
        45. merge(pt1, pt2); // 에러입니다! pt1과 pt2를
        46. // TupleAccessors로 바꿀 방법이 없습니다.
        47.  
        48. // 왜 그럴까요?
        49.  
        50. // DBPtr<Tuple>을 TupleAccessors으로 바꾸려면
        51. // DBPtr<Tuple>을 Tuple*로 바꾸는 함수와
        52. // Tuple*을 TupleAccessors로 바꾸는 함수
        53. // 두 개가 필요한데, 이런 일(두 개 이상의
        54. // 사용자 정의 타입변환 함수를 암시적으로
        55. // 호출하는 일)은 C++에서 금지되어 있기 때문입니다.
        56.  
        57.  
        58. //-----------------------------------------------------------------------------
        59. // 암시적 타입 변환 연산자를 사용하는 스마트 포인터는
        60. // 어떤 지저분한 버그에 대해서도 아무 생각 없이
        61. // 문을 열어 놓습니다.
        62.  
        63. // 다음의 예를 보세요.
        64.  
        65. DBPtr<Tuple> pt = new Tuple;
        66. ...
        67. delete pt;
        68.  
        69. // 이 코드는 컴파일되어선 안됩니다.
        70. // 그도 그럴게 pt는 포인터가 아니라 객체니까요.
        71.  
        72. // 하지만 DBPtr에 암시적 타입변환 연산자가
        73. // 있다면, 컴파일러는 스마트 포인터 pt를
        74. // pt가 가리키고 있는 객체의 벙어리 포인터
        75. // (Tuple* 타입)로 변환하여 기어코
        76. // 삭제해버리고 맙니다.
        77.  
        78. // 당연히 pt의 소멸자가 한 번 더 삭제를
        79. // 시도할테니 프로그램은 온전히 작동되지
        80. // 않을 것입니다.

        
        
        암시적 타입 변환의 문제 예제 코드 접기
        
        
        이것만은 꼭 지킵시다. 꼭 그렇게 해야 하는 이유가 없으면, 스마트 포인터를 벙어리 포인터로 바꾸는 암시적 타입변환 연산자는 제공하지 말자는 원칙 말입니다.

      • 스마트 포인터와 상속 기반의 타입변환

        클래스 A와 A를 상속받아 구현한 클래스 B가 있다고 합시다. 벙어리 포인터의 경우 A 타입의 포인터가 B 타입의 객체를 가리킬 수 있는 것은 너무나 당연한 일입니다. 하지만 스마트 포인터의 경우는 좀 다릅니다. 상속 관게에 있는 것은 스마트 포인터가 가리키고 있는 객체의 클래스이지 스마트 포인터는 아니기 때문에, A 타입의 포인터를 가리키는 스마트 포인터가 B 타입의 객체를 가리킬 수 없습니다.
        
        이 문제를 해결하기 위해서 (비가상) 멤버 함수 템플릿(보통, 멤버 템플릿이라고 부릅니다)을 선언해 주는 방법을 사용할 수 있습니다. 다만 이 방법의 동작 원리를 제대로 이해하기 힘들다는 단점이 있습니다.
        
        명심해야 할 점은 스마트 포인터는 '스마트'하지만 진짜 벙어리 포인터가 될 수는 없다는 것입니다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. template <class T> // T 객체에 대한 스마트 포인터
        3. class SmartPtr { // 템플릿 클래스
        4. public:
        5. SmartPtr(T* realPtr = 0);
        7. T* operator->(void) const;
        8. T& operator*(void) const;
        10. template <class newType> // 암시적 변환 연산자를 위한
        11. operator SmartPtr<newType>(void) // 템플릿 함수
        12. {
        13. return SmartPtr<newType>(pointee);
        14. }
        15. ...
        16. };
        17.  
        18. // 이 객체를 T의 기본 클래스에 대한 포인터로
        19. // 변환해야 하는 상황이라고 가정합시다.
        20.  
        21. // 우선 컴파일러는 SmartPtr<T>의 클래스
        22. // 정의를 살펴서 필요한 변환 연산자가
        23. // 선언되어 있는지를 확인하는데, 보시다시피
        24. // 선언이 안 되어 있지요.
        25.  
        26. // 이번엔 컴파일러는 그 시점에 필요한 타입변환을
        27. // 해 주는 멤버 함수 템플릿이 들어 있는지
        28. // 점검합니다.
        29.  
        30. // 이윽고 요구에 맞는 멤버 함수 템플릿
        31. // (형식 타입 매개변수 newType을 취하는)
        32. // 을 찾게 되고, 변환하고자 하는 타입 T의
        33. // 기본 클래스에 바인딩된 newType 매개변수를
        34. // 써서 함수 템플릿을 함수로 인스턴스화 합니다.
        35.  
        36. // 생성자에서 벙어리 포인터 타입 T*를
        37. // 매개변수로 받기 때문에 newType이
        38. // T의 기본 클래스 타입이라면 오류 없이
        39. // 컴파일 될 것입니다.
        40.  
        41. // 다음 예시를 보세요.
        42.  
        43. class MusicProduct { ... };
        44. class Cassette : public MusicProduct { ... };
        45.  
        46. void displayAndPlay(const SmartPtr<MusicProduct>& pmp,
        47. int howMany);
        48.  
        49. SmartPtr<Cassette> funMusic(new Cassette("Alapalooza"));
        50.  
        51. displayAndPlay(funMusic, 10);
        52.  
        53. // 위 상황에서 컴파일러는 멤버 함수 템플릿을
        54. // 이용하여 다음의 함수를 찍어냅니다.
        55.  
        56. SmartPtr<Cassette>::operator SmartPtr<MusicProduct>(void)
        57. {
        58. return SmartPtr<MusicProduct>(pointee);
        59. }
        60.  
        61.  
        62. //-----------------------------------------------------------------------------
        63. // 하지만 다음과 같은 경우에는 스마트 포인터가
        64. // 벙어리 포인터의 흉내를 낼 수 없습니다.
        65.  
        66. template <class T> // 이전과 같습니다. 타입변환 연산자를
        67. class SmartPtr { ... }; // 위한 멤버 함수 템플릿이 들어 있습니다.
        68.  
        69. class MusicProduct { ... };
        70. class Cassette : public MusicProduct { ... };
        71. class CasSingle : public Cassette { ... };
        72.  
        73. void displayAndPlay(const SmartPtr<MusicProduct>& pmp,
        74. int howMany);
        75.  
        76. void displayAndPlay(const SmartPtr<Cassette>& pc,
        77. int howMany);
        78.  
        79. SmartPtr<CasSingle> dumbMusic(new CasSingle
        80. ("Achy Breaky Heart"));
        81.  
        82. displayAndPlay(dumbMusic, 1); // 에러입니다!
        83.  
        84. // 우리들 예상에는 오버로딩된 함수 중에
        85. // SmartPtr<Cassette>을 받는 버전이
        86. // 선택될 것 같습니다.
        87.  
        88. // CasSingle은 Cassette로부터 직접 파생되었고,
        89. // MusicProduct로부터는 간접적으로 파생되었기
        90. // 때문입니다.
        91.  
        92. // 벙어리 포인터의 경우엔 이 예상이 맞습니다.
        93.  
        94. // 하지만 스마트 포인터에서는 멤버 함수를 써서
        95. // 타입변환을 수행하기 때문에, C++ 컴파일러의
        96. // 눈에는 모든 변환 함수가 똑같이 보입니다.
        97.  
        98. // 결국 적합한 displayAndPlay를 선택하지 못하고
        99. // "모호(ambiguous)하다"라는 에러를 냅니다.

        
        
        예제 코드 접기
        
        
        

      • 스마트 포인터와 const

        벙어리 포인터를 선언할 때 붙일 수 있는 const 키워드로는 포인터가 가리키는 것과 포인터 그 자체를 상수(constant)로 만들 수 있습니다. 이 개념을 그대로 스마트 포인터로 가져오면, 다음과 같이 네 가지 경우를 표현할 수 있습니다.
        
        // 비상수 객체,
        // 비상수 포인터
        SmartPtr<CD> p;
        
        // 상수 객체,
        // 비상수 포인터
        SmartPtr<const CD> p;
        
        // 비상수 객체,
        // 상수 포인터
        const SmartPtr<CD> p;
        
        // 상수 객체,
        // 상수 포인터
        const SmartPtr<const CD> p;
        
        물론 SmartPtr<CD>에서 SmartPtr<const CD>로 변환이 가능하도록 멤버 함수 템플릿을 이용한 암시적 변환 함수를 만들어 줘야 합니다.
        
        하지만 멤버 함수 템플릿을 지원하지 않는 구형 컴파일러를 사용하고 있다면 다른 방법을 사용해야 합니다.
        
        상수 객체가 할 수 있는 모든 행위를 비상수 객체도 할 수 있다는 점은 public 상속 관계와 매우 유사합니다. 따라서 상수 객체를 가리키는 스마트 포인터를 public 상속받아, 비상수 객체를 가리키는 스마트 포인터를 구현함으로써 이 문제를 해결할 수 있습니다.
        
        예제 코드 보기
        
        
        

        1. template <class T> // 상수 객체에 대한
        2. class SmartPtrToConst { // 스마트 포인터 클래스
        3. ... // 스마트 포인터 클래스가 가진
        4. // 공통의 멤버 함수는 모두 포함
        5. protected:
        6. union {
        7. const T* constPointee; // SmartPtrToConst에서 쓰기 위한 것
        8. T* pointee; // SmartPtr에서 쓰기 위한 것
        9. };
        10. };
        11.  
        12. template <class T> // 비상수 객체에 대한
        13. class SmartPtr: // 스마트 포인터 클래스
        14. public SmartPtrToConst<T> {
        15. ... // 데이터 멤버는 없습니다.
        16. };
        17.  
        18. SmartPtr<CD> pCD = new CD("Famous Movie Themes");
        19. SmartPtrToConst<CD> pConstCD = pCD; // 문제 없습니다.
        20.  
        21. // 단 공용체를 써서 구현한 경우
        22. // 각 클래스의 멤버 함수에 적절한
        23. // 타입의 포인터를 쓰는 것은
        24. // 개발자의 의무입니다.
        25.  
        26. // 이 부분만큼은 컴파일러의 도움을 받아
        27. // 문법적 제약을 가한다든지 할 수가
        28. // 없습니다.
        29.  
        30. // 이것이 공용체의 위험한 점이죠.

        
        
        예제 코드 접기
        
        
        

  29. 참조 카운팅(Reference Counting) / 258

      • 참조 카운팅이 만들어진 첫 번째 이유는, 힙 객체를 둘러싼 내부 정보를 유지하는 작업을 단순하게 하자는 것입니다.

        참조 카운팅은 객체 소유권을 추적해야 하는 고민을 없앱니다.

      • 두 번째 이유는 지극히 상식적인 것입니다. 똑같은 값을 갖고 있는 객체들이 각각 메모리를 할당하여 값의 복사본을 가지고 있는 것은 공간적, 시간적 낭비임에 틀림없습니다.

        참조 카운팅을 사용하면, 공통된 값을 나타내는 데이터 하나를 공유하게 하면 되므로 여러모로 이득입니다.

      • 참조 카운팅의 구현 예제입니다.

        참조 카운팅을 하기 위해서는, 공유할 값과 그 값을 갖는(가리키는) 객체가 몇 개인지를 담을 변수(참조 카운트)가, 각 값마다 하나씩 필요합니다. String 클래스를 참조 카운팅을 적용하여 구현한 형태를 예로 들어 보겠습니다.
        
        참조 카운팅 예제 코드 보기
        
        
        

        1. // 참조 카운트는 굳이 String 객체 내에
        2. // 있을 필요가 없습니다. 왜냐하면 실제
        3. // 문자열값 하나에 대해서 참조 카운트는
        4. // 하나만 있으면 되기 때문입니다.
        5.  
        6. // 따라서 참조 카운트와 값을 묶는 클래스를
        7. // 만드는 편이 관리하기 좋을 것입니다.
        8.  
        9. // 이 클래스의 이름은 StringValue이고,
        10. // 이 클래스의 존재 이유는 String 클래스의
        11. // 구현을 보조하는 것이므로, String의
        12. // private 영역에 이 클래스를
        13. // 중첩(nesting)시키겠습니다.
        14.  
        15. // 덧붙여서 StringValue 데이터 구조는
        16. // String의 모든 멤버 함수가 접근할
        17. // 수 있도록 StringValue는 클래스(class)
        18. // 가 아닌 구조체(struct)로 선언하겠습니다.
        19.  
        20. class String {
        21. public:
        22. String(const char *initValue = "");
        23. String(const String& rhs);
        24. ~String(void);
        26. String& operator =(const String& rhs);
        27.  
        28. ... // String에 관련된 멤버 함수
        29. // 는 여기에 있습니다.
        30. private:
        31. struct StringValue { // 참조 카운트와 실제 문자열값을
        32. int refCount; // 가집니다.
        33. char *data;
        35. StringValue(const char *initValue);
        36. ~StringValue(void);
        37. };
        38.  
        39. StringValue *value; // 이 String 객체의 값
        40. };
        41.  
        42. String::StringValue::StringValue(const char *initValue)
        43. : refCount(1)
        44. {
        45. data = new char[strlen(initValue) + 1];
        46. strcpy(data, initValue);
        47. }
        48.  
        49. String::StringValue::~StringValue(void)
        50. {
        51. delete[] data;
        52. }
        53.  
        54. String::String(const char *initValue) // 이 생성자는 인자로 넘기는
        55. : value(new StringValue(initValue)) // char* 포인터를 써서
        56. {} // StringValue 객체를 새로
        57. // 생성한 후에, 새로 만들어진
        58. // StringValue를 역시
        59. // 새로 만들어진 String 객체가
        60. // 가리키게 하는 것입니다.
        61.  
        62. String::String(const String& rhs) // 복사 생성자는 꼭 필요한
        63. : value(rhs.value) // 것일 뿐만 아니라, 효율을
        64. { // 위한 장치입니다.
        65. ++value->refCount; // 새로 생성된 String 객체는
        66. } // 복사되는 String 객체와
        67. // 똑같은 StringValue 객체를
        68. // 공유하게 됩니다.
        69.  
        70. String::~String(void) // 소멸자의 경우 복사 생성자와
        71. // 반대로 참조 카운트를 줄이고,
        72. // 참조 카운트가 1인 경우에는
        73. { // value를 삭제합니다.
        74. if (--value->refCount == 0) delete value;
        75. }
        76.  
        77. String& String::operator =(const String& rhs)
        78. {
        79. if (value == rhs.value) { // 이미 같은 값이면 아무 것도
        80. return *this; // 하지 않습니다. 보통 이런 연산자
        81. } // 에서 행하는 this와 &rhs의 대등
        82. // 비교 대신에 사용된 코드입니다.
        84. if (--value->refCount == 0) { // 원래의 값을 사용하는 객체가
        85. delete value; // 없으면 *this의 값을 소멸시킵니다.
        86. }
        88. value = rhs.value; // *this로 하여금 rhs의 값을
        89. ++value->refCount; // 공유하도록 합니다.
        91. return *this;
        92. }

        
        
        참조 카운팅 예제 코드 접기
        
        
        

      • 기록시점 복사(Copy-on-Write)

        참조 카운팅 기능을 갖는 문자열의 기본적인 뼈대를 마무리하는 마지막 부품은 배열-대괄호 연산자([])입니다. 이 연산자는 String 객체가 가리키는 문자열에 들어 있는 문자 하나씩을 읽고 쓰는데 사용됩니다.
        
        이 함수의 const 버전은 문자열값을 변경하지는 않으므로 단순히 넘겨받은 인덱스의 문자를 반환하기만 하면 됩니다. 하지만 const가 아닌 operator [] 버전은 문자열값을 변경할 수도, 하지 않을 수도 있기 때문에 신경써서 구현해야 합니다. 왜냐하면 두 String 객체가 같은 문자열값을 가리키고 있는 경우, 한 객체의 문자열값이 변경되면 다른 객체에도 영향을 주기 때문입니다. 따라서 문자열값을 변경할 가능성이 있는 멤버함수는, 자신이 갖는 문자열값을 가리키는 다른 객체가 존재할 경우에는 문자열을 복사한 후 작업해야 합니다.
        
        기록시점 복사 예제 코드 보기
        
        
        

        1. class String {
        2. public:
        3. const char& operator [](int index) const; // 상수 String 객체에 대한 [] 연산자
        5. char& operator [](int index); // 비상수 String 객체에 대한 [] 연산자
        6. ...
        7. };
        8.  
        9. const char& String::operator [](int index) const
        10. {
        11. return value->data[index]; // 예제를 간결하게 하기 위해
        12. } // 인덱스 유효성 검사는 생략했습니다.
        13.  
        14. String s;
        15. ...
        16. cout << s[3]; // 문자 읽기
        17. s[5] = 'x'; // 문자 쓰기
        18.  
        19. // 위의 예제에서 문자를 읽고 쓰는 경우 모두
        20. // 비상수 String 객체에 대한 [] 연산자가
        21. // 사용되었습니다.
        22.  
        23. // C++ 컴파일러의 힘을 빌려 operator []가
        24. // 쓰기 동작에 쓰였는지 읽기 동작에 쓰였는지를
        25. // 구분할 방법은 없기 때문에, 비상수 String
        26. // 객체에 대한 [] 연산자는 항상 쓰기를 한다고
        27. // 가정을 할 수 밖에 없습니다.
        28.  
        29. // 단 읽기와 쓰기를 구분하는 데 항목 30에서
        30. // 다룰 프로시(Proxy) 클래스의 도움을 받을 수
        31. // 있긴 합니다.
        32.  
        33. char& String::operator [](int index)
        34. {
        35. // 다른 String 객체와 문자열값을 공유하고 있는 상태에서는,
        36. // 이 String 객체만의 문자열 사본을 별도로 마련합니다.
        37. if (value->refCount > 1) {
        38. --value->refCount; // 현재 문자열값에 대한 참조 카운트를
        39. // 감소시킵니다. 왜냐하면 이제 그 값을
        40. // 사용하지 않겠다는 표시를 해야 하니까요.
        42. value = // 이 String 객체만의
        43. new StringValue(value->data); // 문자열 사본을 마련합니다.
        44. }
        45. // 공유 관계가 끊긴 StringValue 객체 안의
        46. // 문자에 대한 참조자를 반환합니다.
        47. return value->data[index];
        48. }

        
        
        기록시점 복사 예제 코드 접기
        
        
        

      • 포인터, 참조자, 그리고 기록시점 복사

        기록시점 복사를 하는 경우 const가 아닌 operator []에 대해서 다음과 같은 문제가 발생할 수 있습니다.
        
        String s1 = "Hello";
        char *p = &s1[1];
        
        String s2 = s1;
        *p = 'x';
        
        이 때, 기록시점 복사를 하기 때문에 s1과 s2는 하나의 문자열값을 공유하고 있어서, 결국 마지막 문장에 의해 s1과 s2모두 "Hxllo"로 바뀌게 됩니다. 이 문제는 포인터 뿐만이 아니라, 참조자를 사용한 경우에도 발생할 수 있습니다.
        
        이 문제를 해결할 수 있는 방법은 최소한 세 가지 입니다.
        1. 이런 문제를 무시하고, 문제가 없는 것처럼 꾸미기
           참조 카운트 기능을 갖는 문자열을 구현한 클래스 라이브러리를 살펴보면, 이런 경우가 애처로울 정도로 흔합니다. 하지만 별로 바람직하지는 못한 방법이죠.
        2. 불법으로 규정하기
           라이브러리의 사용 문서(설명서)에 이러한 코드를 작성하면 안된다고 못을 박는 것입니다. 그리고 사용자가 고의든 아니든 이런 코드를 작성하여 발생한 불만에 대해서는 "아참, 설명서를 읽으셔야죠. 하지 말라고 되어 있는데"라고 응답하면 그만입니다.
        3. 이 문제를 적극적으로 직접 없애기
           구현하기는 어렵지 않지만 객체들 간의 값 공유 횟수가 줄어들 수 있습니다. 이 방법의 핵심은 각 StringValue 객체에 그 객체의 공유 가능 여부를 표시하는 플래그를 넣는 것입니다. 처음에는 이 플래그를 켜고('공유가능'이란 뜻) 나중에 그 객체가 나타내는 값에 대해 비상수 operator []가 호출될 때마다 이 플래그를 끕니다. 일단 이 플래그가 한 번 꺼지면 다시는 켜지지 않도록 합니다.
        
        ※ std::string 타입의 경우 두 번째와 세 번째 방법을 섞어서 사용하고 있습니다. 비상수 operator []에서 반환된 참조자는 그 문자열을 수정하는 다른 함수가 호출되기 전까지는 유효합니다. 즉 다른 함수가 호출된 후에는 그 참조자(혹은, 그 참조자로 참조한 문자)를 사용했다간 오작동이 일어날 수 있습니다. 그렇기 때문에, 문자열을 수정하는 함수가 호출될 때마다 공유 가능성 플래그를 true로 되돌려 놓아도 되도록 만들어져 있습니다.
        
        공유 가능 플래그 예제 코드 보기
        
        
        

        1. class String {
        2. private:
        3. struct StringValue {
        4. int refCount;
        5. bool shareable; // 이것이 추가된 것입니다.
        6. char *data;
        8. StringValue(const char *initValue);
        9. ~StringValue(void);
        10. };
        11. ...
        12. };
        13.  
        14. String::StringValue::StringValue(const char *initValue)
        15. : refCount(1),
        16. shareable(true) // 플래그 초기화용으로 추가했습니다.
        17. {
        18. data = new char[strlen(initValue) + 1];
        19. strcpy(data, initValue);
        20. }
        21.  
        22. String::StringValue::~StringValue(void)
        23. {
        24. delete[] data;
        25. }
        26.  
        27. String::String(const String& rhs)
        28. {
        29. if (rhs.value->shareable) { // 플래그가 공유 가능함을
        30. value = rhs.value; // 나타낼 때에만 공유합니다.
        31. ++value->refCount;
        32. }
        33. else {
        34. value = new StringValue(rhs.value->data);
        35. }
        36. }
        37.  
        38. char& String::operator [](int index)
        39. {
        40. if (value->refCount > 1) {
        41. --value->refCount;
        42. value = new StringValue(value->data);
        43. }
        45. value->shareable = false; // 이것이 추가되었습니다.
        46. return value->data[index];
        47. }
        48.  
        49. // 항목 30에 나온 프록시 클래스 기법을 써서
        50. // operator []의 읽기/쓰기를 구별할 경우에는,
        51. // 공유 가능성 플래그가 false로 표시되는
        52. // StringValue 객체의 개수가 줄어드는 것이
        53. // 보통입니다.

        
        
        공유 가능 플래그 예제 코드 접기
        
        
        

      • 참조 카운팅 기능을 가진 기본 클래스

        참조 카운팅(Reference counting) 기능은 비단 문자열에만 필요한 것은 아닙니다. 하지만 번듯하게 만들어져 있는 멀쩡한 클래스에 참조 카운팅 기능을 넣기에는 너무 많은 노력이 필요하게 됩니다. 이러한 노력을 피하기 위한 첫 단추는 참조 카운팅 기능을 가진 객체의 기반 코드를 제공하는 C++ 기본 클래스를 만드는 것 부터 시작합니다. 이름하여 RCObject, 자동 참조 카운팅 기능을 이용하고자 하는 클래스는 이 클래스를 상속하면 됩니다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. class RCObject {
        3. public:
        4. RCObject(void);
        5. RCObject(const RCObject& rhs);
        6. RCObject& operator =(const RCObject& rhs);
        7. virtual ~RCObject(void) = 0;
        8. void addReference(void);
        9. void removeReference(void);
        10. void markUnshareable(void);
        12. bool isShareable(void) const;
        14. bool isShared(void) const;
        15.  
        16. private:
        17. int refCount;
        18. bool shareable;
        19. };
        20.  
        21. RCObject::RCObject(void)
        22. : refCount(0), shareable(true) {}
        23.  
        24. RCObject::RCObject(const RCObject&)
        25. : refCount(0), shareable(true) {}
        26. RCObject& RCObject::operator =(const RCObject&)
        27. { return *this; }
        28.  
        29. RCObject::~RCObject(void) {} // 가상 소멸자는 반드시 항상
        30. // 코드 몸체를 가져야 합니다.
        31. // 가상 소멸자가 순수 가상 함수이고
        32. // 아무 것도 하지 않더라도 구현해야
        33. // 합니다(항목 33을 같이 보세요).
        34.  
        35. void RCObject::addReference(void)
        36. { ++refCount; }
        37.  
        38. void RCObject::removeReference(void)
        39. { if (--refCount == 0) delete this; }
        40.  
        41. void RCObject::markUnshareable(void)
        42. { shareable = false; }
        43.  
        44. bool RCObject::isShareable(void) const
        45. { return shareable; }
        46.  
        47. bool RCObject::isShared(void) const
        48. { return refCount > 1; }
        49.  
        50. // 여기서 이상한 부분을 하나 찾을 수 있는데,
        51. // refCount가 두 개의 생성자에서 0으로
        52. // 세팅되고 있다는 점입니다. 보시면 알겠지만,
        53. // 이것은 RCObject를 생성하는 쪽에서
        54. // refCount를 1로 초기화 하는 작업을
        55. // 간단히 한 것이기 때문에, 여기에서는 그냥
        56. // 건드리지 않는 것이 좋겠습니다.
        57.  
        58. // 이상한 부분 또 하나는 복사 생성자가 무조건
        59. // refCount를 0으로 세팅하고 있다는 점입니다.
        60. // 그 이유는 값을 나타내는 객체를 새로 만들고
        61. // 있고, 새로 만들어진 객체의 값은 언제나
        62. // 공유되지 않은 상태에 있으며, 그 객체를
        63. // 생성한 쪽에서만 참조하기 때문입니다.
        64. // 다시 말씀드리지만 객체를 생성한 쪽에서는
        65. // refCount에 적당한 값을 넘겨주어야 합니다.
        66.  
        67. // RCObject의 대입 연산자는 아무 것도
        68. // 하지 않습니다. 사실 이 연산자가 호출될
        69. // 가능성은 영원히 없을 것 같습니다.
        70. // RCObject는 공유되는 값을 나타내는
        71. // 객체에 대한 기본 클래스이고, 참조 카운팅을
        72. // 사용해서 만든 시스템에서 이런 객체가
        73. // 다른 객체에 대입될 일은 없습니다.
        74.  
        75. // 그럼에도 불구하고, 어쩌다가 RCObject로부터
        76. // 상속받은 클래스에서 참조 카운트로 관리되는
        77. // 값에 대한 대입 연산이 이루어질 것으로
        78. // 예상하기는 그리 어렵지 않습니다.
        79. // 그렇기 때문에 RCObject의 대입 연산자는
        80. // 어떤 일이라도 해야 하고, 그 '어떤 일'이
        81. // 바로 '무위(아무 것도 안 함)'라는 것입니다.
        82.  
        83. // 예를 들어 StringValue 객체인 sv1과 sv2가
        84. // 있을 때, 다음과 같이 대이 연산이 수행되면
        85. // sv1과 sv2의 참조 카운트에는 어떻게
        86. // 변해야 할까요?
        87.  
        88. sv1 = sv2; // sv1과 sv2의 참조 카운트는
        89. // 어떤 영향을 받을까요?
        90.  
        91. // 위 문장이 수행된 결과, sv1의 공유값
        92. // (문자열값)만 변하면 되고, sv1과 sv2의
        93. // 참조 카운트는 모두 변하지 않습니다.
        94.  
        95.  
        96. //-----------------------------------------------------------------------------
        97. // 실제로 RCObject를 사용한 예를 봅시다.
        98. // StringValue 클래스가 이 RCObject
        99. // 기본 클래스로부터 참조 카운팅 기능을 물려받도록
        100. // 고쳐 봅시다.
        101.  
        102. class String {
        103. private:
        104. struct StringValue: public RCObject {
        105. char *data;
        107. StringValue(const char *initValue);
        108. ~StringValue(void);
        109. };
        110. ...
        111. };
        112.  
        113. String::StringValue::StringValue(const char *initValue)
        114. {
        115. data = new char[strlen(initValue) + 1];
        116. strcpy(data, initValue);
        117. }
        118.  
        119. String::StringValue::~StringValue(void)
        120. {
        121. delete[] data;
        122. }

        
        
        예제 코드 접기
        
        
        

      • 참조 카운트 동작을 자동화하기

        RCObject 클래스에는 참조 카운트를 저장할 수 있는 공간과, 이 참조 카운트를 조작할 수 있는 멤버 함수가 들어 있습니다. 하지만 이 함수는 직접 호출해 주어야 합니다. 이를테면, StringValue 객체에 대해 addReference와 removeReference를 호출하는 일은 String의 복사 생성자와 String의 대입 연산자가 마땅히 해 주어야 한다는 이야기입니다. 여기서 StringValue 객체를 가리키는 포인터(String 클래스의 경우 value 멤버)에, 벙어리 포인터 대신 스마트 포인터를 사용하면, addReference와 removeReference의 호출도 자동화할 수 있습니다.
        
        예제 코드 보기
        
        
        

        1. // T에 대한 스마트 포인터의 템플릿. T는 RCObject
        2. // 인터페이스를 지원해야 하는데, 대개 이것은 RCObject를
        3. // 상속함으로써 해결합니다.
        4.  
        5. template <class T>
        6. class RCPtr {
        7. public:
        8. RCPtr(T* realPtr = 0);
        9. RCPtr(const RCPtr& rhs);
        10. ~RCPtr(void);
        12. RCPtr& operator =(const RCPtr& rhs);
        14. T* operator ->(void) const; // 항목 28을 보세요.
        15. T& operator *(void) const; // 항목 28을 보세요.
        17. private:
        18. T *pointee; // 이 객체가 흉내내는
        19. // 벙어리 포인터
        20. void init(void); // 공통 초기화
        21. }; // 코드
        22.  
        23. template <class T>
        24. RCPtr<T>::RCPtr(T* realPtr) : pointee(realPtr)
        25. {
        26. init();
        27. }
        28.  
        29. template <class T>
        30. RCPtr<T>::RCPtr(const RCPtr& rhs) : pointee(rhs.pointee)
        31. {
        32. init();
        33. }
        34.  
        35. template <class T>
        36. void RCPtr<T>::init(void)
        37. {
        38. if (pointee == 0) { // 벙어리 포인터가 널(null)이면,
        39. return; // 스마트 포인터도 널입니다.
        40. }
        41. if (pointee->isShareable() == false) { // 이 객체의 값을 공유하는
        42. pointee = new T(*pointee); // 것이 불가능하면,
        43. } // 그 값을 복사합니다.
        45. pointee->addReference(); // 이 값에 대한 새 참조자가 생겼음을
        46. } // 알 수 있습니다.
        47.  
        48. // 여기서 문제가 한가지 있습니다.
        49. // 위에서 등장한 문장 중 아래 문장을 잘 봅시다.
        50.  
        51. pointee = new T(*pointee);
        52.  
        53. // pointee의 타입은 T에 대한 포인터입니다.
        54. // 따라서 이 문장은 T 객체를 새로 생성하고
        55. // T의 복사 생성자를 호출하여 그 객체를
        56. // 초기화 합니다.
        57.  
        58. // RCPtr이 String 클래스에 사용되는 경우에
        59. // T는 String::StringValue가 되므로,
        60. // 앞의 문장은 결국 String::StringValue의
        61. // 복사 생성자를 호출하는 셈이 되지요.
        62.  
        63. // 하지만, 이 클래스에 대해 우리가 선언해놓은
        64. // 복사 생성자가 없기 때문에, 컴파일러가 대신
        65. // 만들어 준 복사 생성자를 통해 얕은 복사를
        66. // 수행하게 됩니다. 이것은 재앙이나 마찬가지입니다.
        67.  
        68. // 그렇기 때문에, 포인터를 가진 클래스에 대해서는
        69. // 복사 생성자와 대입 연산자를 꼭 직접 만드는
        70. // 습관을 들여야 합니다.
        71.  
        72. // 이에 따라 StringValue의 내부를 조금
        73. // 고칠 필요가 있겠습니다.
        74.  
        75. class String {
        76. private:
        77. struct StringValue: public RCObject {
        78. StringValue(const StringValue& rhs);
        79. ...
        80. };
        81. ...
        82. };
        83.  
        84. String::StringValue::StringValue(const StringValue& rhs)
        85. {
        86. data = new char[strlen(rhs.data) + 1];
        87. strcpy(data, rhs.data);
        88. }
        89.  
        90. // 이 복사 생성자는 RCPtr<T>에 대한
        91. // 가정 하나를 깔고 만들어졌습니다.
        92. // 그 가정이란, T는 RCObject에서
        93. // 파생된 것이든지, 아니면 최소한 RCObject의
        94. // 기능을 모두 갖고 있어야 한다는 것입니다.
        95. // 이 부분에 대해서는 설명 문서에 언급해 두어야 합니다.
        96.  
        97. // RCPtr<T>의 가정 또 한 가지는
        98. // '가리킴을 당하는' 객체의 타입이
        99. // 반드시 T라는 것입니다.
        100. // 사실 RCPtr<T>는 T의 파생 타입도
        101. // 가리킬 수 있지만, 현재의 String
        102. // 클래스의 경우, StringValue에서
        103. // 클래스가 파생되는 것 자체를 가정하지
        104. // 않기 때문에, 이 부분에 대한 사항은
        105. // 무시하려고 합니다.
        106.  
        107. template <class T>
        108. RCPtr<T>& RCPtr<T>::operator =(const RCPtr& rhs)
        109. {
        110. if (pointee != rhs.pointee) { // 값이 변하지 않으면
        111. // 대입 연산을 수행하지 않고
        112. // 건너 뜁니다.
        114. T *oldPointee = pointee; // 바로 전의 pointee 값을 저장합니다.
        116. pointee = rhs.pointee; // 새 값을 가리킵니다.
        117. init(); // 가능하면 이 값을 공유하고,
        118. // 그렇지 않으면 별도의 사본을 만듭니다.
        120. if (oldPointee) {
        121. oldPointee->removeReference(); // 현재의 값에 대한 참조자를
        122. } // 제거합니다.
        123. }
        125. return *this;
        126. }
        127.  
        128. template <class T>
        129. RCPtr<T>::~RCPtr(void)
        130. {
        131. if (pointee) pointee->removeReference();
        132. }
        133.  
        134. template <class T>
        135. T* RCPtr<T>::operator ->(void) const { return pointee; }
        136.  
        137. template <class T>
        138. T& RCPtr<T>::operator *(void) const { return *pointee; }

        
        
        예제 코드 접기
        
        
        

      • 헤쳐 모여!(정리)

        지금까지 공부하며 만들어 놓은 이것저것을 모아서, RCObject와 RCPtr 클래스에 기반한 참조 카운팅 String 클래스를 만들어 보자고요.
        
        예제 코드 보기
        
        
        

        1. template <class T> // T에 대한 스마트 포인터 객체를
        2. class RCPtr { // 만드는 템플릿. T는 반드시
        3. public: // RCObject에서 파생된 것이어야 합니다.
        4. RCPtr(T* realPtr = 0);
        5. RCPtr(const RCPtr& rhs);
        6. ~RCPtr(void);
        8. RCPtr& operator =(const RCPtr& rhs);
        10. T* operator ->(void) const;
        11. T& operator *(void) const;
        13. private:
        14. T *pointee;
        15. void init(void);
        16. };
        17.  
        18. class RCObject { // 참조 카운팅 기능을 갖춘 객체를 위한
        19. public: // 기본 클래스
        20. void addReference(void);
        21. void removeReference(void);
        23. void markUnshareable(void);
        24. bool isShareable(void) const;
        26. bool isShared(void) const;
        28. protected:
        29. RCObject(void);
        30. RCObject(const RCObject& rhs);
        31. RCObject& operator =(const RCObject& rhs);
        32. virtual ~RCObject(void) = 0;
        34. private:
        35. int refCount;
        36. bool shareable;
        37. };
        38.  
        39. class String { // 애플리케이션 개발자가
        40. public: // 사용하게 될 클래스
        41. String(const char *value = "");
        43. const char& operator [](int index) const;
        44. char& operator [](int index);
        46. private:
        47. // 문자열 값을 나타내는 클래스
        48. struct StringValue: public RCObject {
        49. char *data;
        51. StringValue(const char *initValue);
        52. StringValue(const StringValue& rhs);
        53. void init(const char *initValue);
        54. ~StringValue(void);
        55. };
        56. RCPtr<StringValue> value;
        57. };
        58.  
        59. // 이제 String 클래스에는
        60. // 복사 생성자, 대입 연산자, 소멸자가 모두
        61. // 필요 없어졌습니다.
        62.  
        63. // 컴파일러가 만들어 낸 String의 복사 생성자가
        64. // 자동으로 RCPtr멤버의 복사 생성자를 호출하는데,
        65. // 이 클래스의 복사 생성자가 StringValue
        66. // 객체를 적절하게 조작해 줍니다.
        67.  
        68. // 물론 깊은 복사 외에, 참조 카운팅, 소멸과
        69. // 같은 작업도 다 알아서 처리해 줍니다.
        70.  
        71.  
        72. // RCObject의 구현 코드를 보시죠.
        73.  
        74. RCObject::RCObject(void)
        75. : refCount(0), shareable(true) {}
        76.  
        77. RCObject::RCObject(const RCObject&)
        78. : refCount(0), shareable(true) {}
        79.  
        80. RCObject& RCObject::operator =(const RCObject&)
        81. { return *this; }
        82.  
        83. RCObject::~RCObject(void) {}
        84.  
        85. void RCObject::addReference(void) { ++refCount; }
        86.  
        87. void RCObject::removeReference(void)
        88. { if (--refCount == 0) delete this; }
        89.  
        90. void RCObject::markUnshareable(void)
        91. { shareable = false; }
        92.  
        93. bool RCObject::isShareable(void) const
        94. { return shareable; }
        95.  
        96. bool RCObject::isShared(void) const
        97. { return refCount > 1; }
        98.  
        99.  
        100. // 그리고 RCPtr을 구현한 코드도요.
        101.  
        102. template <class T>
        103. void RCPtr<T>::init(void)
        104. {
        105. if (pointee == 0) return;
        106. if (pointee->isShareable() == false) {
        107. pointee = new T(*pointee);
        108. }
        110. pointee->addReference();
        111. }
        112.  
        113. template <class T>
        114. RCPtr<T>::RCPtr(T* realPtr)
        115. : pointee(realPtr)
        116. { init(); }
        117.  
        118. template <class T>
        119. RCPtr<T>::RCPtr(const RCPtr& rhs)
        120. : pointee(rhs.pointee)
        121. { init(); }
        122.  
        123. template <class T>
        124. RCPtr<T>::~RCPtr(void)
        125. { if (pointee) pointee->removeReference(); }
        126.  
        127. template <class T>
        128. RCPtr<T>& RCPtr<T>::operator =(const RCPtr& rhs)
        129. {
        130. if (pointee != rhs.pointee) {
        131. T *oldPointee = pointee;
        132. pointee = rhs.pointee;
        133. init();
        134. if (oldPointee) oldPointee->removeReference();
        135. }
        137. return *this;
        138. }
        139.  
        140. template <class T>
        141. T* RCPtr<T>::operator ->(void) const { return pointee; }
        142.  
        143. template <class T>
        144. T& RCPtr<T>::operator *(void) const { return *pointee; }
        145.  
        146.  
        147. // String::StringValue를 구현한 코드는 다음과 같습니다.
        148.  
        149. void String::StringValue::init(const char *initValue)
        150. {
        151. data = new char[strlen(initValue) + 1];
        152. strcpy(data, initValue);
        153. }
        154.  
        155. String::StringValue::StringValue(const char *initValue)
        156. { init(initValue); }
        157.  
        158. String::StringValue::StringValue(const StringValue& rhs)
        159. { init(rhs.data); }
        160.  
        161. String::StringValue::~StringValue(void)
        162. { delete[] data; }
        163.  
        164.  
        165. // 결국 모든 길은 String으로 향하게 되어 있습니다.
        166. // String 클래스는 이렇게 구현하고요.
        167.  
        168. String::String(const char *initValue)
        169. : value(new StringValue(initValue)) {}
        170.  
        171. const char& String::operator [](int index) const
        172. { return value->data[index]; }
        173.  
        174. char& String::operator [](int index)
        175. {
        176. if (value->isShared()) {
        177. value = new StringValue(value->data);
        178. }
        180. value->markUnshareable();
        182. return value->data[index];
        183. }

        
        
        예제 코드 접기
        
        
        

      • 기존의 클래스에 참조 카운팅 기능을 부착하는 방법

        지금까지 공부한 모든 내용은 클래스의 소스 코드를 우리가 직접 건드릴 수 있다는 가정을 아래에 깔고 있었습니다. 하지만 참조 카운팅 기능을 넣었으면 하는 클래스가 애석하게도 우리의 손이 미치지 않는 라이브러리에 들어있다면, 어떻게 하시겠습니까? 이를테면, 어떤 클래스 라이브러리에 Widget이란 클래스가 들어있는데, 이 Widget에 참조 카운팅 기능을 붙이고 싶다고 합시다. 지금까지 우리가 공부한 것처럼 Widget이 RCObject을 상속하게 한다든지 하는 방법을 쓸 수 없기 때문에, RCPtr 같은 것도 쓸 수 없습니다.
        
        우선, Widget이 RCObject를 상속했더라면 어떤 설계가 나올 수 있을지 생각해 보는 것으로 시작하지요. 이 경우에는 RCWidget이란 클래스를 만들어서 사용자가 쓸 수 있게 해야 할 것입니다. 하지만 이렇게 놓고 보면 모든 상황이 String/StringValue 예제와 흡사하게 만들어집니다. RCWidget은 String에, Widget은 StringValue에 대응되는 것이죠.
        
        하지만 실제로는 Widget이 RCObject를 상속받을 수 없으니, 간접적인 수단을 덧붙여서 해결해야 합니다. 먼저 CountHolder라는 이름의 클래스를 끌어들였습니다. 참조 카운트를 가지는 역할을 맡은 이 클래스는 RCObject를 상속합니다. 게다가 이 클래스에는 Widget에 대한 포인터도 넣습니다. 마지막으로 RCPtr 템플릿 대신에 RCIPtr란 이름의 템플릿으로 교체합니다. 이 템플릿은 CountHolder 클래스를 조작할 수 있습니다(RCIPtr의 "I"는 "indirect"를 의미합니다).
        
        RCIPtr 예제 코드 보기
        
        
        

        1. template<class T>
        2. class RCIPtr {
        3. public:
        4. RCIPtr(T* realPtr = 0);
        5. RCIPtr(const RCIPtr& rhs);
        6. ~RCIPtr(void);
        8. RCIPtr& operator =(const RCIPtr& rhs);
        10. const T* operator ->(void) const; // 이 함수들이 이런
        11. T* operator ->(void); // 방식으로 선언된 이유는
        12. const T& operator *(void) const; // 소스 코드 이후에
        13. T& operator *(void); // 설명되어 있습니다.
        15. private:
        16. struct CountHolder: public RCObject {
        17. ~CountHolder(void) { delete pointee; }
        18. T* pointee;
        19. };
        21. CountHolder *counter;
        23. void init(void);
        24. void makeCopy(void); // 다음을 보세요.
        25. };
        26.  
        27. template <class T>
        28. void RCIPtr<T>::init(void)
        29. {
        30. if (counter->isShareable() == false) {
        31. T *oldValue = counter->pointee;
        32. counter = new CountHolder;
        33. counter->pointee = new T(*oldValue);
        34. }
        36. counter->addReference();
        37. }
        38.  
        39. template <class T>
        40. RCIPtr<T>::RCIPtr(T* realPtr)
        41. : counter(new CountHolder)
        42. {
        43. counter->pointee = realPtr;
        44. init();
        45. }
        46.  
        47. template <class T>
        48. RCIPtr<T>::RCIPtr(const RCIPtr& rhs)
        49. : counter(rhs.counter)
        50. { init(); }
        51.  
        52. template <class T>
        53. RCIPtr<T>::~RCIPtr(void)
        54. { counter->removeReference(); }
        55.  
        56. template <class T>
        57. RCIPtr<T>& RCIPtr<T>::operator =(const RCIPtr& rhs)
        58. {
        59. if (counter != rhs.counter) {
        60. counter->removeReference();
        61. counter = rhs.counter;
        62. init();
        63. }
        64. return *this;
        65. }
        66.  
        67. template <class T> // 기록시점 복사
        68. void RCIPtr<T>::makeCopy(void) // (Copy-on-write(COW))
        69. { // 의 복사 부분을 구현한 코드
        70. if (counter->isShared()) {
        71. T *oldValue = counter->pointee;
        72. counter->removeReference();
        73. counter = new CountHolder;
        74. counter->pointee = new T(*oldValue);
        75. counter->addReference();
        76. }
        77. }
        78.  
        79. template <class T> // 읽기 전용(const) 액세스
        80. const T* RCIPtr<T>::operator ->(void) const // 즉, COW가 필요없습니다.
        81. { return counter->pointee; }
        82.  
        83. template <class T> // 읽기/쓰기(const가 아님)
        84. T* RCIPtr<T>::operator ->(void) // 액세스. 즉, COW가
        85. { makeCopy(); return counter->pointee; } // 필요합니다.
        86.  
        87. template <class T> // 읽기 전용(const) 액세스
        88. const T& RCIPtr<T>::operator *(void) const // 즉, COW가 필요없습니다.
        89. { return *(counter->pointee); }
        90.  
        91. template <class T> // 읽기/쓰기(const가 아님)
        92. T& RCIPtr<T>::operator *(void) // 액세스. 즉, COW를
        93. { makeCopy(); return *(counter->pointee); } // 수행합니다.
        94.  
        95. // 이렇게 만들어진 RCIPtr은 RCPtr과 비교해서
        96. // 두 가지가 다릅니다.
        97.  
        98. // 첫째, RCPtr은 값을 직접 가리키고 있는 반면,
        99. // RCIPtr은 CountHolder 객체로 하여금
        100. // 값을 가리키게 하고 자신은 CountHolder를
        101. // 가리킵니다.
        102.  
        103. // 둘째, RCIPtr은 operator->와 operator*를
        104. // 오버로딩해서, 가리킴을 당하는 객체에 대해 읽기/쓰기
        105. // 액세스가 이루어질 때마다 자동으로 기록시점 복사가
        106. // 이루어지도록 하였습니다.

        
        
        RCIPtr 예제 코드 접기
        
        
        RCIPtr이 만들어진 이상, RCWidget를 구현하기는 더 이상 꿈이 아닙니다. RCWidget의 멤버 함수는 Widget 객체에 대한 RCIPtr을 통해 Widget 객체의 멤버 함수에게 책임을 전가하는(!) 것으로 구현할 수 있기 때문입니다.
        
        RCWidget 예제 코드 보기
        
        
        

        1. // 예를 들어 Widget이 다음과 같이 생겼다면,
        2.  
        3. class Widget {
        4. public:
        5. Widget(int size);
        6. Widget(const Widget& rhs);
        7. ~Widget(void);
        8. Widget& operator =(const Widget& rhs);
        10. void doThis(void);
        11. int showThat(void) const;
        12. };
        13.  
        14. // RCWidget은 이렇게 정의할 수 있을 것입니다.
        15.  
        16. class RCWidget {
        17. public:
        18. RCWidget(int size) : value(new Widget(size)) {}
        19. void doThis(void) { value->doThis(); }
        20. int showThat(void) const { return value->showThat(); }
        22. private:
        23. RCIPtr<Widget> value;
        24. };
        25.  
        26. // RCWidget의 멤버 함수가 하는 일은,
        27. // value가 가리키고 있는 Widget 객체가
        28. // 가진, 똑같은 이름의 멤버 함수를 호출하고 그
        29. // 반환값을 그대로 반환하는 일 뿐입니다.
        30.  
        31. // 이와 아울러, RCWidget에는 복사 생성자,
        32. // 대입 연산자, 소멸자가 없습니다. String
        33. // 클래스와 마찬가지로, 이 세 개의 함수는
        34. // 작성할 필요가 없습니다. RCIPtr의 똘똘한
        35. // 동작 덕택이죠.

        
        
        RCWidget 예제 코드 접기
        
        
        

      • 총정리

        참조 카운팅은 무료로 얻어지지 않습니다. 참조 카운팅으로 유지되는 객체값(object value)에는 참조 횟수(카운트)가 반드시 포함되며, 관련된 거의 모든 동작에서 이 참조 횟수를 조작해야 합니다. 게다가 참조 카운팅을 쓰는 클래스의 코드는 그렇지 않은 클래스보다 더 복잡합니다. String클래스를 예로 들면 참조 카운팅을 하기 위해 세 개의 보조 클래스(StringValue, RCObject, RCPtr)가 필요합니다. 이를 제작, 시험, 문서화, 유지보수하는 것이 한 개의 클래스에 대해 이렇게 하는 것 보다 힘든 것은 불을 보듯 뻔합니다.
        
        참조 카운팅은 객체들 사이에서 값의 공유가 빈번하다는 가정 하에 고안한 최적화 기법입니다(항목 18도 같이 보세요). 만약에 참조 카운팅을 쓴 코드가 메모리도 더 많이 먹고 코드도 더 많이 실행한다면, 이 가정은 실패한 것입니다. 참조 카운팅이 효율 향상에 효과적일 수 있는 상황은 다음의 두 가지로 정리할 수 있습니다.
        • 상대적으로 많은 객체들이 상대적으로 적은 값을 공유할 때.
          이러한 상황은 대개 대입 연산자와 복사 생성자가 호출될 때 만들어집니다. 객체 개수에 대한 값 개수의 비율이 클수록 참조 카운팅을 할 필요가 더 커집니다.
        • 어떤 객체값을 생성하거나 소멸시키는데 많은 비용이 들거나 메모리 소모가 클 때.
          이러한 경우라고 해도, 여러 객체들이 값을 공유하지 않으면 참조 카운팅은 별 효과를 보이지 않습니다.
        
        앞의 조건이 만족되는지 확인하는 방법은 오로지 하나입니다. 프로그램을 프로파일링하고 설치해 보는 것입니다(항목 16 참조).
        
        앞의 조건이 충족되었다고 하더라도 참조 카운팅을 사용한 코드 설계가 여전히 적합하지 않을 경우도 있습니다. 어떤 자료구조는 자기 참조형(self-referential) 혹은 원형 의존형(circular dependency) 구조를 띄고 있어서(방향성 그래프(directed graph)가 한 예인데, 트리(tree)구조가 여기에 속합니다), 참조 카운팅 적용에 애로사항을 일으키기도 합니다. 이런 자료구조에서는 사용되지 않는(고립된) 객체들이 생기는 경향이 있는데, 이 객체들의 참조 카운트는 절대로 0이 되지 않습니다. 왜냐하면, 사용되지 않은 구조 안의 객체는 같은 구조 안에 있는 최소한 하나의 다른 객체가 가리키고 있기 때문입니다.
        
        마지막으로 한 가지만 더 이야기하고 이번 항목을 마무리지어볼까 합니다. RCObject::removeReference는 객체의 참조 카운트를 감소시키고, 감소 후 값이 0인 경우 this에 대해 delete를 호출함으로써 객체를 소멸시킵니다. delete를 호출한다는 것은, RCObject의 생성이 오로지 new를 통해 힙에 할당되어야 한다는 것을 의미하고, 이것이 지켜지도록 제약할 수 있는 어떤 방법이 필요합니다.
        
        간단히 말해, 이번 항목에서 사용한 방법은 'RCObject를 생성할 수 있는 클래스를 정해 놓고, 그 클래스를 사용할 때 그 제약을 잘 지키라고 알리는 것'이라고 할 수 있겠습니다. 참조 카운팅 객체를 생성할 수 있는 자격을 제한하고, 자격을 가진 쪽은 반드시 그 객체 생성에 수반되는 규칙을 따를 것을 명확히 알려야 한다는 것이죠.

  30. 프록시(Proxy) 클래스 / 295

      • 2차원 배열 구현하기

        C/C++에서의 다차원 배열은 사실 컴파일러가 1차원 배열을 가지고 다차원 배열을 흉내낸 것에 불과합니다. 게다가 C/C++은 어떤 변수의 값 만큼의 크기를 갖는 배열을 선언하는것을 싫어합니다. 이것을 극복하기 위해 C++에서는 OOP의 성질을 살리겠다고 '배열을 나타내는 클래스'를 만들어 구현하는것이 보통입니다. 이를테면 2차원 배열을 나타내는 클래스를 만들어 사용하는 것이죠.
        
        그런데 이런 배열 객체는 왠지 조금 뻑뻑한 느낌을 줍니다. C/C++ 스타일의 배열 조작에 익숙한 우리들에게는 인덱스 연산자인 대괄호([])를 썼으면 하는 소망이 있을 테니까요. 다음과 같이 말이죠.
        
        Array2D<int> data(10, 20);
        cout << data[3][6];
        
        하지만 operator[][] 란 것은 없기 때문에 직접적으로 이런 객체를 구현할 수는 없습니다. 여기서 1차원 배열로 다차원 배열을 흉내내는 방법에 대해서 생각해 볼 필요가 있습니다.
        
        int data[10][20];
        
        위에서 data는 사실 2차원 배열이 아니라 단지 10 개의 요소를 가진 1차원 배열입니다. 10개의 요소 자체가 바로 20개 요소의 배열이기 때문에, 결국 data[3][6]이란 표현식은 (data[3])[6]으로 풀어서 이해하시면 됩니다. data의 4번째 요소가 되는 배열 안의 7번째 요소인 것이죠.
        
        이 원리를 똑같이 써서 Array2D를 가지고 놀 수 있습니다. 우선, operator[]의 오버로딩을 통해 또 다른 배열을 나타내는 클래스 객체를 반환하게 합니다. 이 클래스가 Array1D 입니다. 그리고 나서, Array1D의 operator[]를 오버로딩해서 원래의 2차원 배열 내의 요소를 반환하게 하는 것입니다.
        
        2차원 배열 예제 코드 보기
        
        
        

        1. template <class T>
        2. class Array2D {
        3. public:
        4. class Array1D {
        5. public:
        6. T& operator [](int index);
        7. const T& operator [](int index) const;
        8. ...
        9. };
        11. Array1D operator [](int index);
        12. const Array1D operator [](int index) const;
        13. ...
        14. };
        15.  
        16. // 이렇게 만든 Array2D로는 이제
        17. // 다음의 코드를 쓸 수 있습니다.
        18.  
        19. Array2D<float> data(10, 20);
        20. ...
        21. cout << data[3][6]; // 오옷! 아무 문제없습니다.

        
        
        2차원 배열 예제 코드 접기
        
        
        Array2D 클래스를 쓰는 개발자는 Array1D 클래스에 대해 전혀 알 필요가 없습니다. 이렇게 또 다른 객체를 대신하는 객체를 두는 방법이 꽤 쓸모가 있어서 이런 객체에 프록시 객체(proxy object)라는 이름을, 그리고 프록시 객체를 만드는 클래스를 가리켜 프록시 클래스(proxy class)라고 부릅니다. 이번 예제의 Array1D는 프록시 클래스이고, 이 클래스의 인스턴스는 개념적으로는 존재하지 않는 1차원 배열을 대신합니다.

      • '진짜로' operator[] 의 읽기/쓰기를 구분하는 방법

        프록시 클래스는 상당히 넓은 응용폭을 자랑합니다. 프록시 클래스의 국가대표급 응용 사례는 operator[] 의 읽기/쓰기 동작을 구분하는 것입니다. 이 순간, operator[] 를 지원한 참조 카운팅 문자열이 어렴풋이 생각나려고 합니다(항목 29 를 보세요).
        
        이미 알고 계시겠지만 operator[]는 문자를 읽고, 문자를 쓰는 두 가지 상황에서 호출될 수 있습니다. 여기서 우리가 원하는 것은 operator[]가 읽기를 위해 쓰였는지 쓰기를 위해 쓰였는지를 구분하는 것입니다. 왜냐하면 우항값 연산(읽기)이 좌항값 연산(쓰기)보다 비용이 덜 들기 때문입니다. 특히 이 효과는 참조 카운팅 기능을 가진 자료구조에서 두드러집니다.
        
        기본 아이디어는 이렇습니다. operator[]의 결과값이 사용되기까지 좌항값/우항값 연산을 늦추면 읽기와 쓰기를 다르게 처리할 수 있다는 것입니다. 우리가 필요로 하는 지연 시간을 벌어주는 일이 바로 프록시 클래스의 역할입니다. 이제 operator[]는 문자열 내의 문자 자체를 반환하지 않고 문자를 대신하는 프록시 객체를 반환하도록 바뀝니다.
        
        예제 코드를 보기 전에 이 프록시를 정확하게 이해하기로 합시다. 프록시를 가지고 할 수 있는 일은 단 세 개뿐입니다.
        
        
        • 프록시를 생성합니다. 즉, 프록시가 대신할 문자열 내의 문자를 지정합니다.
        • 이 프록시를 대입 연산의 대상(target)으로 사용합니다. 이 경우는 프록시가 대신하는 문자에 대해 직접 대입 연산을 수행하는 것인데, 이렇게 사용되는 프록시는 operator[]를 호출한 문자열에 대한 좌항값을 대신한다고 할 수 있습니다.
        • 이 프록시를 이외의 경우에 사용합니다. 이렇게 사용되는 프록시는 operator[]를 호출한 문자열에 대한 우항값을 대신한다고 할 수 있습니다.
        
        예제 코드 보기
        
        
        

        1. class String { // 참조 카운팅 기능을 가진 문자열
        2. public: // 자세한 내용은 항목 29에서 공부하세요.
        4. class CharProxy { // 문자열 내의 문자(char)를 대신하는 프록시
        5. public:
        6. CharProxy(String& str, int index); // 프록시 생성
        8. CharProxy& operator =(const CharProxy& rhs); // 좌항값(lvalue)
        9. CharProxy& operator =(char c); // 연산
        11. operator char(void) const; // 우항값 연산
        13. private:
        14. String& theString; // 이 프록시가 관계한 문자열 객체
        16. int charIndex; // 이 문자열 안에서 프록시가
        17. // 직접 대신하고 있는 문자
        18. };
        20. // String 클래스의 계속
        21. const CharProxy operator [](int index) const; // 상수 String 객체를 위한 함수
        22. CharProxy operator [](int index); // 비상수 String 객체를 위한 함수
        23. ...
        24. friend class CharProxy;
        26. private:
        27. RCPtr<StringValue> value;
        28. };
        29.  
        30. // 다음 문장을 잘 봐주세요.
        31.  
        32. String s1;
        33. ...
        34. cout << s1[5];
        35.  
        36. // 이 문장에서 s1[5]는 CharProxy 객체를
        37. // 반환합니다. 이 객체에는 출력용 연산자(<<)가
        38. // 정의되어 있지 않기 때문에, C++ 컴파일러는
        39. // operator <<를 성사시키기 위해
        40. // char타입으로의 암시적 변환 함수를
        41. // 호출하도록 합니다.
        42.  
        43. // CharProxy가 우항값으로 사용될 때에는
        44. // 반드시 CharProxy에서 char로의 변환이
        45. // 이루어집니다.
        46.  
        47. // 좌항값 연산은 조금 다르게 처리됩니다.
        48. // 다음을 보세요.
        49.  
        50. String s2;
        51. ...
        52. s2[5] = 'x';
        53.  
        54. // 표현식 s2[5]가 CharProxy 객체를 반환한다는
        55. // 것은 이전의 경우와 마찬가지입니다.
        56. // 하지만 이번의 CharProxy 객체는 대입
        57. // 연산의 대상이 되는 객체입니다.
        58.  
        59. // 그렇기 때문에, 호출되는 대입 연산자는
        60. // CharProxy 안에 정의되어 있는 것이란
        61. // 사실은 확실합니다.
        62.  
        63. // 따라서 CharProxy 안에 정의된
        64. // 대입 연산자는 이 문자에 대한 좌항값
        65. // 연산을 구현하는 데에 필요한 동작을
        66. // 취하면 될 것입니다.
        67.  
        68. const String::CharProxy String::operator [](int index) const
        69. {
        70. return CharProxy(const_cast<String&>(*this), index);
        71. }
        72.  
        73. String::CharProxy String::operator [](int index)
        74. {
        75. return CharProxy(*this, index);
        76. }
        77.  
        78. // const 버전의 operator []는
        79. // 반환할 CharProxy 객체를 생성할 때
        80. // *this에 const_cast(항목 2 참조)
        81. // 를 사용하고 있습니다. 캐스트 연산자는
        82. // 골칫거리이기 쉽지만, 이런 경우에는
        83. // operator []가 반환한 CharProxy
        84. // 객체가 상수 타입이기 때문에, 이 프록시가
        85. // 나타내는 문자를 가진 String 객체가
        86. // 변경될 위험은 없습니다.
        87.  
        88. String::CharProxy::CharProxy(String& str, int index)
        89. : theString(str), charIndex(index) {}
        90.  
        91. String::CharProxy::operator char(void) const
        92. {
        93. return theString.value->data[charIndex];
        94. }
        95.  
        96. String::CharProxy& String::CharProxy::operator =(const CharProxy& rhs)
        97. {
        98. // 이 String 객체가 다른 String 객체와 값을 공유하고 있는 상태에 있다면,
        99. // 이 String 객체만 가질 수 있는 값의 사본을 따로 만듭니다.
        100. if (theString.value->isShared()) {
        101. theString.value = new StringValue(theString.value->data);
        102. }
        104. // 이제 대입합니다. rhs가 나타내는 문자값을
        105. // *this가 나타내는 문자값에 대입합니다.
        106. theString.value->data[charIndex] =
        107. rhs.theString.value->data[rhs.charIndex];
        109. return *this;
        110. }
        111.  
        112. // 문자값 대입을 위해 String의 private 멤버 데이터인
        113. // value가 직접 사용되었기 때문에, CharProxy를
        114. // String의 프렌드로 선언한 것입니다.
        115.  
        116. // 두 번째의 대입 연산자 역시 거의 비슷한 구조로 만들어져 있습니다.
        117. String::CharProxy& String::CharProxy::operator =(char c)
        118. {
        119. if (theString.value->isShared()) {
        120. theString.value = new StringValue(theString.value->data);
        121. }
        123. theString.value->data[charIndex] = c;
        125. return *this;
        126. }
        127.  
        128. // 중복된 코드를 제거하는 일은 여러분에게 맡깁니다.

        
        
        예제 코드 접기
        
        
        

      • 프록시 클래스라고 능사는 아니다

        프록시 클래스에도 단점이 있습니다. 우리에겐 프록시 객체와 프록시 객체가 대신하는 객체가 감쪽같이 자리바꿈했으면 하는 소망이 있지만, 실상은 이게 꽤 만만찮습니다. 왜냐하면, 객체가 좌항값으로 사용되는 경우는 대입 연산 외에서도 찾을 수 있고, 이런 경우에 프록시 객체를 사용하면 원래의 객체를 사용하는 것과 사뭇 다른 동작 결과를 보게 되기 때문입니다.
        
        
        • 항목 29에서 StringValue 객체에 공유 가능성 플래그를 추가할 필요성을 보여준 그 코드를 다시 가져와 보았습니다. String::operator[]가 반환하는 것이 char&가 아닌 CharProxy이면 다음의 코드는 절대로 컴파일되지 않습니다.
          
          String s1 = "Hello";
          char *p = &s1[1];
          // 에러입니다!
          
          이 난관을 극복하려면 CharProxy 클래스의 주소 연산자(address of, & 연산자)를 오버로딩할 수 밖에 없습니다.
          
          예제 코드 보기
          
          
          

          1. class String {
          2. public:
          4. class CharProxy {
          5. public:
          6. ...
          7. char* operator &(void);
          8. const char* operator &(void) const;
          9. ...
          10. };
          11. ...
          12. };
          13.  
          14. const char* String::CharProxy::operator &(void) const
          15. {
          16. return &(theString.value->data[charIndex]);
          17. }
          18.  
          19. char* String::CharProxy::operator &(void)
          20. {
          21. // 이 함수가 반환하는 포인터가 가리키는 문자가
          22. // 다른 String 객체들이 공유하는 문자열에 속해 있지 않도록 주의합니다.
          23. if (theString.value->isShared()) {
          24. theString.value = new StringValue(theString.value->data);
          25. }
          27. // 이 함수가 반환한 포인터가 언제까지 사용되는지
          28. // 알 수 없기 때문에, 이 StringValue 객체는 절대로
          29. // 공유되지 않도록 설정합니다.
          30. theString.value->markUnshareable();
          32. return &(theString.value->data[charIndex]);
          33. }
          34.  
          35. // CharProxy의 다른 멤버 함수에서
          36. // 익히 봐 왔던 코드가 대부분이기 때문에,
          37. // 역시 별도의 private 멤버 함수에 몰아
          38. // 넣고 싶은 독자가 있을 것 같네요.

          
          
          예제 코드 접기
          
          
          
        • CharProxy로 char를 대신할 수 없는 경우의 두 번째 예는 다음의 코드를 가지고 설명할까 합니다. Array는 참조 카운팅 기능을 가진 배열의 템플릿인데, operator[]의 좌항값/우항값 연산을 구분하려고 프록시 클래스를 사용했습니다.
          
          Array<int> intArray;
          ...
          intArray[5] = 22;
          // 여기까진 문제없다가
          
          intArray[5] += 5;
          // 윽, 에러입니다!
          
          ++intArray[5];
          // 또 에러입니다!
          
          원인은 간단합니다. operator []는 Proxy 객체를 반환하는데, Proxy 클래스 안에는 operator +=나 operator ++ 함수가 정의되어 있지 않으니 컴파일이 안 되는 것이죠. 이 외에도 좌항값을 필요로 하는 연산자(operator *, operator <<=, operator -- 등)에서는 이런 상황이 어김없이 발생합니다. 이런 연산자들에 대해서도 제대로 작동하게 하려면, Array<T>::Proxy 클래스 안에 이 연산자들을 정의해 넣어야 합니다.
          
          
        • 프록시를 통해 원래 객체의 멤버 함수를 호출할 때에도 비슷한 문제가 끼어 듭니다. Rational는 유리수를 나타내는 클래스 입니다. 위의 Array 템플릿에 Rational 클래스를 적용하면 다음과 같은 문제가 발생합니다.
          
          Array<Rational> array;
          // 여기까지는 좋습니다.
          
          cout << array[4].numerator();
          // 에러입니다!
          
          int denom =
          array[22].denominator();
          // 에러입니다!
          
          결국 프록시가 원래의 객체처럼 동작하게 만들려면, 원래 객체에 적용할 수 있는 함수를 모조리 오버로딩해서 프록시에도 적용될 수 있도록 해야 합니다.
          
          
        • 프록시가 원래의 객체를 대신할 수 없는 경우는 아직도 남아 있습니다. 바로 비상수 객체 참조자를 받아들이는 함수의 매개변수로 프록시를 넘기는 경우입니다.
          
          void swap(char& a, char& b);
          // a와 b의 값을 맞바꾸는 함수
          
          String s = "+C+";
          // 윽, "C++"을 잘못 썼습니다.
          
          swap(s[0], s[1]);
          // 이렇게 해서 문제를 해결했으면
          // 좋겠는데, 이 코드는 컴파일되지
          // 않습니다.
          
          
          
        • 이제 프록시 객체가 원래 객체를 대체할 수 없는 경우가 딱 하나 남았습니다. '암시적 타입변환'이 바로 마지막 경우입니다.
          
          예제 코드 보기
          
          
          

          1. class TVStation {
          2. public:
          3. TVStation(int channel);
          4. ...
          5. };
          6.  
          7. void watchTV(const TVStation& station, float hoursToWatch);
          8.  
          9. // int를 TVStation 타입으로 바꾸는
          10. // 암시적 타입변환 함수(항목 5 참조)가
          11. // 있기 때문에, 다음과 같은 코드를
          12. // 쓸 수도 있습니다.
          13.  
          14. watchTV(10, 2.5); // 2시간 30분 동안
          15. // 채널 10을 봅니다.
          16.  
          17. // 그런데 프록시 클래스로 operator []의
          18. // 좌항값/우항값 연산을 구분하고 참조 카운팅
          19. // 기능도 가진 배열 템플릿을 써서 비슷한
          20. // 코드를 쓰려고 하면 에러가 납니다.
          21.  
          22. Array<int> intArray;
          23. intArray[4] = 10;
          24. watchTV(intArray[4], 2.5); // 에러입니다! Proxy<int>를
          25. // TVStation 타입으로
          26. // 변환할 수 없습니다.
          27.  
          28. // 이 경우에 int 타입이 TVStation 타입으로
          29. // 변환되려면 다음과 같이 두 번의
          30. // 암시적 타입변환 과정이 필요합니다.
          31. // Proxy<int> -> int -> TVStation
          32.  
          33. // 하지만 C++에서는 두 번 이상의
          34. // 암시적 타입변환이 금지되어 있습니다.
          35.  
          36. // 사실, 이 경우에는 좀 더 신경써서
          37. // 설계한 TVStation 클래스였다면
          38. // 생성자를 explicit로 선언해 두었을
          39. // 것이고, 첫 번째 watchTV 호출도
          40. // 컴파일되지 않았을 것입니다.

          
          
          예제 코드 접기
          
          
          

      • 총정리

        프록시 클래스를 이용하면 어떤 특정한 동작 원리 몇 가지를 아주 쉽게 구현할 수 있습니다. 다차원 배열이 첫 번째 예이고, 좌항값/우항값 구분이 두 번째 예이며, 암시적 타입변환(항목 5 참조)의 방지가 세 번째 예입니다.
        
        이와 동시에, 프록시 클래스에는 단점도 있습니다. 함수로부터 반환되는 프록시 객체는 임시 객체(temporary, 항목 19 참조)이기 때문에, 객체 생성 및 소멸 과정이 저절로 수반되어야 합니다(비용이 듭니다). 또한 프록시 클래스를 사용한 소프트웨어 시스템은 그렇지 않은 것보다 더 복잡합니다. 클래스 몇 개가 더 추가되기 때문에 설계, 구현, 파악, 유지보수 등에 관한 작업이 어려워질 수밖에 없지요.
        
        마지막으로, 원래의 객체를 사용하는 클래스를 프록시를 사용하는 버전으로 바꿀 때에는 그 클래스의 의미구조도 어쩔 수 없이 바뀌어야 하는 경우도 더러 있습니다. 프록시 객체는 대개 원래 객체와 약간 다른 동작 패턴을 보이기 때문입니다. 하지만 프록시를 사용자에게까지 드러내는 동작이 필요한 경우는 별로 많지 않습니다.
        

  31. 함수를 두 개 이상의 객체(타입)에 대해 가상 함수처럼 동작하도록 만들기 / 313

      • 두 개 이상의 객체에 대해 가상 함수처럼 동작하는 함수가 필요한 경우의 예

        여러분은 게임을 하나 만들기로 작정했습니다. 이 게임에는 GameObject를 상속하여 구현한 SpaceShip(우주선), SpaceStation(정거장), Asteroid(소행성)가 있고, 이들끼리 충돌한 경우 다음과 같은 규칙을 따른다고 합시다.
        • 우주선과 정거장이 느린 속도로 충돌하면, 우주선은 정거장에 도킹합니다. 충돌할 때의 속도가 느리지 않았다면, 우주선과 정거장은 충돌 속도에 비례하여 손상을 입습니다.
        • 우주선과 우주선, 또는 정거장과 정거장이 충돌하면, 충돌한 것들 모두 충돌 속도에 비례하는 손상을 입습니다.
        • 작은 소행성이 우주선 또는 정거장과 충돌하면, 소행성이 부서집니다. 충돌한 소행성이 좀 큰 것이라면 우주선과 정거장이 부서집니다.
        • 한 소행성이 다른 소행성과 충돌하면, 두 소행성이 작은 소행성들로 쪼개지면서 모든 방향으로 튕겨져 나갑니다.
        
        이 게임에는 오브젝트들의 충돌을 처리하는 다음과 같은 함수가 있을 것입니다.
        
        void checkForCollision(
        GameObject& object1,
        GameObject& object2)
        {
        if (theyJustCollided(object1,
        object2))
        {
        processCollision(object1,
        object2);
        }
        else
        {
        ...
        }
        }
        
        processCollision이 호출되었을 때, 함수 안에서는 object1과 object2가 충돌되었다는 사실을 알고 있기 때문에, object1과 object2가 실제로 어떤 것이냐에 따라 적절한 충돌처리를 해 주어야 합니다. 하지만 충돌한 객체가 진짜로 무엇인지는 알 방법이 없습니다.
        
        만약 object1의 동적 타입만 보고 충돌처리를 할 수 있다면, processCollision을 GameObject 클래스의 가상 함수로 선언해 놓고 object1.processCollision(object2)을 호출하면 문제가 해결되었을 것입니다.
        
        하지만 이 경우에 충돌 처리를 제대로 하려면 object1과 object2의 동적 타입이 모두 필요합니다. 이런 경우에 필요한 것이 두 개 이상의 객체 타입에 대해 가상 함수처럼 동작하는 함수입니다.
        
        하지만 C++에는 이런 기능이 없기 때문에, 이중 디스패치(double-dispatch, 일반화 하여 여러 개의 매개변수에 대해 가상 함수처럼 동작하는 함수를 다중 디스패치(multiple dispatch)라고 한다)라고 알려진 기법을 스스로 구현해야 합니다.

      • 가상 함수와 RTTI를 사용하여 구현하는 이중 디스패치

        가상 함수는 단일 디스패치를 구현한 것이라고 생각할 수 있습니다. 목표가 이중 디스패치이니, 일단 목표의 반은 이룬 셈이죠. GameObject에다 collide라는 가상 함수를 선언하는 것으로 일을 시작합니다.
        
        첫 번째로 보여드릴 이중 디스패치 구현 방법은 가장 흔한 방법이면서도 지저분한 방법입니다. if-then-else를 줄줄이 엮어 가상 함수를 흉내내는, 용서가 안 되는 아수라장에 발을 들이는 것이기 때문입니다. 우선 otherObject의 진짜 타입을 알아낸 후에, 그 타입에 대해 생길 수 있는 모든 가능성을 조사합니다.
        
        예제 코드 보기
        
        
        

        1. // 이 예제에서는 SpaceShip 파생 클래스에 대한
        2. // 코드만 보였는데, 나머지 파생 클래스들도 똑같은 방식으로
        3. // 처리된다고 생각해 두시면 됩니다.
        4.  
        5. class GameObject {
        6. public:
        7. virtual void collide(GameObject& otherObject) = 0;
        8. ...
        9. };
        10.  
        11. class SpaceShip: public GameObject {
        12. public:
        13. virtual void collide(GameObject& otherObject);
        14. ...
        15. };
        16.  
        17. // 충돌한 객체의 타입이 전혀 모르는 타입이면,
        18. // 그 객체를 사용해서 만든 예외를 발생시킵니다.
        19. class CollisionWithUnknownObject {
        20. public:
        21. CollisionWithUnknownObject(GameObject& whatWeHit);
        22. ...
        23. };
        24.  
        25. void SpaceShip::collide(GameObject& otherObject)
        26. {
        27. const type_info& objectType = typeid(otherObject);
        29. if (objectType == typeid(SpaceShip)) {
        30. SpaceShip& ss = static_cast<SpaceShip&>(otherObject);
        32. 우주선-우주선 충돌을 처리합니다;
        33. }
        34. else if (objectType == typeid(SpaceStation)) {
        35. SpaceStation& ss =
        36. static_cast<SpaceStation&>(otherObject);
        38. 우주선-우주정거장 충돌을 처리합니다;
        39. }
        40. else if (objectType == typeid(Asteroid)) {
        41. Asteroid& a = static_cast<Asteroid&>(otherObject);
        43. 우주선-소행성 충돌을 처리합니다;
        44. }
        46. else {
        47. throw CollisionWithUnknownObject(otherObject);
        48. }
        49. }
        50.  
        51. // SpaceShip의 멤버 함수에서
        52. // *this는 SpaceShip 객체입니다.
        53. // 따라서 otherObject의 진짜(동적)
        54. // 타입만 알아내면 문제가 풀립니다.

        
        
        예제 코드 접기
        
        
        이 코드를 쓸 때부터 이미 우리는 '캡슐화'와는 안녕을 고한 셈입니다. collide 멤버 함수는 무늬만 멤버 함수이지, 해당 클래스의 형제(sibling) 클래스, 즉 GameObject에서 파생된 클래스를 모두 알고 있어야 합니다. 이게 나쁜 이유는 새로운 형제 클래스가 추가되었을때 if-then-else 끄나풀에 새로 추가된 객체 타입을 반영해야 하기 때문입니다.
        
        코드를 우겨 넣고 기존의 코드를 많이 바꾸어야 하기 때문에 상당한 타이핑 중노동이 뒤따를 것은 물론이고, 타입 하나를 빠뜨리기라도 하면 버그가 생길 수도 있습니다. 이런 버그는 찾기도 힘들고, 컴파일러가 잡아낼수도 없습니다.

      • 가상 함수만 사용하여 구현하는 이중 디스패치

        '가상 함수만 쓰는 방법'은 RTTI 방법과 똑같은 기본 골격으로 시작합니다. collide 함수는 GameObject 클래스에서 가상 함수로 선언되고 각 파생 클래스에서 재정의됩니다. 덧붓여, collide는 각 파생 클래스에서 오버로딩되는데, 이 함수는 클래스 계통 구조의 모든 파생 클래스 타입에 대해 오버로딩되어 있습니다.
        
        이 방법의 기본 아이디어는 이중 디스패치를 단일 디스패치 두 개로 구현하자는 것입니다. 즉, 독립된 가상 함수 두 개를 호출하자는 말입니다.
        
        예제 코드 보기
        
        
        

        1. class SpaceShip;
        2. class SpaceStation;
        3. class Asteroid;
        4.  
        5. class GameObject {
        6. public:
        7. virtual void collide(GameObject& otherObject) = 0;
        8. virtual void collide(SpaceShip& otherObject) = 0;
        9. virtual void collide(SpaceStation& otherObject) = 0;
        10. virtual void collide(Asteroid& otherObject) = 0;
        11. ...
        12. };
        13.  
        14. class SpaceShip: public GameObject {
        15. public:
        16. virtual void collide(GameObject& otherObject);
        17. virtual void collide(SpaceShip& otherObject);
        18. virtual void collide(SpaceStation& otherObject);
        19. virtual void collide(Asteroid& otherObject);
        20. ...
        21. };
        22.  
        23. void SpaceShip::collide(GameObject& otherObject)
        24. {
        25. otherObject.collide(*this);
        26. }
        27.  
        28. // 언뜻 보기에는 매개변수가 뒤바뀐 재귀함수 호출로밖에
        29. // 보이지 않습니다. 그러나 컴파일러는 자신이 호출할
        30. // 함수를 결정할 때 함수에 넘겨진 인자의 정적 타입
        31. // 을 보고 결정합니다.
        32.  
        33. // 이 경우 SpaceShip 클래스의 멤버 함수 안으로
        34. // 들어왔으니, *this의 정적 타입은 SpaceShip입니다.
        35. // 따라서, otherObject에서는 SpaceShip& 타입을
        36. // 받는 collide 함수가 호출되는 것입니다.
        37. // GameObject&를 받는 collide 함수가 아닙니다.
        38.  
        39. void SpaceShip::collide(SpaceShip& otherObject)
        40. {
        41. 우주선-우주선 충돌을 처리합니다;
        42. }
        43.  
        44. void SpaceShip::collide(SpaceStation& otherObject)
        45. {
        46. 우주선-우주 정거장 충돌을 처리합니다;
        47. }
        48.  
        49. void SpaceShip::collide(Asteroid& otherObject)
        50. {
        51. 우주선-소행성 충돌을 처리합니다;
        52. }

        
        
        예제 코드 접기
        
        
        가상 함수만 쓴 방법의 치명적 단점은, 이 방법 역시 모든 클래스가 다른 형제 클래스에 대해 알고 있어야 한다는 전제 조건이 필요하다는 것입니다. 하지만 업데이트 방법이 약간 다릅니다. if-then-else 사슬을 고치는 일은 아니지만, 더 나쁜 영향을 끼칠 수 있다는 것이 문제입니다. 클래스에 새 가상 함수를 정의해 넣어야 하기 때문입니다.
        
        기존의 클래스를 고치는 일은 여러분이 손댈 수 없는 부분일 때가 많습니다. GameObject가 라이브러리에 있는 클래스라면, 건드릴 수 없습니다. 설령 여러분이 사용하는 툴킷이 사용자 수정이 가능하게 만들어져 있다 해도, 실제적으로 수정하기는 쉽지 않습니다.
        
        예를 들어 개발 팀원들이 GameObject와 기타 자질구레한 클래스로 이루어진 라이브러리를 사용한다고 가정합시다. 이 라이브러리를 사용하는 사람이 한둘이 아니기 때문에, 여러분이 새로운 형태의 객체를 게임 프로그램에 추가할 때마다 이 라이브러리를 사용하는 모든 프로그램을 다시 컴파일해야 할 것입니다.
        
        요컨데 이 방법은 RTTI를 쓰는 방법보다는 안전하지만, 헤더 파일을 고치는 등의 시스템 확장에는 제약이 따른다는 단점이 있습니다. 한편, RTTI 방법을 쓰면 이후의 재컴파일 작업이 필요하진 않으나 일반적으로 프로그램의 유지보수가 불가능해집니다.

      • 가상 함수 테이블의 유사구현(emulation)을 통한 이중 디스패치

        이제는 앞의 두 가지 방법을 개선할 수 있는 방법을 찾아보도록 합시다. 컴파일러는 함수 포인터의 배열(vtbl)로 C++의 가상 함수 호출장치를 만들어 놓고, 가상 함수가 호출될 때 그 배열을 인덱싱합니다(항목 24를 보세요).
        
        항목 24에서는 힘들다고 설레발을 쳤지만, 가상 함수 메커니즘을 여러분 스스로 구현하지 못할 이유는 없습니다. RTTI 기반의 코드를 더욱 효율적으로 만들고, 한 곳(함수 포인터 배열이 초기화되는 부분)에서만 RTTI를 사용하도록 할 것입니다.
        
        예제 코드 보기
        
        
        

        1. class GameObject {
        2. public:
        3. virtual void collide(GameObject& otherObject) = 0;
        4. ...
        5. };
        6.  
        7. class SpaceShip: public GameObject {
        8. public:
        9. virtual void collide(GameObject& otherObject);
        10. virtual void hitSpaceShip(SpaceShip& otherObject);
        11. virtual void hitSpaceStation(SpaceStation& otherObject);
        12. virtual void hitAsteroid(Asteroid& otherObject);
        13. ...
        14. };
        15.  
        16. void SpaceShip::hitSpaceShip(SpaceShip& otherObject)
        17. {
        18. 우주선-우주선 충돌을 처리합니다;
        19. }
        20.  
        21. void SpaceShip::hitSpaceStation(SpaceStation& otherObject)
        22. {
        23. 우주선-정거장 충돌을 처리합니다;
        24. }
        25.  
        26. void SpaceShip::hitAsteroid(Asteroid& otherObject)
        27. {
        28. 우주선-소행성 충돌을 처리합니다;
        29. }
        30.  
        31. // GameObject 클래스에 충돌 처리용 함수가
        32. // 하나밖에 들어 있지 않습니다. 이 함수는
        33. // 두 번의 함수 디스패치 중 첫 번째
        34. // 디스패치를 맡습니다.
        35.  
        36. // 또한, RTTI 방법 뒤에 나왔던
        37. // 가상 함수 방법과 마찬가지로 충돌하는
        38. // 객체들의 상호작용은 별도의 함수에서
        39. // 처리되는데, 각자 별도의 이름을
        40. // 가지고 있습니다. 오버로딩을 피한
        41. // 이유는 곧 확인하게 될 것입니다.
        42.  
        43. // SpaceShip::collide는 hitXXX 함수
        44. // 들이 호출되는 시작 위치입니다.
        45.  
        46. // SpaceShip::collide 함수 안에는,
        47. // 클래스 이름과, 멤버 함수 포인터를
        48. // 짝으로 묶는 일종의 연관 자료구조를
        49. // 만들어 두는 것이 쉬운 방법일 것
        50. // 같습니다.
        51.  
        52. // 그리고 collide가 이 연관 자료구조에
        53. // 직접 액세스하기보다는, 대신 액세스해주는
        54. // 함수를 하나 만들고 collide가 이 함수를
        55. // 호출하는 편이 이해하기 좋을 것입니다.
        56.  
        57. // 이 함수의 이름을 lookup이라고 합시다.
        58. // 이 함수는 GameObject&를 받아,
        59. // 그 객체의 진짜 타입에 맞는 멤버 함수
        60. // 포인터를 반환합니다.
        61.  
        62. class SpaceShip: public GameObject {
        63. private:
        64. typedef void (SpaceShip::*HitFunctionPtr)(GameObject&);
        65. static HitFunctionPtr lookup(const GameObject& whatWeHit);
        66. ...
        67. };
        68.  
        69. void SpaceShip::collide(GameObject& otherObject)
        70. {
        71. HitFunctionPtr hfp =
        72. lookup(otherObject);
        73. if (hfp) {
        74. (this->*hfp)(otherObject);
        75. }
        76. else {
        77. throw CollisionWithUnknownObject(otherObject);
        78. }
        79. }
        80.  
        81. // 이제 lookup이 어떻게 생겨먹었는지만
        82. // 보면 될 것입니다.
        83.  
        84. // lookup에 사용될 연관 자료구조는
        85. // 자신이 사용되기 전에 생성과 초기화가
        86. // 완료되어야 하고, 더 사용되지 않을
        87. // 때 소멸되어야 합니다.
        88.  
        89. // new와 delete를 쓰기보다는,
        90. // 컴파일러가 자동으로 해 주는 것이
        91. // 오류를 막기 쉽습니다.
        92.  
        93. // 그래서 이 연관 자료구조를 lookup의
        94. // 정적 데이터로 선언하는 것입니다.
        95.  
        96. class SpaceShip: public GameObject {
        97. private:
        98. typedef void (SpaceShip::*HitFunctionPtr)(GameObject&);
        99. typedef std::map<std::string, HitFunctionPtr> HitMap;
        100. ...
        101. };
        102.  
        103. SpaceShip::HitFunctionPtr
        104. SpaceShip::lookup(const GameObject& whatWeHit)
        105. {
        106. static HitMap collisionMap; // 이 연관 자료구조(맵)의
        107. // 초기화는 나중에 설명합니다.
        108.  
        109. // whatWeHit의 타입에 맞는 충돌처리 함수를 찾습니다.
        110. // 반환값은 "반복자(iterator)"라고 불리는
        111. // 포인터 비슷한 객체입니다(항목 35를 보세요).
        112. HitMap::iterator mapEntry =
        113. collisionMap.find(typeid(whatWeHit).name());
        115. // 탐색이 실패하면 mapEntry == collisionMap.end() 입니다;
        116. // 이것은 map의 표준적인 동작방식입니다. 역시 항목 35를 참고하십시오.
        117. if (mapEntry == collisionMap.end()) return 0;
        119. // 이 부분으로 들어왔다면 탐색이 성공한 것입니다.
        120. // mapEntry는 map에 저장되는 실제 엔트리를 가리키는데,
        121. // 이 엔트리의 타입은 string과 HitFunctionPtr를 묶은 pair입니다.
        122. // 지금은 이 페어의 두 번째(second) 부분만 필요합니다.
        123. return (*mapEntry).second;
        124. }
        125.  
        126. // 이 함수의 마지막 문장에서 맵 엔트리의 둘째 멤버를 반환할 때
        127. // mapEntry->second 대신에 (*mapEntry).second를 쓴 이유는
        128. // 아직 안정화되지 않은 STL을 사용하는 경우를 감안했기 때문입니다.
        129.  
        130. // C++ 표준에는 type_info::name의 반환값을 확실히 지정해 놓지
        131. // 않았기 때문에, 이 함수의 동작은 C++ 컴파일러마다 다르게
        132. // 구현되어 있습니다.
        133.  
        134. // 이 코드를 좀 더 안전하게 설계하려면 type_info 객체의 주소를
        135. // 가지고 클래스를 식별하도록 고치는 것이 좋습니다. 왜냐하면
        136. // type_info 객체의 주소는 유일하기 때문입니다.
        137.  
        138. // 이 경우 HitMap은 map<const type_info*, HitFunctionPtr>으로
        139. // 선언되어야 합니다.

        
        
        예제 코드 접기
        
        
        

      • 유사 가상 함수 테이블의 초기화

        어찌 하다보니 이제 collisionMap의 초기화를 해야하는 때가 되었습니다. collisionMap이 생성될 때 딱 한 번만 초기화를 하려면, 별도의 정적 멤버 함수를 두어 여기서 맵을 생성하고 초기화하도록 하면 됩니다. 그래서 이런 일을 하는 initializeCollisionMap이란 함수를 따로 만들었습니다. 이 함수의 반환값은 collisionMap을 초기화하는 데 쓰입니다.
        
        하지만 initializeCollisionMap에서 반환된 객체가 collisionMap으로 복사된다는 점이 마음에 걸립니다(항목 19와 20을 참고하세요). 포인터를 반환하면 복사 비용을 물지 않지만, 적절한 시기를 보아 우리가 직접 소멸시켜야 하는 문제가 있습니다. 이런 고민들은 스마트 포인터(항목 28 참조)를 사용하여 일거에 없앨 수 있습니다. lookup 함수 안에 선언된 collisionMap의 타입을 정적 auto_ptr로 바꾸고, initializeCollisionMap에서는 초기화된 map 객체의 포인터를 반환하게 합시다.
        
        아직 문제는 남아 있습니다. collisionMap은, string와 HitFunctionPtr를 묶은 pair인데 HitFunctionPtr은 인자 타입이 GameObject&인 함수 포인터 입니다. 그런데 hitXXX 함수들의 인자 타입은 파생 클래스 타입의 참조자입니다. 따라서 hitXXX함수의 포인터를 collisionMap에 담을 수 없는 문제가 생깁니다.
        
        당장에 어떻게든 컴파일이 되게 하려고 reinterpret_cast(항목 2 참조)를 써서 함수 포인터 타입을 캐스팅 하는 방법을 떠올릴 수 있겠으나, 만약에 GameObject의 파생 클래스들이 다중 상속으로 만들어졌다거나 가상 기본 클래스를 가지고 있으면, 함수 포인터를 통해 함수가 호출되는 부분에서 심각한 런타임 에러가 발생할 것입니다. 왜냐하면 다중 상속으로 만들어졌거나 가상 기본 클래스를 가지고 있는 경우, 하나의 객체가 어떤 타입으로 해석되냐에 따라 포인터의 값(주소)이 다를 수 있기 때문입니다(항목 24 참조).
        
        이것을 해결할 방법은 단 하나입니다. hitSpaceShip, hitSpaceStation, hitAsteroid 함수가 모두 GameObject를 인자로 받아들이도록 타입을 바꾸는 것입니다. 이번 방법에서 함수 오버로딩을 피했던 이유가 바로 hitXXX 함수가 받는 매개변수 타입을 모두 똑같게(GameObject&) 하기 위해서 였습니다.
        
        애석하게도, hitXXX 계열의 모든 함수가 받는 매개변수의 타입이 GameObject라는 일반 타입으로 바뀌었지만, hitXXX 함수는 여전히 자신들이 요구했던 객체 타입을 가지고 동작해야 합니다. 따라서 dynamic_cast의 힘을 빌어와야 하겠습니다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 잘못 구현된 코드
        3. SpaceShip::HitFunctionPtr
        4. SpaceShip::lookup(const GameObject& whatWeHit)
        5. {
        6. static HitMap collisionMap;
        8. // 함수가 호출될 때 마다 초기화 됩니다.
        9. collisionMap["SpaceShip"] = &hitSpaceShip;
        10. collisionMap["SpaceStation"] = &hitSpaceStation;
        11. collisionMap["Asteroid"] = &hitAsteroid;
        12. ...
        13. }
        14.  
        15.  
        16. //-----------------------------------------------------------------------------
        17. class SpaceShip: public GameObject {
        18. private:
        19. static HitMap* initializeCollisionMap(void);
        20. ...
        21. };
        22.  
        23. SpaceShip::HitFunctionPtr
        24. SpaceShip::lookup(const GameObject& whatWeHit)
        25. {
        26. static auto_ptr<HitMap> collisionMap(initializeCollisionMap());
        27. ...
        28. }
        29.  
        30. SpaceShip::HitMap* SpaceShip::initializeCollisionMap(void)
        31. {
        32. HitMap *phm = new HitMap;
        34. (*phm)["SpaceShip"] = &hitSpaceShip;
        35. (*phm)["SpaceStation"] = &hitSpaceStation;
        36. (*phm)["Asteroid"] = &hitAsteroid;
        38. return phm;
        39. }
        40.  
        41. class GameObject { // 이 부분은 안 바뀝니다.
        42. public:
        43. virtual void collide(GameObject& otherObject) = 0;
        44. ...
        45. };
        46.  
        47. class SpaceShip: public GameObject {
        48. public:
        49. virtual void collide(GameObject& otherObject);
        51. // 이제 이 함수들은 모두 GameObject 매개변수를 취합니다.
        52. virtual void hitSpaceShip(GameObject& spaceShip);
        53. virtual void hitSpaceStation(GameObject& spaceStation);
        54. virtual void hitAsteroid(GameObject& asteroid);
        55. ...
        56. };
        57.  
        58. void SpaceShip::hitSpaceShip(GameObject& spaceShip)
        59. {
        60. SpaceShip& otherShip = dynamic_cast<SpaceShip&>(spaceShip);
        62. 우주선-우주선 충돌을 처리합니다;
        63. }
        64.  
        65. void SpaceShip::hitSpaceStation(GameObject& spaceStation)
        66. {
        67. SpaceStation& station = dynamic_cast<SpaceStation&>(spaceStation);
        69. 우주선-우주정거장 충돌을 처리합니다;
        70. }
        71.  
        72. void SpaceShip::hitAsteroid(GameObject& asteroid)
        73. {
        74. Asteroid& theAsteroid = dynamic_cast<Asteroid&>(asteroid);
        76. 우주선-소행성 충돌을 처리합니다;
        77. }
        78.  
        79. // dynamic_cast 연산자는 다운 캐스팅이 실패하면
        80. // bad_cast 예외를 발생합니다. 물론 다운 캐스팅은
        81. // 절대로 실패해선 안 됩니다. 여기서 가정하지 않은
        82. // 매개변수 타입에 대해 hitXXX 함수가 호출되면
        83. // 안 되니까요.

        
        
        예제 코드 접기
        
        
        

      • 충돌처리 함수를 클래스 멤버로 넣지 않고 구현하는 이중 디스패치

        클래스 이름과 함수 포인터를 묶어서 관리하는 연관 자료구조(맵)로 구현한, 유사 가상 함수 테이블이 '멤버 함수에 대한 포인터'를 관리한다는 점은 왠지 모를 껄끄러움을 우리에게 선사하고 있습니다. 왜냐하면, GameObject의 새로운 파생 클래스가 게임에 추가되기라도 하면, 여전히 클래스 정의를 수정해야 하기 때문입니다. 이렇게 되면 새로운 클래스에 대해 관심이 없는 개발자라도 재컴파일을 피할 수 없습니다. 이 문제는 가상 함수만 써서 이중 디스패치를 구현하는 방법의 문제와 똑같습니다.
        
        이것을 해결하기 위해 충돌처리 함수를 GameObject 클래스 계통 구조에서 분리하고, hitXXX 함수나 collide 함수를 비멤버 함수로 만드는 방법을 사용할 수 있습니다.
        
        예제 코드 보기
        
        
        

        1. #include "SpaceShip.h"
        2. #include "SpaceStation.h"
        3. #include "Asteroid.h"
        4.  
        5. namespace { // 이름 없는 네임스페이스 - 다음을 보세요.
        6. // 기본적인 충돌 처리 함수
        7. void shipAsteroid(GameObject& spaceShip,
        8. GameObject& asteroid);
        9.  
        10. void shipStation(GameObject& spaceShip,
        11. GameObject& spaceStation);
        13. void asteroidStation(GameObject& asteroid,
        14. GameObject& spaceStation);
        15. ...
        16. // 매개변수 타입이 뒤바뀌었을 때를 감안하여 만든
        17. // 부수의 충돌처리 함수. 매개변수를 다시 뒤바꾸어
        18. // 기본 충돌처리 함수를 호출합니다.
        19. void asteroidShip(GameObject& asteroid,
        20. GameObject& spaceShip)
        21. { shipAsteroid(spaceShip, asteroid); }
        23. void stationShip(GameObject& spaceStation,
        24. GameObject& spaceShip)
        25. { shipStation(spaceShip, spaceStation); }
        27. void stationAsteroid(GameObject& spaceStation,
        28. GameObject& asteroid)
        29. { asteroidStation(asteroid, spaceStation); }
        30. ...
        31. // 이 타입과 함수에 대한 설명은 다음에서 읽을 수 있습니다.
        32. typedef void (*HitFunctionPtr)(GameObject&, GameObject&);
        33. typedef map<pair<string, string>, HitFunctionPtr> HitMap;
        35. pair<string, string> makeStringPair(const char *s1,
        36. const char *s2);
        38. HitMap * initializeCollisionMap(void);
        40. HitFunctionPtr lookup(const string& class1,
        41. const string& class2);
        42. } // 네임스페이스 끝
        43.  
        44. void processCollision(GameObject& object1,
        45. GameObject& object2)
        46. {
        47. HitFunctionPtr phf = lookup(typeid(object1).name(),
        48. typeid(object2).name());
        50. if (phf) phf(object1, object2);
        51. else throw UnknownCollision(object1, object2);
        52. }
        53.  
        54. // 이름 없는 네임스페이스의 안에 있는
        55. // 모든 것들은 현재의 컴파일 단위
        56. // (즉, 현재의 파일)에서만 의미를
        57. // 가지고, 외부에서는 볼 수 없게
        58. // 됩니다.
        59.  
        60. // 말하자면, 함수 앞에 static을 붙여
        61. // 정적 함수로 선언한 것과 똑같은
        62. // 효과를 갖는 것이죠.
        63.  
        64. // 네임스페이스가 도입되면서 파일 범위
        65. // 에서의 정적 변수/함수 선언은
        66. // 폐기되었습니다.
        67.  
        68. // 기존과 달라진 점이 몇 가지 있습니다.
        69.  
        70. // 첫째, HitFunctionPtr이 비멤버 함수
        71. // 포인터의 typedef로 바뀌었습니다.
        72.  
        73. // 둘째, 예외 클래스인 CollisionWithUnknownObject가
        74. // UnknownCollision으로 이름이 바뀌고,
        75. // 두 개의 객체를 받아들이게 되었습니다.
        76.  
        77. // 마지막으로, lookup 함수는 이제
        78. // 두 개의 타입 이름을 받아 두 단계의
        79. // 이중 디스패치를 한꺼번에 수행합니다.
        80. // 즉, 이제 연관 자료구조에서 세 개의
        81. // 정보(두 개의 타입 이름과 한 개의
        82. // HitFunctionPtr)를 관리해야 합니다.
        83.  
        84. // 이 함수는 char* 리터럴을 받아 pair<string, string>
        85. // 을 만드는데 사용하고, 실제로 initializeCollisionMap에서
        86. // 사용됩니다. 이 함수에서 어떻게 반환값 초기화
        87. // (RVO, 항목 20을 보세요)를 가능하게 했는지 눈여겨 보세요.
        88.  
        89. namespace { // 이름 없는 네임스페이스 재출현 - 다음을 보세요.
        90. pair<string, string> makeStringPair(const char *s1,
        91. const char *s2)
        92. { return pair<string, string>(s1, s2); }
        93. } // 네임스페이스의 끝
        94.  
        95. namespace { // 이름 없는 네임스페이스 거듭 출현 - 다음을 보세요.
        96. HitMap *initializeCollisionMap(void)
        97. {
        98. HitMap *phm = new HitMap;
        99. (*phm)[makeStringPair("SpaceShip", "Asteroid")] =
        100. &shipAsteroid;
        102. (*phm)[makeStringPair("SpaceShip", "SpaceStation")] =
        103. &shipStation;
        104. ...
        105. return phm;
        106. }
        107. } // 네임스페이스의 끝
        108.  
        109. // lookup 함수 역시 바뀌어야 합니다.
        110. namespace { // 맹세코 다음에서 설명합니다. - 이 사람 믿어 주세요.
        111. HitFunctionPtr lookup(const string& class1,
        112. const string& class2)
        113. {
        114. static auto_ptr<HitMap>
        115. collisionMap(initializeCollisionMap());
        117. // make_pair의 설명은 다음에서 확인하세요.
        118. HitMap::iterator mapEntry =
        119. collisionMap->find(make_pair(class1, class2));
        121. if (mapEntry == collisionMap->end()) return 0;
        122. return (*mapEntry).second;
        123. }
        124. } // 네임스페이스의 끝
        125.  
        126. // make_pair는 페어 객체를 생성할 때
        127. // 타입을 일일히 지정해 줄 필요가 없도록
        128. // 만들어진 함수(템플릿)로서, 표준 라이브러리
        129. // (항목 35 참조)에 들어 있습니다.
        130.  
        131. // 즉 다음 두 문장은 똑같은 역할을
        132. // 수행합니다.
        133.  
        134. HitMap::iterator mapEntry =
        135. collisionMap->find(make_pair(class1, class2));
        136.  
        137. HitMap::iterator mapEntry =
        138. collisionMap->find(pair<string, string>(class1, class2));
        139.  
        140. // makeStringPair, initializeCollisionMap, lookup 함수는
        141. // 모두 이름 없는 네임스페이스 안에 선언되어 있습니다.
        142. // 그렇기 때문에 이 함수들은 동일한 네임스페이스
        143. // 안에서 구현(정의)되어야 합니다.
        144.  
        145. // 앞의 함수들에 대한 구현 코드가 이름 없는
        146. // 네임스페이스(즉, 함수가 선언된 컴파일 단위(파일)
        147. // 와 똑같은 컴파일 단위에 대해)에 들어 있는
        148. // 이유도 그 때문입니다.

        
        
        예제 코드 접기
        
        
        이제는 GameObject에서 새로 파생된 클래스가 클래스 계통 구조에 추가되더라도 이미 만들어진 클래스를 다시 컴파일할 필요가 없습니다. initializeCollisionMap에서 맵 정보를 추가하고, processCollision이 구현된 파일에다 추가된 클래스에 대한 충돌처리 함수를 새로 만들어 넣기만 하면 됩니다.

      • 클래스 상속이 유사 가상 함수 테이블에 끼치는 영향

        아직도 해결해야 할 마지막 문제가 남아 있습니다. 우리가 만든 이중 디스패치 장치는 충돌 처리 함수를 호출할 때 상속 기반의 타입변환을 허용하지 않으면 문제 없이 잘 동작합니다.
        
        예를 들어 볼까요? 우주선(SpaceShip)을 상업용 우주선(CommercialShip)과 군사용 우주선(MilitaryShip)으로 구분할 필요가 생겼습니다. 항목 33의 가이드라인을 준수해서 SpaceShip을 추상 클래스로 바꾸고 CommercialShip과 MilitaryShip이 이 SpaceShip 클래스에서 파생되도록 했습니다.
        
        상업용 우주선과 군사용 우주선은 충돌할 때의 행동패턴이 똑같다고 가정합시다. 이렇게 하면, 이 두 클래스에 대한 충돌처리 함수로는 이전의 SpaceShip에 썼던 그 함수가 쓰일 수 있을 것 같습니다. 이를테면, MilitaryShip 객체와 Asteroid 객체가 충돌할 때,
        
        void shipAsteroid(
        GameObject& spaceShip,
        GameObject& asteroid);
        
        이 함수가 호출될 것으로 생각할 수 있다는 것이죠. 하지만, 이 함수는 호출되지 않고 UnknownCollision 예외가 발생됩니다.
        
        이유는 이렇습니다. lookup함수에서는 "MilitaryShip"과 "Asteroid"란 타입 이름에 대응되는 함수를 찾아야 하는데, 불행하게도 "MilitaryShip"은 collisionMap의 엔트리로 입력되어 있지 않습니다. MilitaryShip이 SpaceShip와 같은 종류로 취급될 수 있다고 하지만, lookup은 그것을 알 턱이 없습니다.
        
        게다가 lookup에게 그것을 알려 주는 것이 쉬운 것도 아닙니다. 그래서 이중 디스패치를 구현해야 하고 이런 식의 상속 기반 매개변수 변환을 지원해야 한다면, 앞에서 공부했던 이중 가상 함수 호출 메커니즘을 이용해야 합니다. 물론 이 방법을 쓰면 클래스 상속 계통 구조가 바뀔 때마다 프로그램을 재컴파일하는 고통을 감내하셔야 합니다.

      • 유사 가상 함수 테이블의 초기화(제 2탄)

        collisionMap을 초기화 하는 방법에 대해서 조금만 더 말씀드리려고 합니다. 이번 항목에서 설계한 유사 가상 함수 테이블 메커니즘은 모든 것이 정적(static)입니다. 하지만 게임이 진행되면서 충돌처리 함수가 추가될 수도 있고, 제거될 수도 있고, 바뀔 수도 있는 것 아니겠습니까? 지금의 유사 가상 함수 테이블엔 그런 기능이 없습니다.
        
        그런 기능이 없는 것은 만들지 않았기 때문입니다. 단순히 충돌처리 함수를 저장하는 맵의 개념을, 동적으로 맵의 내용을 수정하는 멤버 함수를 제공하는 클래스로 바꾸어 해결할 수 있습니다.
        
        예제 코드 보기
        
        
        

        1. class CollisionMap {
        2. public:
        3. typedef void (*HitFunctionPtr)(GameObject&, GameObject&);
        5. void addEntry(const string& type1,
        6. const string& type2,
        7. HitFunctionPtr collisionFunction,
        8. bool symmetric = true); // 다음을 보세요.
        10. void removeEntry(const string& type1,
        11. const string& type2);
        13. HitFunctionPtr lookup(const string& type1,
        14. const string& type2);
        16. // 이 함수는 유일한 단 하나의 맵에 대한 참조자를
        17. // 반환합니다. 항목 26을 참고하세요.
        18. static CollisionMap& theCollisionMap(void);
        20. private:
        21. // 여러 개의 맵이 생기지 않도록 이 함수를 private 영역에
        22. // 넣습니다. 역시 항목 26을 참고하세요.
        23. CollisionMap(void);
        24. CollisionMap(const CollisionMap&);
        25. };
        26.  
        27. // 현재의 시스템에는 맵이 하나만 있기 때문에
        28. // CollisionMap 객체의 개수를 하나로 제한했습니다.
        29.  
        30. // 마지막으로, addEntry가 호출될 때 넘겨지는
        31. // symmetric 인자를 통해, 타입이 뒤바뀐
        32. // 맵 엔트리를 자동으로 추가할 수 있는 옵션을
        33. // 만들었습니다.
        34.  
        35. // 이제는 이렇게 맵 엔트리를 추가할 수 있게 됩니다.
        36.  
        37. void shipAsteroid(GameObject& spaceShip,
        38. GameObject& asteroid);
        39. CollisionMap::theCollisionMap().addEntry("SpaceShip",
        40. "Asteroid",
        41. &shipAsteroid);
        42.  
        43. void shipStation(GameObject& spaceShip,
        44. GameObject& spaceStation);
        45. CollisionMap::theCollisionMap().addEntry("SpaceShip",
        46. "SpaceStation",
        47. &shipStation);
        48.  
        49. void asteroidStation(GameObject& asteroid,
        50. GameObject& spaceStation);
        51. CollisionMap::theCollisionMap().addEntry("Asteroid",
        52. "SpaceStation",
        53. &asteroidStation);
        54. ...
        55.  
        56. // 여기서 주의할 부분은, 어떤 충돌이 일어나
        57. // 충돌처리 함수를 호출하는 일이 벌어지기 전에
        58. // 맵 엔트리를 모두 추가할 수 있도록 해야
        59. // 한다는 것입니다.
        60.  
        61. // 조금 괜찮은 방법으로 '타입 이름 - 충돌 함수'
        62. // 매핑을 담당하는 장치를 따로 만드는 것입니다.
        63.  
        64. class RegisterCollisionFunction {
        65. public:
        66. RegisterCollisionFunction(
        67. const string& type1,
        68. const string& type2,
        69. CollisionMap::HitFunctionPtr collisionFunction,
        70. bool symmetric = true)
        71. {
        72. CollisionMap::theCollisionMap().addEntry(type1, type2,
        73. collisionFunction,
        74. symmetric);
        75. }
        76. };
        77.  
        78. // 이 타입의 객체는 전역 객체로 띄워 사용합니다.
        79. // 이 클래스의 객체가 전역 메모리에 올라오는 동시에
        80. // 필요한 함수가 자동으로 등록됩니다.
        81.  
        82. RegisterCollisionFunction cf1("SpaceShip", "Asteroid",
        83. &shipAsteroid);
        84.  
        85. RegisterCollisionFunction cf2("SpaceShip", "SpaceStation",
        86. &shipStation);
        87.  
        88. RegisterCollisionFunction cf3("Asteroid", "SpaceStation",
        89. &asteroidStation);
        90. ...
        91. int main(int argc, char * argv[])
        92. {
        93. ...
        94. }
        95.  
        96. // 만약, 이후에 어떤 클래스가 새로 추가되었다고 하면,
        97. // 그리고 이 클래스에 대한 충돌처리 함수가 새로 만들어졌다고 하면,
        98.  
        99. class Satellite: public GameObject { ... };
        100.  
        101. void satelliteShip(GameObject& satellite,
        102. GameObject& spaceShip);
        103.  
        104. void satelliteAsteroid(GameObject& satellite,
        105. GameObject& asteroid);
        106.  
        107. // 기존의 코드를 흔들지 않은 채로, 비슷하게
        108. // 새 함수를 맵에 추가하면 됩니다.
        109.  
        110. RegisterCollisionFunction cf4("Satellite", "SpaceShip",
        111. &satelliteShip);
        112. RegisterCollisionFunction cf5("Satellite", "Asteroid",
        113. &satelliteAsteroid);
        114.  
        115. // 프로그래밍이 조금 더 세련되어 지긴 했지만
        116. // '다중 디스패치를 완벽하게 구현하는 방법은 없다'
        117. // 라는 사실은 바뀌지 않습니다.

        
        
        예제 코드 접기
        
        
        

• Chapter 6   이외의 이야기들(Miscellany)

  32. 미래 지향적인 프로그래머가 되자 / 343

      • 훌륭한 소프트웨어는 변화에 잘 적응합니다. 새로운 기능을 수용할 수 있고, 다른 플랫폼으로도 잘 이식되고, 시대의 요구에 잘 부응하며, 새로운 입력 데이터를 처리할 수 있습니다.

        이런 유연성, 견고성, 신뢰성을 갖춘 소프트웨어는 신이 내리는 것이 아닙니다. 이러한(변화를 품위 있게 받아들이는) 소프트웨어는 미래 지향적인 개발자가 만듭니다.

      • 미래 지향적인 프로그래밍이란, 변화를 받아들이고 변화에 대비하는 것입니다.

        이렇게 하는 한 가지 방법은 설계 제약을 나타내는 데에 있어서 주석문이나 다른 문서화 대신(혹은 이것들을 포함해서) C++의 특징을 사용하는 것입니다.
        
        예를 들어, 어떤 클래스가 (설계적으로) 절대로 파생되지 않는 클래스라면 그 클래스에 대한 헤더 파일에는 주석문을 넣지 말고 C++의 특성을 써서 아예 파생을 못하게 막아버리세요(항목 26 참조).
        
        어떤 클래스는 반드시 힙에 인스턴스가 생성되어야 한다면, 사용자에게 문서로 알리지 말고 진짜로 힙에만 만들어지도록 하는 장치를 만들어 두라 이겁니다(항목 27 참조).
        
        복사나 대입이 불필요한 클래스의 경우에는, 복사 생성자와 대입 연산자를 private로 선언하여 복사나 대입을 막습니다.
        
        C++는 엄청난 강력함과 유연성, 표현력을 가지고 있습니다. C++의 언어적 특성을 통해 여러분의 설계 의도를 반영에 두는 것이 최상입니다.

      • "사용해 줄 사람을 기다리는(demand-paged)" 가상 함수를 만들지 마십시오. 누군가 와서 그렇게 하라고 하기 전에는 멀쩡한 함수를 가상 함수로 만들지 말라는 뜻 입니다.

        어떤 함수를 만들 때마다 그 함수가 파생 클래스에서 재정의될 가치가 있는지를 결정하도록 하세요. 확신이 선다면, 아무도 그 함수를 재정의하지 않더라도 그 함수를 가상 함수로 만들어도 됩니다. 확신이 서지 않으면, 그 함수를 비가상 함수로 선언하고, 그 이후에는 가상 함수로 만들라는 잔소리가 들린다고 해서 바꾸면 안됩니다.
        
        항상 그 변화는 전체 클래스와 그 클래스가 나타내는 추상화의 한도 내에서 의미를 갖도록 하십시오.

      • 대입과 복사 생성은 모든 클래스에 대해 처리해 두어야 합니다. 복사나 생성을 사용하는 사람이 없을 것이라는 생각이 들어도 그렇게 해야 합니다. 지금 사용하지 않는다는 것은 나중에도 사용하지 않는다는 뜻이 아니니까요.

        복사나 생성 처리가 까다로운 경우에는 복사 생성자와 대입 연산자를 private로 선언해 두기 바랍니다. 컴파일러가 어쩌다가 만들어 놓은 코드 때문에 오작동이 일어나는 불상사를 막을 수 있습니다.

      • C++ 프로그래밍에서 어기면 안 되는 원칙이 있습니다. 바로 "황당함 최소화의 원칙(the principle of least astonishment)" 이란 것입니다.

        어떤 클래스에 대해 만들어지는 연산자와 함수는, 다른 사람들이 자연스럽게 사용할 수 있는 문법과 직관적인 의미구조를 갖도록 하라는 것이죠. C++의 기본 제공 타입과 동일한 동작원리를 갖도록 하세요. '아리송하면 int의 동작원리대로 만들지어다(when in doubt, do as the ints do)' 아시죠?

      • 누구라고 일으킬 수 있는 일은 반드시 터지고야 만다는 사실도 잊어선 안 됩니다.

        일반적으로 컴파일러가 별 불평을 하지 않는 동작은 누군가가 반드시 하게 된다고 생각하는 것이 좋습니다. 따라서 C++ 클래스를 만들 때에는, 맞게 사용하기에는 쉽고 틀리게 사용하기에는 어렵도록 클래스를 만들어야 합니다.
        
        그리고 이런 실수를 방지하고, 알아내고, 고칠 수 있도록 여러분의 클래스를 설계해야 합니다(항목 33에서 이야기한 내용이 그런 예입니다).

      • 코드의 이식성도 최대한 신경 쓰셔야 하는 부분입니다.

        이식이 안 되는 코드보다 이식이 잘 되는 코드를 작성하기가 훨씬 어렵습니다. 그리고 이식이 안 되는 코드를 꼭 써야 할 정도로 수행 성능의 차이가 현격하게 나는 경우도 드뭅니다(항목 16을 보세요).

      • 변경이 필요할 때 그 변경의 영향이 제한된 부분에만 미치도록 코드를 설계하기 바랍니다. 여러분이 힘닿는 데까지 캡슐화를 하고, 구현에 관련된 상세한 부분은 외부에 노출시키지 마세요.

        사용하는 개발 도구가 지원하는 기능에 맞추어 이름 없는 네임스페이스(unnamed namespace)를 사용하든지, 파일 범위(file-scope)의 정적 변수(객체)나 정적 함수를 선언하도록 하세요(항목 31에서 참고할 수 있습니다).
        
        가상 기본 클래스가 필요한 설계는 피하는 것이 좋습니다. if-then-else 문을 줄줄이 늘어놓는 RTTI 기반의 설계(역시 항목 31에서 참고할 수 있습니다)도 피하는 것이 좋습니다.

      • 클래스는 완벽하게 만듭니다. 어떤 부분은 지금 사용되지 않아도 완벽하게 만들어야 합니다.

        그래야 나중에 새로운 기능이 필요해질 때 그 클래스로 되돌아가서 근본부터 수정하는 일이 줄어듭니다.

      • 인터페이스를 설계할 때에는 자주 사용하는 기능은 모두 포함하고, 자주 일어나는 실수는 막아 둡니다. 맞게 사용하기에는 쉽고, 틀리게 사용하기에는 어렵도록 클래스를 만들어야 합니다.

        이를테면, 복사나 대입이 필요 없는 경우에는 복사나 생성이 일어나지 않도록 합니다. 부분 대입(partial assignment, 항목 33 참조) 현상은 반드시 막아야 합니다.

      • 코드를 일반화하더라도 별 손실이 없는 경우라면, 코드는 일반화합니다.

        예를 들어, 트리 횡단(tree traversal)에 필요한 알고리듬은 방향성 비순환 그래프(directed acyclic graph)에 쓸 수 있도록 일반화하도록 하십시오.

      • 미래 지향적인 사고도 중요하지만, 그렇다고 해서 현재 지향적인 사고가 엉터리라는 말은 아닙니다.

        여러분이 개발하는 소프트웨어는 지금(현재) 사용하는 컴파일러로 만들어질 수밖에 없습니다. 컴파일러에 최신의 기능이 구현될 때까지 기다릴 수는 없으니 현재 구현된 기능만으로 개발해야 합니다.
        
        소프트웨어는 여러분이 지금 지원하는 하드웨어에서 동작하도록 해야 하고, 사용자들이 쓰고 있을 플랫폼도 고려해야 합니다. 수행 속도도 웬만큼 나와 주어야 합니다.
        
        또, 지금 신명나게 개발하고 있는 소프트웨어는 '곧 출시됨(soon)'이어야 합니다. 언젠가는 '곧 출시됨(soon)'이 최근의 과거를 뜻하는 경우가 많다는 사실도 주의하십시오.
        
        미래 지향적인 사고도 중요하지만, 현재를 무시해선 안 됩니다. 미래 지향적 프로그램은 현재의 제약과 보조를 맞출 때 비로소 제 힘을 발휘할 수 있습니다.

  33. 상속 관계의 말단에 있지 않은 (non-leaf) 클래스는 반드시 추상 클래스로 만들자 / 351

      • 부분 대입(partial assignment) 현상

        동물(animal) 데이터를 취급하는 소프트웨어를 개발하는 프로젝트를 수행하고 있다고 가정합시다. 다른 동물들은 똑같이 처리하지만 유독 도마뱀(lizard)과 닭(chicken)에 대해서만 특별한 처리가 필요하게 되었습니다. 따라서, 일반적인 동물을 상속하여 닭과 도마뱀을 구현하였습니다. 이들 세 클래스(Animal, Lizard, Chicken)에는 각각 대입 연산자가 정의되어 있습니다. 이런 상황에서 다음과 같은 코드를 실행한다고 생각해 봅시다.
        
        Lizard liz1;
        Lizard liz2;
        
        Animal *pAnimal1 = &liz1;
        Animal *pAnimal2 = &liz2;
        ...
        *pAnimal1 = *pAnimal2;
        
        여기엔 두 가지 문제가 잠자고 있습니다. 우선, 마지막 줄에서 호출되는 대입 연산자는 Animal 클래스의 것입니다. 이렇기 때문에 liz1에 들어 있는 멤버 전체가 바뀌지 않고 Animal의 멤버인 부분만 바뀌고 맙니다. 이것을 가리켜 부분 대입 현상이라고 합니다. 물론 이런 현상이 일어나도록 두면 안 됩니다.
        
        두 번째 문제는 더욱 심각합니다. 바로, 프로그래머들이 진짜로 이렇게 코딩한다는 사실입니다. 항목 32에서 이야기 한 것처럼 클래스 설계는 '맞게 사용하기엔 쉽고, 틀리게 사용하기엔 어렵게' 해야 하지만, 지금 우리가 보고 있는 클래스는 틀리게 사용하기가 쉬워 보이네요.

      • 대입 연산자를 가상 함수로 바꾸면? - 타입 불일치 대입(mixed-type assignment) 현상

        C++ 표준화 위원회에 의해 최근에 변경된 사항 덕택에 대입 연산자의 반환값 타입은 파생 클래스의 참조자로 맞추어 줄 수 있게 되었지만, 가상 함수의 매개변수 타입만은 기본 클래스의 것을 그대로 쓸 수밖에 없습니다.
        즉, Lizard와 Chicken 클래스의 대입 연산자에 넘겨질 수 있는 객체는 Animal 타입이 될 수 있는 것이면 아무거나 다 된다는 뜻입니다. 다음과 같이 말이죠.
        
        Lizard liz;
        Chicken chick;
        
        Animal *pAnimal1 = &liz;
        Animal *pAnimal2 = &chick;
        ...
        *pAnimal1 = *pAnimal2;
        // 도마뱀에다가
        // 닭을 대입하려 하다니요!
        
        이것을 가리켜 타입 불일치 대입 현상이라고 합니다. 타입 불일치 대입은 C++에서 그다지 큰 문제는 아닙니다. 왜냐하면 C++는 타입 제약이 엄격해서 컴파일 단계에서 이런 경우를 잡아내기 때문입니다. 그런데 어떤 C++ 클래스의 대입 연산자가 가상 함수로 만들어지면 컴파일러가 이런 경우를 잡아내지 못하게 됩니다.

      • dynamic_cast(항목 2 참조)를 쓴다면?

        일단, dynamic_cast를 쓰면 소기의 목적은 달성할 수 있습니다. 예를 들어 Lizard 클래스의 대입 연산자에서 const Animal& 타입으로 받은 인자를 dynamic_cast를 사용해서 const Lizard& 타입으로 캐스팅 한 뒤 대입하는 것입니다. 만일 인자가 실제로 Lizard 타입이 아니었다면 std::bad_cast 예외가 던져질 것입니다.
        
        예제 코드 보기
        
        
        

        1. Lizard& Lizard::operator =(const Animal& rhs)
        2. {
        3. // rhs가 진짜로 Lizard 타입인지 확인합니다.
        4. const Lizard& rhs_liz = dynamic_cast<const Lizard&>(rhs);
        6. rhs를 *this에 대입합니다;
        7. }
        8.  
        9. // 진짜 Lizard 객체 사이에 대입이
        10. // 수행되는 경우가 훨씬 흔하지만,
        11. // 어떤 대입이든 타입 점검을 해야
        12. // 하니 비용이 많이 듭니다.
        13.  
        14. // 이런 경우에는 필요 없는 비용이
        15. // 들지 않도록 Lizard 클래스에
        16. // 그 클래스만의 대입 연산자를
        17. // 추가하면 간단히 해결됩니다.
        18.  
        19. class Lizard: public Animal {
        20. public:
        21. virtual Lizard& operator =(const Animal& rhs);
        23. Lizard& operator =(const Lizard& rhs); // 이것을 추가합니다.
        24. ...
        25. };
        26.  
        27. Lizard liz1, liz2;
        28. ...
        29. liz1 = liz2; // const Lizard&를 받는
        30. // operator =를 호출합니다.
        31. Animal *pAnimal1 = &liz1;
        32. Animal *pAnimal2 = &liz2;
        33. ...
        34. *pAnimal1 = *pAnimal2; // const Animal&를 받는
        35. // operator =를 호출합니다.
        36.  
        37. // 사실, 새로 추가된 operator =를 사용하면
        38. // 첫 번째 대입 연산자도 간단히 구현할 수 있습니다.
        39.  
        40. Lizard& Lizard::operator =(const Animal& rhs)
        41. {
        42. return operator =(dynamic_cast<const Lizard&>(rhs));
        43. }

        
        
        예제 코드 접기
        
        
        하지만 가뜩이나 런타임에 할 일도 많은데, 대입 연산자에까지 dynamic_cast로 타입을 비교하고 어쩌고 하는 것은 그다지 마음에 들지는 않습니다.
        
        게다가, 이런 Lizard와 Chicken 클래스를 가지고 프로그래밍하는 개발자는 항상 bad_cast에 대한 대비를 해야 합니다. 대입 연산자가 등장하는 부분마다 catch 문이 붙어야 한다니, 정상적인 사고를 지닌 C++ 프로그래머라면 쌍수를 들고 울 일입니다.
        
        행여나 예외 처리를 하지 않을 수도 있잖아요? 부분 대입을 막으려고 애썼던 것들이 모두 물거품이 될지도 모릅니다.

      • 이 문제는 조금 다른 시각에서 볼 필요가 있습니다. 개발자로 하여금 애초부터 이상한 대입을 하지 못하게 할 방법을 찾아야 합니다. 가장 쉬운 방법은 Animal::operator = 함수를 private 영역에 두는 것입니다.

        예제 코드 보기
        
        
        

        1. class Animal {
        2. private:
        3. Animal& operator =(const Animal& rhs); // 이 함수는 이제
        4. ... // private 멤버가 되었습니다.
        5. };
        6.  
        7. class Lizard: public Animal {
        8. public:
        9. Lizard& operator =(const Lizard& rhs);
        10. ...
        11. };
        12.  
        13. class Chicken: public Animal {
        14. public:
        15. Chicken& operator =(const Chicken& rhs);
        16. ...
        17. };
        18.  
        19. Lizard liz1, liz2;
        20. ...
        21. liz1 = liz2; // 문제없습니다.
        22.  
        23. Chicken chick1, chick2;
        24. ...
        25. chick1 = chick2; // 문제없습니다.
        26.  
        27. Animal *pAnimal1 = &liz1;
        28. Animal *pAnimal2 = &chick1;
        29. ...
        30. *pAnimal1 = *pAnimal2; // 에러입니다! private 멤버인
        31. // Animal::operator = 를 호출하려고 합니다.

        
        
        예제 코드 접기
        
        
        애석하게도 Animal은 구체 클래스(concrete class)이기 때문에, 이 방법 역시 다음의 문장이 컴파일 되지 않는다는 허점을 가지고 있습니다.
        
        Animal animal1, animal2;
        ...
        animal1 = animal2;
        // 에러입니다. private 멤버인
        // Animal::operator =를
        // 호출하려고 합니다.
        
        게다가, 이 방법을 사용하면 Lizard와 Chicken의 대입 연산자를 맞게 구현할 수도 없습니다. 왜냐하면, 파생 클래스의 대입 연산자는 기본 클래스의 대입 연산자를 호출해서 기본 클래스 부분의 대입 연산을 대신 맡겨야 하는 의무가 있기 때문입니다.
        
        후자의 문제야 Animal::operator = 함수를 protected 멤버로 선언하면 해결되지만, Animal 객체끼리 대입 연산이 되지 않는 문제는 여전히 남아 있습니다.

      • Animal 객체끼리 대입할 필요를 만들지 않는 건 어떨까요? 가장 쉬운 일이 아닐까 생각 됩니다. 그리고 'Animal 객체끼리 대입할 필요를 만들지 않으려면' Animal을 추상 클래스로 만드는 것이 가장 쉽습니다.

        Animal은 객체로 써먹으려고 만든 클래스인데, 졸지에 추상 클래스가 되어 버리면 애초의 설계가 엉망이 되고 만다는 문제가 있습니다. 하지만 이런 것쯤은 간단히 피해갈 수 있습니다.
        
        Animal을 추상 클래스로 만들지 말고 새로운 추상 클래스(AbstractAnimal)를 하나 만들고, Animal, Lizard, Chicken이 갖게 되는 공통적인 특징을 모두 갖게 합니다. 그리고, 세 개의 구체 클래스는 AbstractAnimal을 상속하도록 구성 합니다.
        
        예제 코드 보기
        
        
        

        1. class AbstractAnimal {
        2. protected:
        3. AbstractAnimal& operator =(const AbstractAnimal& rhs);
        5. public:
        6. virtual ~AbstractAnimal(void) = 0; // 다음을 보세요.
        7. ...
        8. };
        9.  
        10. class Animal: public AbstractAnimal {
        11. public:
        12. Animal& operator =(const Animal& rhs);
        13. ...
        14. };
        15.  
        16. class Lizard: public AbstractAnimal {
        17. public:
        18. Lizard& operator =(const Lizard& rhs);
        19. ...
        20. };
        21.  
        22. class Chicken: public AbstractAnimal {
        23. public:
        24. Chicken& operator =(const Chicken& rhs);
        25. ...
        26. };
        27.  
        28. // 이 설계라면 우리가 바라던 바는
        29. // 모두 이루어질 것 같습니다.
        30.  
        31. // 같은 타입끼리의 대입 연산은
        32. // 도마뱀과 닭은 물론 동물에 대해서도
        33. // 가능해지고, 부분 대입이나
        34. // 다른 타입끼리의 대입은 막힙니다.
        35.  
        36. // 그리고 파생 클래스의 대입 연산자는
        37. // 기본 클래스의 대입 연산자를 문제 없이
        38. // 호출할 수 있게 됩니다.
        39.  
        40. // 게다가, Animal, Lizard, 혹은 Chicken
        41. // 클래스에 사용된 코드는 전혀
        42. // 고칠 필요가 없습니다(물론
        43. // 재컴파일은 필요합니다).
        44.  
        45.  
        46. // AbstractAnimal이 추상 클래스가 되기
        47. // 위해서는 순수 가상 함수를 최소한
        48. // 한 개 가져야 합니다.
        49.  
        50. // 순수 가상 함수로 만들만한
        51. // 멤버 함수가 하나도 없는 드문
        52. // 경우에는 보통 소멸자를
        53. // 순수 가상 함수로 선언해서
        54. // 해결합니다.
        55.  
        56. // 소멸자는 순수 가상함수이더라도
        57. // 정의를 가져야 합니다.
        58.  
        59. // 왜냐하면, 파생 클래스의 소멸자가
        60. // 호출될 때 결국 이 함수도
        61. // 호출되기 때문입니다.

        
        
        예제 코드 접기
        
        
        

      • 사실 지금까지 한 이야기는 구체(concrete) 기본 클래스가 데이터 멤버를 가지고 있을 때를 가정하고 한 이야기 입니다. 기본 클래스에 데이터 멤버가 없을 경우라면, 지금까지 한 이야기는 전부 아무 문제도 아닙니다. 데이터가 없는 구체 클래스로부터 구체 클래스를 파생시키는 것은 몇 백 번을 하더라도 안전합니다.

        구체 기본 클래스에 데이터가 없을 수 있는 상황은 두 가지 중 하나입니다. 이후에 데이터를 가질 수 있으나 지금 안 가진 경우와 진짜로 데이터가 없는 경우이죠.
        
        첫째 경우에 여러분은 데이터 멤버가 추가되는 미래를 신경 쓰지 않고 문제들을 덮어두기만 하면 됩니다. 미래의 머리아픔 대신에 현재의 편리함을 택하자는 것입니다.
        
        두 번째 경우는 왠지 구체 클래스가 있을 자리에 추상 클래스가 있어야 할 것 같은 느낌을 줍니다. 데이터가 없는 구체 클래스라니, 어디에 써먹는단 말입니까?

      • Animal같은 구체 기본 클래스 대신에 AbstractAnimal같은 추상 기본 클래스로 바꾸면, 객체의 배열을 다형적으로 조작하는 실수를 할 가능성도 적어집니다(항목 3 참조).

        하지만 무엇보다 중요한 이득은 프로그램 설계 쪽에서 찾을 수 있습니다. 구체 기본 클래스를 추상 기본 클래스로 바꾸면, '뭔가 쓸모 있는' 추상 타입이 존재한다는 것을 명시적으로 알리는 셈이 된다는 것입니다.
        
        즉, 프로그래머는 이 사실을 자연스럽게 알게 되기 때문에 프로그램 제작에 도움이 되는 그 개념을 추상화한 클래스를 만들어 사용할 수 있습니다. 그런 개념이 있다는 사실을 모를지라도 말이죠.
        
        구체 기본 클래스에서 추상 기본 클래스로 변환하는 데에는 확실한 명분이 있습니다. 기존의 구체 클래스를 기본 클래스로 사용해야 할 때에만, 즉 이 클래스가 다른 경우에서 재사용되어야 할 때에만 추상 클래스가 새로 도입되어야 한다는 것입니다.

      • 이번 항목에서 보여드린 클래스 계통 구조를 변환하는 과정은 추상 클래스가 필요한 경우를 찾아내는 유일한 방법이 아닙니다. 이외에도 방법은 아주 많으니, 이런 부분에 대해서는 객체지향 분석에 관련된 책을 뒤져서 필요한 만큼 공부하시면 되겠습니다.

      • 외부 라이브러리에 속해 있는 클래스의 기능을 끌어온 파생 클래스를 만들어 사용하고 싶은 경우도 많을 것입니다.

        알다시피 라이브러리는 바이너리이기 때문에, 추상 클래스를 새로 만들어 끼워 넣는 것은 불가능합니다. 따라서 선택의 폭은 그만큼 좁아지고, 그나마 선택할 수 있는 것마저도 그리 썩 마음에 들지 않습니다.
        
        
        • 기존의 구체 클래스로부터 여러분의 구체 클래스를 파생시켜 사용하되, 이번 항목의 앞에서 이야기한 객체 대입에 관련된 문제는 꾹꾹 참고 지켜냅니다. 또한, 항목 3에서 이야기한 객체 배열에 관련된 함정도 조심해야 합니다.
        • 해당 라이브러리 클래스보다 상위 계통 구조에 있으며 여러분이 원하는 기능을 많이 가진 추상 클래스를 찾아서, 그 클래스로부터 파생 클래스를 만듭니다. 물론 원하는 추상 클래스가 없을 수도 있고, 있다고 해도 여러분이 기본 클래스로 삼으려고 했던 그 라이브러리 클래스의 동작 원리를 반복해서 구현해 줘야 하므로 중노동이 배가됩니다.
        • 기본 클래스로 삼으려고 했던 라이브러리 클래스를 사용해서 독립적인 클래스를 새로 구현합니다. 이를테면, 새 클래스에는 라이브러리 클래스의 인스턴스를 데이터 멤버로 넣고, 라이브러리 클래스의 인터페이스를 다시 구현하는 것입니다.
          
          예제 코드 보기
          
          
          

          1. class Window { // 이 클래스는 라이브러리 클래스입니다.
          2. public:
          3. virtual void resize(int newWidth, int newHeight);
          4. virtual void repaint(void) const;
          6. int width(void) const;
          7. int height(void) const;
          8. };
          9.  
          10. class SpecialWindow { // 이 클래스는 Window로부터
          11. public: // 파생시켜 만들고 싶었던
          12. ... // 클래스입니다.
          14. // Window 객체를 써서 결과를 내어주는 비가상 함수
          15. int width(void) const { return w.width(); }
          16. int height(void) const { return w.height(); }
          18. // "상속하고 싶었던" 가상 함수를 새로 구현한 부분
          19. virtual void resize(int newWidth, int newHeight);
          20. virtual void repaint(void) const;
          22. private:
          23. Window w;
          24. };
          25.  
          26. // 물론 라이브러리가 업데이트 되었을 경우에는
          27. // 그에 따른 조치를 취해야 합니다.
          28.  
          29. // 또한, 라이브러리 클래스에 선언된 가상
          30. // 함수를 어떻게 해보겠다는 생각은 버리는게
          31. // 좋습니다. 직접 상속하지 않으면 가상
          32. // 함수는 재정의(오버라이드)할 수 없으니까요.

          
          
          예제 코드 접기
          
          
          
        • 그냥 있는 대로 삽시다. 라이브러리에 있는 클래스를 사용할 수 있도록 여러분의 프로그램을 고치세요. 파생 클래스를 만들어서 추가하고 싶었던 기능은 별도의 비멤버 함수(전역이든 정적이든)로 구현합니다. 이렇게 만든 소프트웨어는 그리 깔끔하지도, 효율적이지도, 유지보수성이 좋지도, 확장성이 좋지도 않겠지만, 어쨌든 여러분이 원하던 바대로 돌아가긴 할 것입니다.
        
        
        딱히 마음에 드는 것이 하나도 없겠지만, 그렇기 때문에 프로젝트 진행 상황을 잘 살펴서 결단을 내린 후에, 가장 덜 고통스러울 만한 방법을 선택하도록 하십시오.
        
        그래도 이 후의 인생만은 지금보다 덜 피곤하게 만들고 싶다면, 라이브러리 제작사의 고객 센터에 항의해서 설계 좀 잘 하라고 압력을 넣으세요.
        
        외부 라이브러리를 사용하는 경우에는 어쩔 수 없지만, 여러분이 건드릴 수 있는 코드에 대해서는 '상속 관계의 말단에 있지 않은 (non-leaf) 클래스는 반드시 추상 클래스여야 한다' 라는 법칙을 지키도록 하십시오.

  34. 한 프로그램에서 C++와 C를 함께 사용하는 방법을 이해하자 / 366

      • 각자가 사용하는 C++와 C 컴파일러가 생성하는 목적 코드가 서로 호환되는지 확인합니다.

      • 네임 맹글링(Name Mangling) - 두 개의 언어에서 동시에 사용되는 함수는 extern "C"로 선언합니다.

        네임 맹글링, 우리말로 '함수 이름 뒤섞기'라고 불리는 이 동작은 C++ 컴파일러가 함수에 대해 독특한 내부 호출용 이름을 만들어 붙이는 동작을 의미합니다.
        
        이 동작은 C++의 함수 오버로딩을 위한 기능인데, 링커는 같은 이름을 가진 여러 개의 함수를 구분하지 못하기 때문에 이런 링커의 딱한 사정을 봐준 결과 네임 맹글링이란 기능이 생기게 되었습니다.
        
        C++만 사용하여 개발하는 경우에는 네임 맹글링이 아무런 문제가 되지 않습니다. 예를 들어 drawLine이란 이름의 C++ 함수가 있는데 컴파일러가 이 이름을 xyzzy로 맹글링했다고 해도, drawLine이란 이름을 사용하는 데에는 여전히 문제가 없습니다.
        
        그런데 drawLine 함수가 C로 제작한 라이브러리 함수라면 이야기가 달라집니다. 이 경우 C++ 소스 파일에는 다음과 같은 선언문이 적힌 헤더 파일이 인클루드 되겠지요.
        
        void drawLine(int x1, int y1,
        int x2, int y2);
        
        문제는 이 함수를 호출하는 C++ 문장을, 컴파일하는 컴파일러가 C++ 컴파일러라는 사실입니다. 즉, drawLine이란 이름은 네임 맹글링을 통해 내부 호출용 이름으로 바뀌기 때문에, 다음과 같은 함수 호출 코드는,
        
        drawLine(a, b, c, d);
        // 맹글링되지 않은 이름으로 호출
        
        컴파일러에 의해 다음과 같은 함수 호출문으로 해석되고, 이 C++ 소스 파일을 통해 만들어진 목적 파일에 들어갑니다.
        
        xyzzy(a, b, c, d);
        // 맹글링된 함수 이름으로 호출
        
        그러나 drawLine은 C 함수이기 때문에 네임 맹글링이 일어나지 않아 목적 파일 역시 drawLine이란 이름을 사용합니다.
        
        이 문제를 해결하려면, C++ 컴파일러에게 drawLine을 호출한 코드에 대해서는 네임 맹글링을 수행하지 않도록 extern "C" 지시자(directive)를 사용해야 합니다.
        
        // drawLine란 이름의 함수를
        // 선언하되, 이 이름은
        // 맹글링하지 않습니다.
        extern "C"
        void drawLine(int x1, int y1,
        int x2, int y2);
        
        지시자 안에 "C"가 들어 있다고 해서 extern "Pascal" 이나 extern "FORTRAN" 도 있지 않을까 착각할 수 있지만, 그런 것은 없습니다.
        
        어떤 함수를 어셈블러로 만들게 되었다면, 이 함수를 C++에서 사용하려고 할때 역시 extern "C"를 붙여서 선언해야 합니다.
        
        C++로 만든 라이브러리를 다른 언어를 쓰는 사람들에게 공급하려고 할 때도 extern "C" 지시자를 쓸 수 있습니다.
        
        예제 코드 보기
        
        
        

        1. // 이 C++ 함수는 C++ 이외의 언어에서 사용할 수 있도록
        2. // 설계되었습니다. 따라서 네임 맹글링을 하지 않도록 합니다.
        3. extern "C" void simulate(int iterations);
        4.  
        5. // 네임 맹글링을 막고 싶은 함수가 여러 개 되는 경우도
        6. // 있을 수 있습니다. 이럴 때는 다음과 같이 간편하게
        7. // 쓸 수 있습니다.
        8.  
        9. extern "C" { // 이후의 모든 함수에 대해서는
        10. // 네임 맹글링을 막습니다.
        12. void drawLine(int x1, int y1, int x2, int y2);
        13. void twiddleBits(unsigned char bits);
        14. void simulate(int iterations);
        15. ...
        16. }

        
        
        예제 코드 접기
        
        
        C++와 C를 동시에 사용하는 경우에 헤더 파일의 관리를 단순하게 하는 방법도 있습니다. C++ 컴파일중에만 __cplusplus 라는 전처리자 심볼이 정의(define)된다는 사실을 이용하는 것입니다.
        
        예제 코드 보기
        
        
        

        1. #ifdef __cplusplus
        2.  
        3. extern "C" {
        4.  
        5. #endif
        7. void drawLine(int x1, int y1, int x2, int y2);
        8. void twiddleBits(unsigned char bits);
        9. void simulate(int iterations);
        10. ...
        11. #ifdef __cplusplus
        12. }
        13.  
        14. #endif
        15.  

        
        
        예제 코드 접기
        
        
        마지막으로 덧붙이자면, C++ 컴파일러의 "표준" 네임 맹글링 알고리듬 같은 것은 없습니다. 컴파일러마다 구현 방식이 천차만별이며, 동작방식도 제각각입니다.
        
        때문에 호환되지 않는 C++ 컴파일러로 생성한 목적 코드(object code)를 섞으려고 하면 바로 링크 에러가 날 것입니다. 맹글링된 이름이 일치될 리가 없으니까요.

      • 정적 데이터 초기화(Initialization of Statics) - 가능하면 main은 C++로 작성합니다.

        C++에서는 main 함수가 호출되기 전과 호출된 후에 많은 코드들이 실행됩니다. 특히, main의 몸체가 실행되기 전에 정적 클래스 객체와 전역 객체, 네임스페이스와 파일 범위 바깥에 있는 객체의 생성자가 실행된다는 사실은 심각하게 짚어 봐야 할 필요가 있습니다. 그리고 이렇게 생성된 객체들은 main의 실행이 끝난 후에 소멸됩니다.
        
        대다수의 C++ 컴파일러는 main의 시작 부분에 특수한 전용 함수를 호출하는 코드를 삽입하는 방법으로, 정적 데이터를 초기화합니다. 비슷한 이치로, main의 마지막 부분에는 정적 데이터 소멸을 수행하는 함수를 호출하는 코드를 끼워 넣었습니다.
        
        예제 코드 보기
        
        
        

        1. int main(int argc, char *argv[])
        2. {
        3. performStaticInitialization(); // 컴파일러가 생성한
        4. // 코드
        6. main에 개발자가 써넣는 코드가 이 부분에 들어갑니다;
        8. performStaticDestruction(); // 컴파일러가 생성한
        9. // 코드
        10. };
        11.  
        12. // performStaticInitialization 함수와
        13. // performStaticDestruction 함수는
        14. // 실제로 이런 이름이 아닐 수도 있습니다.
        15.  
        16. // 암호문처럼 전혀 알아보지 못할 이름일 수도 있고,
        17. // 인라인 함수로 구현되어 실제 목적 파일에는
        18. // 함수 이름조차 찾기 힘들 수도 있습니다.

        
        
        예제 코드 접기
        
        
        이러한 이유로 main이 C++로 작성되지 않으면 정적 객체의 초기화화 소멸이 정상적으로 이루어 지지 않습니다. 그러므로 C++를 써서 소프트웨어의 일부를 만들고 있었다면 main은 C++로 작성하시는 편이 정신건강에 좋습니다.
        
        프로그램의 거의 대부분을 C로만 짰고 C++라이브러리를 조금 사용했다고 하더라도 C++ 라이브러리에 정적 객체가 포함되어 있을수도 있으므로, main은 C++로 작성하시는게 좋습니다. 멀쩡한 C 코드를 갈아엎고 C++로 다시 만들라는 뜻은 아니고, C로 만들었던 main에는 realMain이란 새 이름을 지어주고, C++로 만든 main에서 realMain을 호출하게 하는 것입니다.
        
        예제 코드 보기
        
        
        

        1. extern "C" // 이 함수를
        2. int realMain(int argc, char *argv[]); // C로 구현합니다.
        3.  
        4. int main(int argc, char *argv[]) // 이 main은 C++로 작성합니다.
        5. {
        6. return realMain(argc, argv);
        7. }
        8.  
        9. // 이런 방법을 썼을 경우엔 main 위에 간단한
        10. // 주석문을 붙여서 알아보기 쉽게 하는 것이
        11. // 좋습니다.

        
        
        예제 코드 접기
        
        
        컴파일러 제작사들도 이런 문제를 잘 알고 있기 때문에, 거의 모든 제작사들이 정적 데이터 초기화 및 소멸을 맡아주는 별도의 메커니즘을 언어 외적으로 제공하고 있습니다. 이런 기능에 대한 정보는 여러분이 사용하고 있는 컴파일러 설명 문서를 찾아서 참고하시는 것이 좋겠습니다.

      • 동적 메모리 할당(Dynamic Memory Allocation) - new로 할당한 메모리는 delete로 해제하고, malloc으로 할당한 메모리는 free로 해제합니다.

        말은 쉽지만, 생각보다 실천하기 힘든 때도 있습니다. strdup 함수 아시죠? 이 함수는 C 표준 API도 아니고 C++ 표준 API도 아니지만, 상당히 많이 사용되고 있는 함수입니다.
        
        char * strdup(const char *ps);
        // ps가 가리키고 있는 문자열을
        // 별도의 힙 메모리에 복사하고
        // 그 포인터를 반환합니다.
        
        메모리 누수를 막기 위해서는 strdup 안에서 할당된 힙 메모리를 strdup의 호출부가 해제해 주어야 합니다. 그런데 free를 사용하여 해제해야 할까요? delete를 사용하여 해제해야 할까요? 이 함수가 C 라이브러리에 속해 있었다면 전자가 정답이겠고, C++ 라이브러리에 속해 있었다면 후자가 정답이겠지요. 즉, strdup를 호출한 이후의 처리 방법이 시스템은 물론 컴파일러마다 다르다는 것입니다.
        
        이런 골치 아픈 호환성 문제를 줄이려면, 표준 라이브러리에 속해 있지도 않으며 대부분의 플랫폼에서 안정된 형태로 쓸 수도 없는 함수는, 아예 호출하지 않도록 해야 합니다.

      • 자료구조의 호환성(Data Structure Compatibility) - 두 개의 언어로 작성한 함수 사이에 전달할 수 있는 데이터 타입은 C 컴파일러로 컴파일되는 것으로만 한정합니다. C와 호환이 가능한 C++ 구조체는 비가상 멤버 함수까지만 가질 수 있습니다.

        C++와 C 컴파일러가 호환성 있는 코드를 만들어낸다면, 두 언어로 만든 함수 사이에 객체의 포인터가 오가거나 비멤버 함수나 정적 함수에 대한 포인터가 오가는 데에는 별 문제가 없습니다. 구조체 종류(struct나 class, 이후에는 구조체로 지칭)와 기본 제공 타입(int, char 등) 역시 C++와 C 경계를 자유롭게 오갈 수 있습니다.
        
        C++ 구조체의 메모리 배열 구조에 대한 규칙은 C 구조체와 동일하기 때문에, 두 언어로 컴파일되는 구조체는 메모리 배열 구조에 있어서도 동일하다고 가정해도 별 문제는 없습니다. C++ 구조체에 멤버 함수를 추가한다고 해도, 그 멤버 함수가 가상 함수만 아니면 메모리 배열 구조는 변하지 않아야 하므로, 비가상 함수만 가지고 있는 객체는 C 에서도 쓸 수 있습니다.
        
        하지만 가상 함수가 하나라도 있는 경우에는, 가상 함수 테이블에 관련된 숨겨진 데이터 멤버(항목 24 참조)로 인해 C++ 구조체의 메모리 배열 구조가 바뀌기 때문에 C 와의 호환성이 깨집니다.
        
        또한 한 구조체에서 다른 구조체를 파생시켜도 메모리 배열 구조가 바뀌는 것이 보통이므로, 상속 계통 구조로 짜여진 C++ 구조체 타입은 C 함수에 쓰기 힘듭니다.

  35. C++ 언어의 최신 표준안과 표준 라이브러리에 대해 익숙해지자 / 374

      • The Annotated C++ Reference Manual(ARM) 이후의 변경 사항 중 가장 중요한 것들을 여기에 추려 보았습니다(항목 35에서 언급하는 '개정 표준안'은 1998년 이전의 것을 가리킵니다).

        • 새로운 기능이 추가됨: RTTI, namespace, bool, mutable과 함께 explicit란 키워드가 추가되었고, 나열자(enum) 타입에 대해 연산자 오버로딩이 가능해졌으며, 숫자 상수 타입의 정적 데이터 멤버를 클래스 안에서 초기화할 수 있게 되었습니다.
        • 템플릿 기능이 확장됨: 멤버 템플릿이 가능해졌고, 템플릿 인스턴스화를 지시하는 표준 문법이 생겼고, 함수 템플릿에 비타입(non-type) 인자를 넣을 수 있게 되었으며, 클래스 템플릿도 템플릿 인자로 사용할 수 있습니다.
        • 예외 처리 기능이 개량됨: 예외 지정(exception specification)은 컴파일 도중에 더 정밀하게 점검되며, unexpected 함수는 bad_exception 객체를 예외로 발생시킵니다.
        • 메모리 할당 루틴이 수정됨: operator new[]와 operator delete[]가 추가되었고, new/new[] 연산자는 메모리 할당에 실패했을 때 예외를 발생시키도록 바뀌었습니다. 할당에 실패했을 때 0을 반환하는 new/new[] 연산자는 이젠 대체 버전으로 준비되어 있습니다.
        • 새로운 캐스팅 방식이 추가됨: static_cast, dynamic_cast, const_cast, reinterpret_cast가 추가되었습니다.
        • 언어 규칙이 개량됨: 이제 재정의한 가상 함수의 반환 타입은 원래 가상 함수(파생 클래스의 것)의 반환 타입과 일치하지 않아도 되고, 임시 객체(temporary object)의 생성/소멸 시점이 확실히 정의되었습니다.
        
        변경된 사항 중 대부분은 The Desigm and Evolution of C++ 라는 책에서 설명하고 있습니다.

      • 환골탈태한 표준 C++ 라이브러리의 면모는 다음과 같이 크게 몇 개의 범주로 나누어 설명할 수 있습니다.

        • 표준 C 라이브러리를 그대로 지원함: C 라이브러리가 C++ 버전으로 바뀌면서 C++의 엄격한 타입 점검을 준수하기 위해 사소한 몇 가지가 바뀌었지만, 어쨌든 C 라이브러리를 그대로 C++에서 사용할 수 있습니다.
        • 문자열(string)을 지원함: 표준 C++ 라이브러리에서는 문자열 타입이 드디어 지원됩니다.
        • 지역화(localization)를 지원함: 표준 C++ 라이브러리에는 사용하는 문자 집합, 날짜나 시간 표기, 문자열 정렬, 통화 표기 등의 지역적 차이를 수용한 프로그램을 쉽게 개발할 수 있도록 하는 지역화 기능이 추가되었습니다.
        • 입출력 스트림 라이브러리가 약간 변경됨: iostream 라이브러리는 여전히 C++ 표준에 속해 있게 되었지만, 표준화 위원회는 이 입출력 라이브러리에도 살짝 손을 댔습니다. 어떤 클래스는 그 흔적만 남고(iostream이 그 예), 또 어떤 클래스는 다른 것으로 바뀌었지만(char* 를 사용하던 strstream 대신에 string을 사용하는 stringstream이 표준이 되었습니다. 현재 strstream은 폐기처분된 클래스입니다), 표준 iostream 클래스의 기본적인 기능은 이전 것을 그대로 유지하고 있습니다.
        • 숫자 조작을 돕는 데이터 타입이 지원됨: 복소수 클래스(complex)가 드디어 표준 라이브러리에 모셔졌습니다(complex 클래스 템플릿으로). 게다가 숫자 데이터만 모아서 다루는 특수한 배열 클래스(valarray)가 추가되었는데, 이 배열 클래스는 C++ 배열을 사용할 때보다 강도 높은 최적화를 해야 할 경우(다중 프로세싱 환경 같은)에 적합합니다. 이외에도, 부분합(partial sum)이나 인접차(adjacent difference)를 구하는 함수 등의 숫자 조작 함수들이 표준 라이브러리에 포함되어 프로그래밍이 더욱 편리해졌습니다.
        • 타입에 상관 없이 쓸 수 있는 일반 용도의 컨테이너와 알고리듬이 지원됨: 표준 C++ 라이브러리에는 표준 템플릿 라이브러리(Standard Template Library - STL)라 불리는 클래스와 함수 모음이 포함되어 있습니다. STL은 표준 C++ 라이브러리의 핵심이라 불릴 만큼 가장 중요하고 C++ 프로그래밍에 가히 혁명적이라고 할 만한 개념으로 똘똘 뭉쳐 있습니다.

      • 표준 템플릿 라이브러리(Standard Template Library) - 기본원리 위주의 겉핥기

        STL을 제대로 이해하려면 일단 표준 C++ 라이브러리의 두 가지 기본 특성을 알고 계셔야 합니다.
        • 첫 번째, 표준 라이브러리에 속해 있는 대부분의 것들은 템플릿으로 만들어져 있습니다.
        • 두 번째, 표준 라이브러리의 모든 구성요소가 std라는 네임스페이스에 속해 있다는 점입니다.
        
        
        STL은 세 가지의 기본 개념을 바탕으로 만들어졌습니다. 이 세 가지는 컨테이너(container), 반복자(iterator), 알고리듬(algorithm)입니다.
        
        반복자는 STL 컨테이너에 담긴 요소를 하나씩 살펴볼 때 사용하는, 포인터처럼 동작하는 객체입니다. 알고리듬은 STL 컨테이너에 대해 반복자를 사용하여 일정한 동작원리를 수행하는 함수입니다.
        
        STL을 쉽게 이해하려면, C++ 배열의 사용 원리를 하나씩 더듬어 보는 것이 가장 좋습니다. 별다른 것은 없고, 배열을 가리키는 포인터로는 배열 내부의 요소를 가리킬 수 있고, 마지막 배열 요소의 이후를 가리킬 수 있다는 정도만 알면 됩니다. 그 배열의 마지막 요소의 이후를 가리키는 포인터는 다른 배열 혹은 유효하지 않은 메모리를 가리키고 있다고 볼 수 있으며, 이때의 포인터를 역참조하면 정의되지(undefined) 않은 결과가 발생합니다.
        
        이 원리를 이용하면, 어떤 배열에서 특정한 값을 찾아내는 함수를 만들 수 있을 것 같죠? 다음 예제는 정수형(int) 배열에 대해 동작하는 탐색용 함수입니다.
        
        예제 코드 보기
        
        
        

        1. int* find(int *begin, int *end, int value)
        2. {
        3. while (begin != end && *begin != value) ++begin;
        4. return begin;
        5. }
        6.  
        7. // 이 함수는 begin과 end(실제로
        8. // end는 빠집니다. end는 마지막
        9. // 배열 요소 다음을 가리킵니다)
        10. // 사이의 범위에서 value라는 값을
        11. // 찾아, 배열에서 그 값을 가진
        12. // 가장 첫 번째 요소에 대한 포인터를
        13. // 반환합니다.
        14.  
        15. // 아무것도 못 찾으면, end를 반환합니다.
        16.  
        17. // find 함수는 이런 식으로
        18. // 사용할 수 있습니다.
        19.  
        20. int values[50];
        21. ...
        22. int *firstFive = find(values, // values[0] - values[49]의
        23. values + 50, // 범위에서 5란 값이 들어있는
        24. 5); // 요소를 찾습니다.
        25.  
        26. if (firstFive != values + 50) { // 탐색이 성공했나요?
        27. ... // 네
        28. }
        29. else {
        30. ... // 아뇨 실패했습니다.
        31. }
        32.  
        33. // 같은 배열 내의 일부 범위에
        34. // 대해서만 탐색할 수도 있습니다.
        35.  
        36. int *firstFive = find(values, // values[0] - values[9]의
        37. values + 10, // 범위에서 5란 값이 들어있는
        38. 5); // 요소를 찾습니다.
        39.  
        40. int age = 36;
        41. ...
        42.  
        43. int *firstValue = find(values + 10, // values[10] - values[19]의
        44. values + 20, // 범위에서 age와 같은 값이
        45. age); // 들어있는 요소를 찾습니다.

        
        
        예제 코드 접기
        
        
        이렇게 하고 보니, find 함수에 쓰이는 배열에 들어가는 요소의 타입을 굳이 int로 한정지을 필요가 없을 것 같습니다. 그래서 이 find를 함수 템플릿으로 만듭니다.
        
        예제 코드 보기
        
        
        

        1. template <class T>
        2. T * find(T *begin, T *end, const T& value)
        3. {
        4. while (begin != end && *begin != value) ++begin;
        5. return begin;
        6. }
        7.  
        8. // value가 어떤 타입인지 알수가
        9. // 없어서 상수 객체에 대한 참조자로
        10. // 바뀌었습니다.
        11.  
        12. // 불필요한 복사를 막기 위해서죠.

        
        
        예제 코드 접기
        
        
        일반화시킬 부분이 아직도 남아 있습니다. 함수 몸체에서 begin과 end가 한 것이라고는 비상등 비교(!=), 역참조 연산자(*), 전위 증가 연산자(++)와 함수의 반환값에 대한 복사를 수행한 것밖에 없습니다. 여기서 수행된 연산들은 모두 오버로딩이 가능한데, 연산자의 동작 대상을 굳이 '포인터'로 한정지을 필요가 있을까요?
        
        연결 리스트(linked-list)를 예로 들면, 전위 증가 연산자를 통해 다음 노드(node)로 넘어갈 수 있는 '포인터 비슷한' 객체를 정의할 수 있을 것 같다는 것입니다.
        
        바로 이것이 STL반복자의 기본 아이디어입니다. 반복자(Iterator)는 STL 컨테이너의 요소를 가리킬 때 사용하는 '포인터 비슷한' 객체입니다. '반복자는 포인터처럼 동작하는 객체다'라는 생각을 find 함수에 옮겨 봅시다.
        
        예제 코드 보기
        
        
        

        1. template <class Iterator, class T>
        2. Iterator find(Iterator begin, Iterator end, const T& value)
        3. {
        4. while (begin != end && *begin != value) ++begin;
        5. return begin;
        6. }
        7.  
        8. // 여러분은 바로 표준 템플릿 라이브러리의
        9. // 일부를 그대로 구현한 것입니다!
        10.  
        11. // STL에는 이렇게 컨테이너와 반복자를
        12. // 사용해서 동작하는 함수 템플릿이
        13. // 모여 있는데, 이런 것들을 가리켜
        14. // 알고리듬(algorithm)이라고 부릅니다.
        15.  
        16. // find도 STL 알고리듬 중의 하나입니다.

        
        
        예제 코드 접기
        
        
        STL의 컨테이너(Container)는 데이터를 모아서 관리하는 클래스 템플릿입니다. 여기에는 bitset(비트셋), vector(벡터), list(리스트), deque(데크), queue(큐), priority_queue(우선순위 큐), stack(스택), set(셋), map(맵) 등이 해당됩니다. 이들 컨테이너는 어떤 것이든 find 함수에서 사용할 수 있습니다.
        
        list<char> charList;
        // char를 모아서 관리하는
        // list 객체를 생성합니다.
        
        ...
        // charList에서 'x'가 처음
        // 나타난 위치를 찾습니다.
        list<char>::iterator it =
        find(charList.begin(),
        charList.end(),
        'x');
        
        list 객체를 find 함수에서 사용하려면, 이 리스트의 첫째 요소를 가리키는 반복자와, 마지막 요소의 바로 다음을 가리키는 반복자가 필요합니다. 이 반복자들은 각각 begin(), end() 라는 멤버함수들을 통해 구할 수 있습니다.
        
        또한 list 클래스에는 iterator라는 typedef 타입이 정의되어 있어서, 반복자 타입이 필요하면 이것을 끌어와 사용할 수 있습니다. 즉 charList는 char의 list이므로, 이 리스트의 반복자 타입은 list<char>::iterator가 됩니다.
        
        list 클래스에는 반복자 타입 두 개가 정의되어 있습니다. 하나는 iterator이고, 또 하나는 const_iterator인데, 전자는 보통의 포인터와 비슷하고, 후자는 상수 객체에 대한 포인터와 비슷합니다.
        
        여기서는 list를 예로 들었지만 다른 STL 컨테이너에 대해서도 똑같은 방법을 쓸 수 있습니다. 심지어 포인터도 반복자의 기본 성격을 그대로 띠고 있기 때문에, 앞에서 보셨던 배열 예제를 STL find 함수에 적용하더라도 전혀 문제가 안 됩니다.

      • STL의 핵심은 간결하다는 것입니다. 그저 일정한 규정에 맞게 만들어진 클래스 템플릿과 함수 템플릿을 모아놓은 것일 뿐입니다.

        그 규정이란 것도 알고 보면 단순합니다.
        • STL 컨테이너는 처음 요소와 끝 요소(다음)를 가리키는 begin과 end를 멤버 함수로 제공하여, 사용자 쪽에서는 반복자를 쓸 수 있도록 합니다.
        • STL 알고리듬은 이 반복자를 써서 STL 컨테이너 안의 요소를 차례대로 훑어 갑니다.
        • STL 반복자는 포인터와 비슷하게 동작합니다.
        엄청난 상속 관계가 이리저리 꼬여 있지도 않고, 가상 함수 같은 것도 없습니다. 몇 개의 클래스 템플릿과 몇 십개의 함수 템플릿, 그리고 이것들에 대한 규정이 STL의 전부입니다.

      • STL은 간결하기 때문에 확장하기도 쉽습니다.

        '규정'만 제대로 지켜서 만들면, 표준 STL 컨테이너를 여러분의 알고리듬에 적용하거나 표준 STL 알고리듬에 여러분의 컨테이너를 적용하면서 쾌적하고 풍요로운 프로그래밍을 즐길 수 있습니다.
        
        물론, 여러분이 만든 템플릿을 표준 C++ 라이브러리에 넣는 것만은 불가능하지만, 동일한 원리로 만들었기 때문에 표준 라이브러리처럼 사용하는 데에 아무런 문제가 없습니다.

      • 사실 여기서 늘어놓은 C++ 라이브러리 이야기는 빙산의 일각에 불과합니다. 표준 C++ 라이브러리를 효과적으로 사용하려면 여기서 이야기한 것보다 더 많이 공부하셔야 합니다. STL 구성요소와 호환되는 템플릿을 만들어 보고 싶은 독자라면, STL의 규정에 대해 더 많이 공부하셔야 하고요.