Effective C++(제3판 번역서) 정리

• Chapter 1   C++에 왔으면 C++의 법을 따릅시다.

  1. C++를 언어들의 집합체로 바라보는 안목은 필수 / 51

     • C++을 사용한 효과적인 프로그래밍 규칙은 경우에 따라 달라집니다. 그 경우란, 바로 C++의 어떤 부분을 사용하느냐 입니다.

       C++ 은 다음 네 가지 부분으로 나누어 생각할 수 있습니다.
       • C언어에서 물려받은 부분
       • 객체 지향 개념의 C++
       • 템플릿 C++
       • STL

  2. #define을 쓰려거든 const, enum, inline을 떠올리자 / 53

     • 단순한 상수를 쓸 때는, #define보다 const 객체 혹은 enum을 우선 생각합시다.

       예제 코드 보기
       
       
       

       1. //-------------------------------------------------------------------
       2. // 정수형 정적 상수 멤버의 선언 방법
       3.  
       4. class GamePlayer {
       5. private:
       6. static const int NumTurns = 5; // 상수 선언
       7. int scores[NumTurns]; // 상수를 사용하는 부분
       8. ...
       9. };
       10.  
       11. // 여기서 NumTurns는 '선언(declaration)'된 것입니다.
       12. // '정의'가 아니니 주의하세요.
       13.  
       14. // C++에서는 여러분이 사용하고자 하는 것에 대해 '정의'가 마련되어 있어야 하는게 보통이지만,
       15. // 정적 멤버로 만들어지는 정수류(각종 정수 타입, char, bool 등) 타입의
       16. // 클래스 내부 상수는 예외입니다.
       17.  
       18. // 단, 클래스 상수의 주소를 구한다던지, 잘못 구현된 컴파일러가 정의를 달라고
       19. // 떼쓰는 경우에는 다음과 같이 별도의 정의를 제공해야 합니다.
       20.  
       21. const int GamePlayer::NumTurns; // NumTurns의 정의.
       22. // 이때 클래스 상수의 정의는 구현 파일에 둡니다.
       23. // 헤더 파일에는 두지 않습니다.
       24. // 정의에는 상수의 초기값이 있으면 안 되는데,
       25. // 왜냐하면 클래스 상수의 초기값은 해당 상수가
       26. // 선언된 시점에서 바로 주어지기 때문입니다.
       27.  
       28.  
       29. //-------------------------------------------------------------------
       30. // 조금 오래된 컴파일러의 경우 위의 문법을 받아들이지 않는 경우가 종종 있습니다.
       31. // 이유는 정적 클래스 멤버가 선언된 시점에 초기값을 주는 것이 대개 맞지 않다고
       32. // 판단하기 때문이죠. 이 경우 초기값을 상수의 '정의' 시점에 주도록 하십시오.
       33.  
       34. class CostEstimate {
       35. private:
       36. static const double FudgeFactor; // 정적 클래스 상수의 선언
       37. ... // 이것은 헤더 파일에 둡니다.
       38. };
       39.  
       40. const double // 정적 클래스 상수의 정의
       41. CostEstimate::FudgeFactor = 1.35; // 이것은 구현 파일에 둡니다.
       43. // 웬만한 경우 이것으로 충분합니다.
       44.  
       45.  
       46. //-------------------------------------------------------------------
       47. // 딱 한 가지 예외가 있다면 해당 클래스를 컴파일하는 도중에
       48. // 클래스 상수의 값이 필요할 때인데, 이를테면 배열 멤버를
       49. // 선언할 때가 대표적인 예입니다(컴파일러는 컴파일 과정에서
       50. // 이 배열의 크기를 알아야 한다며 버틸 것입니다).
       51.  
       52. // 그렇기 때문에 정수 타입의 정적 클래스 상수에 대한
       53. // 클래스 내 초기화를 금지하는 (표준에 어긋난) 구식 컴파일러에
       54. // 대한 배려로 '나열자 둔갑술(enum hack)'이라고
       55. // 알려진 방법을 생각할 수 있겠습니다.
       56.  
       57. class GamePlayer {
       58. private:
       59. enum { NumTurns = 5 }; // "나열자 둔갑술": NumTurns를
       60. // 5에 대한 기호식 이름으로 만듭니다.
       61. int scores[NumTurns];
       62. ...
       63. };
       64.  
       65. // 나열자 둔갑술을 이용한 상수에 대해서는 주소나
       66. // 참조자를 얻을 수 없으며, 이것을 의도적으로
       67. // 이용할 수 있습니다.
       68.  
       69. // 또한 나열자 둔갑술을 이용한 상수(enum)는
       70. // 어떠한 경우에도 #define처럼 어떤 형태의
       71. // 쓸데없는 메모리 할당도 저지르지 않습니다.
       72.  
       73. // 마지막으로 상당히 많은 코드에서 나열자 둔갑술이
       74. // 쓰이고 있으므로 알아두는 것이 좋습니다.

       
       
       예제 코드 접기
       
       
       

     • 함수처럼 쓰이는 매크로를 만들려면, #define 매크로보다 인라인 함수를 우선 생각합시다.

       예제 코드 보기
       
       
       

       1. //---------------------------------------------------------
       2. // 매크로 함수의 문제점
       3.  
       4. // a와 b 중에 큰 것을 f에 넘겨 호출합니다.
       5. #define CALL_WITH_MAX(a, b) f((a) > (b) ? (a) : (b))
       6.  
       7. int a = 5, b = 0;
       8.  
       9. CALL_WITH_MAX(++a, b); // a가 두 번 증가합니다.
       10. CALL_WITH_MAX(++a, b + 10); // a가 한 번 증가합니다.
       11.  
       12. // 이렇게 직관적이지 못한 코드가 생성됩니다.
       13.  
       14.  
       15. //---------------------------------------------------------
       16. // 반면 인라인 함수에 대한 템플릿은
       17. // 매크로 함수의 효율은 그대로 유지함은 물론
       18. // 정규 함수의 모든 동작 방식 및 타입 안전성까지
       19. // 완벽히 취할 수 있습니다.
       20.  
       21. template <typename T>
       22. inline void callWithMax(const T& a, const T& b)
       23. {
       24. f(a > b ? a : b);
       25. }
       26.  
       27. // T가 정확히 무슨 타입인지 모르기 때문에,
       28. // 매개변수로 상수 객체에 대한 참조자를
       29. // 씁니다.

       
       
       예제 코드 접기
       
       
       

  3. 낌새만 보이면 const를 들이대 보자! / 59

     • const를 붙여 선언하면 컴파일러가 사용상의 에러를 잡아내는 데 도움을 줍니다. const는 어떤 유효범위에 있는 객체에도 붙을 수 있으며, 함수 매개변수 및 반환 타입에도 붙을 수 있으며, 멤버 함수에도 붙을 수 있습니다.

     • 컴파일러 쪽에서 보면 비트수준 상수성을 지켜야 하지만, 여러분은 개념적인(논리적인) 상수성을 사용해서 프로그래밍 해야 합니다.

       • 비트수준 상수성: 어떤 객체의 멤버 함수가 객체의 정적 멤버를 제외한 데이터 멤버를 건드리지 않은 경우에만 그 멤버 함수가 'const'임을 인정함
       • 개념적인(논리적인) 상수성: 상수 멤버 함수도 객체의 일부 몇 비트를 바꿀 수 있되 사용자 측에서 알아채지 못하도록(객체의 상태에 영향을 주지 않도록) 해야 함

     • 상수 멤버 및 비상수 멤버 함수가 기능적으로 서로 똑같게 구현되어 있을 경우에는 코드 중복을 피하는 것이 좋은데, 이때 비상수 버전이 상수 버전을 호출하도록 만드세요.

       예제 코드 보기
       
       
       

       1. class TextBlock {
       2. public:
       3.  
       4. ...
       6. const char& operator[](std::size_t position) const {
       7. ...
       8. ...
       9. ...
       10. return text[position];
       11. }
       13. char& operator[](std::size_t position) { // 상수 버전 op[]를 호출하고 끝
       14. return const_cast<char&>( // op[]의 반환 타입에 캐스팅을 적용,
       15. // const를 떼어냅니다.
       16. static_cast<const TextBlock&> // *this의 타입에 const를 붙입니다.
       17. (*this)[position] // op[]의 상수 버전을 호출합니다.
       18. );
       19. }
       21. ...
       23. };

       
       
       예제 코드 접기
       
       
       

  4. 객체를 사용하기 전에 반드시 그 객체를 초기화 하자 / 70

     • 기본제공 타입의 객체는 직접 손으로 초기화합니다. 경우에 따라서 저절로 되기도 하고 안 되기도 하기 때문입니다.

     • 생성자에서는, 데이터 멤버에 대한 대입문을 생성자 본문 내부에 넣는 방법으로 멤버를 초기화하지 말고 멤버 초기화 리스트를 즐겨 사용합시다. 그리고 초기화 리스트에 데이터 멤버를 나열할 때는 클래스에 각 데이터 멤버가 선언된 순서와 똑같이 나열합시다.

     • 여러 번역 단위에 있는 비지역 정적 객체들의 초기화 순서 문제는 피해서 설계해야 합니다. 비지역 정적 객체를 지역 정적 객체로 바꾸면 됩니다.

       예제 코드 보기
       
       
       

       1. class FileSystem { ... };
       2.  
       3. FileSystem& tfs(void) // 이 함수는 FileSystem 클래스 안에
       4. { // 정적 멤버로 들어가도 됩니다.
       5.  
       6. static FileSystem fs; // 지역 정적 객체를 정의하고 초기화 합니다.
       7. return fs; // 이 객체에 대한 참조자를 반환합니다.
       8. } // 지역 정적 객체는 함수가 처음 불릴 때
       9. // 반드시 초기화 됩니다.
       10. class Directory { ... };
       11.  
       12. Directory::Directory( params )
       13. {
       14. ... // tfs의 참조자였던 것이 tfs()로 바뀌었습니다.
       15. std::size_t disks = tfs().numDisks();
       16. ...
       17. }

       
       
       예제 코드 접기
       
       
       

• Chapter 2   생성자, 소멸자 및 대입 연산자

  5. C++가 은근슬쩍 만들어 호출해 버리는 함수들에 촉각을 세우자 / 81

     • 컴파일러는 경우에 따라 클래스에 대해 기본 생성자, 복사 생성자, 복사 대입 연산자, 소멸자를 암시적으로 만들어 놓을 수 있습니다.

  6. 컴파일러가 만들어낸 함수가 필요 없으면 확실히 이들의 사용을 금해 버리자 / 85

     • 컴파일러에서 자동으로 제공하는 기능을 허용치 않으려면, 대응되는 멤버 함수를 private로 선언한 후에 구현은 하지 않은 채로 두십시오. Uncopyable과 비슷한 기본 클래스를 쓰는 것도 한 방법입니다.

       Uncopyable 예제 코드 보기
       
       
       

       1. class Uncopyable {
       2. protected: // 파생된 객체에 대해서
       3. Uncopyable(void) {} // 생성과 소멸을
       4. ~Uncopyable(void) {} // 허용합니다.
       6. private:
       7. Uncopyable(const Uncopyable&); // 하지만 복사는 방지합니다.
       8. Uncopyable& operator=(const Uncopyable&);
       9. };
       10.  
       11. class HomeForSale: private Uncopyable { // 복사 생성자도,
       12. ... // 복사 대입 연산자도
       13. }; // 이제는 선언되지 않습니다.

       
       
       Uncopyable 예제 코드 접기
       
       
       

  7. 다형성을 가진 기본 클래스에서는 소멸자를 반드시 가상 소멸자로 선언하자 / 89

     • 다형성을 가진 기본 클래스에는 반드시 가상 소멸자를 선언해야 합니다. 즉, 어떤 클래스가 가상 함수를 하나라도 갖고 있으면, 이 클래스의 소멸자도 가상 소멸자이어야 합니다.

       기본 클래스의 소멸자가 가상이 아닌 경우, 파생 클래스의 객체를 기본 클래스의 포인터에 담아 소멸(delete)시킬때, 기본 클래스의 소멸자만 호출되어 자원이 누출될 수 있습니다.

     • 기본 클래스로 설계되지 않았거나 다형성을 갖도록 설계되지 않은 클래스에는 가상 소멸자를 선언하지 말아야 합니다.

  8. 예외가 소멸자를 떠나지 못하도록 붙들어 놓자 / 95

     • 소멸자에서는 예외가 빠져나가면 안 됩니다. 만약 소멸자 안에서 호출된 함수가 예외를 던질 가능성이 있다면, 어떤 예외든지 소멸자에서 모두 받아낸 후에 삼켜 버리든지 프로그램을 끝내든지 해야 합니다.

       발생한 예외를 처리하기 위해 스택 되감기를 하는 도중, (소멸자에서)또 다른 예외가 발생하면 상황에 따라 프로그램이 종료되던지, 정의되지 않은 동작을 보이게 됩니다. 따라서 소멸자에서 예외가 빠져나가도록 두면 안됩니다.
       
       예제 코드 보기
       
       
       

       1. //-----------------------------------------------------------------------------
       2. // close에서 예외가 발생하면 프로그램을
       3. // 바로 끝냅니다. 대개 abort를 호출합니다.
       4. DBConn::~DBConn(void)
       5. {
       6. try { db.close(); }
       7. catch (...) {
       8. close 호출이 실패했다는 로그를 작성합니다;
       9. std::abort();
       10. }
       11. }
       12.  
       13. // 에러가 발생한 후에 프로그램을 실행을
       14. // 계속할 수 없는 상황이라면 꽤 괜찮은
       15. // 선택입니다.
       16.  
       17.  
       18. //-----------------------------------------------------------------------------
       19. // close를 호출한 곳에서 일어난 예외를
       20. // 삼켜 버립니다.
       21. DBConn::~DBConn(void)
       22. {
       23. try { db.close(); }
       24. catch (...) {
       25. close 호출이 실패했다는 로그를 작성합니다;
       26. }
       27. }
       28.  
       29. // 대부분의 경우에서 예외 삼키기는
       30. // 그리 좋은 발상이 아닙니다.
       31. // 무엇이 잘못됐는지를 알려 주는 정보가
       32. // 묻혀 버리기 때문입니다.
       33.  
       34. // 예외 삼키기를 선택한 것이
       35. // 제대로 빛을 보려면,
       36. // 발생한 예외를 그냥 무시한
       37. // 뒤라도 프로그램이 신뢰성
       38. // 있게 실행을 지속할 수 있어야
       39. // 합니다.

       
       
       예제 코드 접기
       
       
       

     • 어떤 클래스의 연산이 진행되다가 던진 예외에 대해 사용자가 반응해야 할 필요가 있다면, 해당 연산을 제공하는 함수는 반드시 보통의 함수(즉, 소멸자가 아닌 함수)이어야 합니다.

       예제 코드 보기
       
       
       

       1. class DBConn {
       2. public:
       3. ...
       5. void close(void) { // 사용자 호출을 배려(?) 해서
       6. db.close(); // 새로 만든 함수
       7. closed = true;
       8. }
       10. ~DBConn(void) {
       11. if (!closed)
       12. try { // 사용자가 연결을 안 닫았으면
       13. db.close(); // 여기서 닫아 봅니다.
       14. }
       15. catch (...) { // 연결을 닫다가 실패하면,
       16. close 호출이 실패했다는 로그를 작성합니다;
       17. ... // 실패를 알린 후에
       18. } // 실행을 끝내거나 예외를 삼킵니다.
       19. }
       21. private:
       22. DBConn db;
       23. bool closed;
       24. };
       25.  
       26. // close 호출의 책임을 DBConn의 소멸자에서
       27. // DBConn의 사용자로 떠넘기는 방법입니다.
       28.  
       29. // 사용자는 close가 발생한 예외를
       30. // 처리할 필요가 있다면 DBConn::close
       31. // 함수를 try 블록 내에서 호출하여
       32. // 예외 처리를 할 수 있습니다.
       33.  
       34. // 반면 예외 처리를 할 필요가 없다면
       35. // DBConn의 소멸자가 예외를 삼키거나,
       36. // 프로그램을 종료시키도록 두면 됩니다.

       
       
       예제 코드 접기
       
       
       

  9. 객체 생성 및 소멸 과정 중에는 절대로 가상 함수를 호출하지 말자 / 99

     • 생성자 혹은 소멸자 안에서 가상 함수를 호출하지 마세요. 가상 함수라고 해도, 지금 실행중인 생성자나 소멸자에 해당되는 클래스의 파생 클래스 쪽으로는 내려가지 않으니까요.

  10. 대입 연산자는 *this의 참조자를 반환하게 하자 / 105

      • 대입 연산자는 *this의 참조자를 반환하도록 만드세요.

        이것은 단순 대입형 연산자 뿐만 아니라, 모든 형태의 대입 연산자(예를 들어 +=)에서 지켜져야 합니다. 이러한 관례를 따르지 않아도 컴파일은 되지만, 관례를 따르는 편이 여러 모로 좋습니다. 헷갈린다면, int(기본 제공 타입)의 작동 원리대로 만드세요.

  11. operator=에서는 자기대입에 대한 처리가 빠지지 않도록 하자 / 106

      • operator=을 구현할 때, 어떤 객체가 그 자신에 대입되는 경우를 제대로 처리하도록 만듭시다. 원본 객체와 복사대상 객체의 주소를 비교해도 되고, 문장의 순서를 적절히 조정할 수도 있으며, 복사 후 맞바꾸기 기법을 써도 됩니다.

        복사 후 맞바꾸기 예제 코드 보기
        
        
        

        1. class Widget {
        2. ...
        3. void swap(Widget &rhs); // *this의 데이터 및 rhs이 데이터를 맞바꿉니다.
        4. ...
        5. };
        6.  
        7. Widget& Widget::operator=(const Widget& rhs)
        8. {
        9. Widget temp(rhs); // rhs의 데이터에 대해 사본을 하나 만듭니다.
        10. swap(temp); // *this의 데이터를 그 사본의 것과 맞바꿉니다.
        11. return *this;
        12. }
        13.  
        14. Widget& Widget::operator=(Widget rhs) // rhs는 넘어온 원래 객체의 사본입니다.
        15. { // (값에 의한 전달)
        17. swap(rhs); // *this의 데이터를 이 사본의
        18. // 데이터와 맞바꿉니다.
        19. return *this;
        20. }

        
        
        복사 후 맞바꾸기 예제 코드 접기
        
        
        

      • 두 개 이상의 객체에 대해 동작하는 함수가 있다면, 이 함수에 넘겨지는 객체들이 사실 같은 객체인 경우에 정확하게 동작하는지 확인해 보세요.

  12. 객체의 모든 부분을 빠짐없이 복사하자 / 111

      • 객체 복사 함수는 주어진 객체의 모든 데이터 멤버 및 모든 기본 클래스 부분을 빠뜨리지 말고 복사해야 합니다.

      • 클래스의 복사 함수 두 개(복사 생성자, 복사 대입 연산자)를 구현할 때, 한쪽을 이용해서 다른 쪽을 구현하려는 시도는 절대로 하지 마세요. 그 대신, 공통된 동작을 제3의 함수에다 분리해 놓고 양쪽에서 이것을 호출하게 만들어서 해결합시다.

• Chapter 3   자원 관리

  13. 자원 관리에는 객체가 그만 / 118

      • 자원 누출을 막기 위해, 생성자 안에서 자원을 획득하고 소멸자에서 그것을 해제하는 RAII(Resource Acquisition Is Initialization)객체를 사용합시다.

      • 일반적으로 널리 쓰이는 RAII 클래스는 tr1::shared_ptr 그리고 auto_ptr입니다. 이 둘 가운데 tr1::shared_ptr이 복사 시의 동작이 직관적이기 때문에 대개 더 좋습니다. 반면, auto_ptr은 복사되는 객체(원본 객체)를 null로 만들어 버립니다.

  14. 자원 관리 클래스의 복사 동작에 대해 진지하게 고찰하자 / 123

      • RAII 객체의 복사는 그 객체가 관리하는 자원의 복사 문제를 안고 가기 때문에, 그 자원을 어떻게 복사하느냐에 따라 RAII객체의 복사 동작이 결정됩니다.

      • RAII 클래스에 구현하는 일반적인 복사 동작은 복사를 금지하거나, 참조 카운팅을 해 주는 선으로 마무리하는 것입니다. 하지만 이 외의 방법도 가능하니 참고해 둡시다.

        RAII객체가 복사될 때 이루어져야 할 동작 들 중 하나
        • 복사를 금지합니다.
        • 관리하고 있는 자원에 대해 참조 카운팅을 수행합니다.(tr1::shared_ptr)
        • 관리하고 있는 자원을 진짜로 복사합니다.
        • 관리하고 있는 자원의 소유권을 옮깁니다.(auto_ptr)

  15. 자원 관리 클래스에서 관리되는 자원은 외부에서 접근할 수 있도록 하자 / 127

      • 실제 자원을 직접 접근해야 하는 기존 API들도 많기 때문에, RAII클래스를 만들 때는 그 클래스가 관리하는 자원을 얻을 수 있는 방법을 열어 주어야 합니다.

      • 자원 접근은 명시적 변환 혹은 암시적 변환을 통해 가능합니다. 안전성만 따지면 명시적 변환이 대체적으로 더 낫지만, 고객 편의성을 놓고 보면 암시적 변환이 괜찮습니다.

  16. new 및 delete를 사용할 때는 형태를 반드시 맞추자 / 132

      • new 표현식에 []를 썼으면, 대응되는 delete 표현식에도 []를 써야 합니다. 마찬가지로 new 표현식에 []를 안 썼으면, 대응되는 delete 표현식에도 []를 쓰지 말아야 합니다.

  17. new로 생성한 객체를 스마트 포인터에 저장하는 코드는 별도의 한 문장으로 만들자 / 135

      • new로 생성한 객체를 스마트 포인터로 넣는 코드는 별도의 한 문장으로 만듭시다. 이것이 안 되어 있으면, 예외가 발생될 때 디버깅하기 힘든 자원 누출이 초래될 수 있습니다.

        자원 누출 예제 코드 보기
        
        
        

        1. processWidget(std::tr1::shared_prt<Widget>(new Widget), priority());
        2. // 이런 식으로 코드를 작성한 경우 매개변수의 평가 순서가 정해지지 않은 C++에서
        3. // 다음과 같은 순서로 작동한 경우 메모리 누수가 일어날 수 있습니다.
        4.  
        5. // 1. "new Widget"을 실행합니다.
        6. // 2. priority를 호출합니다.
        7. // 3. tr1::shared_prt 생성자를 호출합니다.
        8. // 이 때 priority 호출 부분에서 예외가 발생하면
        9. // "new Widget"으로 만들어졌던 포인터가 유실됩니다.

        
        
        자원 누출 예제 코드 접기
        
        
        

• Chapter 4   설계 및 선언

  18. 인터페이스 설계는 제대로 쓰기엔 쉽게, 엉터리로 쓰기엔 어렵게 하자 / 139

      • 좋은 인터페이스는 제대로 쓰기엔 쉬우며 엉터리로 쓰기엔 어렵습니다. 인터페이스를 만들 때는 이 특성을 지닐 수 있도록 고민하고 또 고민합시다.

      • 인터페이스의 올바른 사용을 이끄는 방법으로는 인터페이스 사이의 일관성 잡아주기, 그리고 기본제공 타입과의 동작 호환성 유지하기가 있습니다.

      • 사용자의 실수를 방지하는 방법으로는 새로운 타입 만들기, 타입에 대한 연산을 제한하기, 객체의 값에 대해 제약 걸기, 자원 관리 작업을 사용자 책임으로 놓지 않기가 있습니다.

        ※ 예시
        • 새로운 타입 만들기: month, day등을 int를 사용하여 표현하기보다 별도의 타입을 만든다.
        • 타입에 대한 연산을 제한하기: a * b = c 같은 연산은 허용하지 않는 것이 좋다.
        • 객체의 값에 대해 제약 걸기: month가 갖는 값은 1~12월 밖에 없으므로 이 외의 값은 갖지 못하게 한다.
        • 자원 관리 작업을 사용자의 책임으로 놓지 않기: 팩토리 함수의 반환값을 스마트 포인터로 만든다면 사용자가 자원을 반환하지 않아 발생하는 자원의 누수를 막을 수 있다.

      • tr1::shared_prt은 사용자 정의 삭제자를 지원합니다. 이 특징 때문에 tr1::shared_ptr은 교차 DLL 문제를 막아 주며, 뮤텍스 등을 자동으로 잠금 해제하는 데(항목 14 참조) 쓸 수 있습니다.

        ※ 교차 DLL 문제: 객체 생성 시에 어떤 동적 링크 라이브러리(DLL)의 new를 썼는데 그 객체를 해제할 때는 이전의 DLL과 다른 DLL에 있는 delete를 써서 발생하는 문제
        
        예제 코드 보기
        
        
        

        1. std::tr1::shared_ptr<Investment> createInvestment(void)
        2. {
        3. std::tr1::shared_ptr<Investment> retVal(static_cast<Investment*>(0),
        4. getRidOfInvestment);
        5. // getRidOfInvestment는 Investment 객체를
        6. // 소멸시키는 삭제자 입니다.
        8. // shared_ptr은 두 번째 인자로 지정한
        9. // 삭제자를 통해 자원을 해제합니다.
        11. retVal = ... ; // retVal은 실제 객체를 가리키도록
        12. // 만듭니다.
        13. return retVal;
        14. }

        
        
        예제 코드 접기
        
        
        

  19. 클래스 설계는 타입 설계와 똑같이 취급하자 / 146

      • 클래스 설계는 타입 설계입니다. 새로운 타입을 정의하기 전에, 다음의 모든 고려사항을 빠짐없이 점검해 보세요.

        • 새로 정의한 타입의 객체 생성 및 소멸은 어떻게 이루어져야 하는가?
          이 부분에 따라 클래스의 생성자 및 소멸자의 설계가 바뀝니다. 그뿐 아니라 메모리 할당 연산자 함수를 오버로딩 하는 경우에는 이들 연산자 함수의 설계에도 영향을 미칩니다.
        • 객체 초기화는 객체 대입과 어떻게 달라야 하는가?
          생성자와 대입 연산자의 동작 및 둘 사이의 차이점을 결정짓는 요소입니다.
        • 새로운 타입으로 만든 객체가 값에 의해 전달되는 경우에 어떤 의미를 줄 것인가?
          여기서 잊으면 안되는 중요한 사실은 '값에 의한 전달'을 구현하는 쪽은 바로 복사생성자라는 것입니다.
        • 새로운 타입이 가질 수 있는 적법한 값에 대한 제약은 무엇으로 잡을 것인가?
          전부는 아니지만, 클래스의 데이터 멤버의 몇 가지 조합 값만은 반드시 유효해야 합니다. 이런 조합을 가리켜 클래스의 불변속성(invariant)이라고 하며, 클래스 차원에서 지켜주어야 하는 부분입니다. 이 불변속성에 따라 클래스 멤버 함수 안에서 해 주어야 할 에러 점검 루틴이 좌우되는데, 특히 생성자, 대입 연산자, 각종 "쓰기(setter)" 함수는 불변속성에 많이 좌우됩니다. 그뿐 아니라 불변속성은 함수가 발생시키는 예외에도 영향을 미치며, 예외 지정을 쓴다면 그 부분에도 영향을 줍니다.
        • 기존의 클래스 상속 계통망(inheritance graph)에 맞출 것인가?
          이미 갖고 있는 클래스로부터 상속을 시킨다고 하면, 클래스의 설계는 이들 클래스에 의해 제약을 받게 됩니다. 특히 멤버 함수의 가상성 여부가 가장 큰 요인입니다.(항목 34 및 36 참조) 만약 직접 만든 클래스를 다른 클래스들이 상속할 수 있게 만들자고 결정했다면, 이에 따라 멤버 함수의 가상 함수 여부가 결정됩니다.(특히 소멸자)
        • 어떤 종류의 타입 변환을 허용할 것인가?
          암시적 타입 변환과 명시적 타입 변환중 허용할 타입 변환을 정합니다.
        • 어떤 연산자와 함수를 두어야 의미가 있을까?
          클래스 안에 선언할 멤버 함수가 여기서 결정됩니다. 멤버 함수로 적당한 함수와 그렇지 않은 함수가 있을 것입니다.(항목 23, 24, 46 참조)
        • 표준 함수들 중 어떤 것을 허용하지 말 것인가?
          private로 선언해야 하는 함수가 여기에 해당됩니다.(항목 6 참조)
        • 새로운 타입의 멤버에 대한 접근권한을 어느 쪽에 줄 것인가?
          어떤 클래스 멤버를 public, protected, private 영역에 둘 것인가를 결정하는데 도움을 주게 될 질문입니다. 또한 프렌드로 만들어야 할 클래스 및 함수를 결정하는것은 물론이고 한 클래스를 다른 클래스에 중첩시켜도 되는가에 대한 결정을 내리는 데도 이 질문이 도움이 될 것입니다.
        • '선언되지 않은 인터페이스'로 무엇을 둘 것인가?
          만든 타입이 제공할 보장이 어떤 종류일까에 대한 질문으로서, 보장할 수 있는 부분은 수행 성능 및 예외 안전성(항목 29 참조) 그리고 자원 사용(잠금 및 동적 메모리 등) 입니다. 이들에 대해 여러분이 보장하겠다고 결정한 결과는 클래스 구현에 있어서 제약으로 작용하게 됩니다.
        • 새로 만드는 타입이 얼마나 일반적인가?
          정의하는 클래스가 타입 하나가 아니라 동일 계열의 타입군(family of types) 전체일지도 모릅니다. 만일 그렇다면 새로운 클래스가 아니라 새로운 클래스 템플릿을 정의해야 할 것입니다.
        • 정말로 꼭 필요한 타입인가?
          기존의 클래스에 대해 기능 몇 개가 아쉬워서 파생 클래스를 새로 만들기 보다는, 차라리 간단하게 비멤버 함수라든지 템플릿을 몇 개 더 정의하는 편이 낫습니다.

  20. '값에 의한 전달'보다는 '상수객체 참조자에 의한 전달' 방식을 택하는 편이 대개 낫다 / 149

      • '값에 의한 전달'보다는 '상수 객체 참조자에 의한 전달'을 선호합시다. 대체적으로 효율적일 뿐만 아니라 복사손실 문제까지 막아 줍니다.

      • 이번 항목에서 다룬 법칙은 기본제공 타입 및 STL 반복자, 그리고 함수 객체 타입에는 맞지 않습니다. 이들에 대해서는 '값에 의한 전달'이 더 적절합니다.

  21. 함수에서 객체를 반환해야 할 경우에 참조자를 반환하려고 들지 말자 / 154

      • 지역 스택 객체에 대한 포인터나 참조자를 반환하는 일, 혹은 힙에 할당된 객체에 대한 참조자를 반환하는 일, 또는 지역 정적 객체에 대한 포인터나 참조자를 반환하는 일은 그런 객체가 두 개 이상 필요해질 가능성이 있다면 절대로 하지 마세요(항목 4를 보시면 지역 정적 객체에 대한 참조자를 반환하도록 설계된 올바른 코드 예제를 찾을 수 있습니다. 최소한 단일 스레드 환경에서는 통합니다).

        예제 코드 보기
        
        
        

        1. //-------------------------------------------------------------------------
        2. // 잘못된 코드 1: 스택 객체에 대한 참조자 반환
        3. const Rational& operator*(const Rational& lhs, const Rational& rhs)
        4. {
        5. Rational result(lhs.n * rhs.n, lhs.d * rhs.d);
        6. return result; // 경고! 어이없는 코드입니다.
        7. }
        8.  
        9.  
        10. //-------------------------------------------------------------------------
        11. // 잘못된 코드 2: 힙에 할당된 객체에 대한 참조자 반환
        12. const Rational& operator*(const Rational& lhs, const Rational& rhs)
        13. { // 동적할당받아 반환합니다.
        14. Rational *result = new Rational(lhs.n * rhs.n, lhs.d * rhs.d);
        15. return *result; // 경고! 또 일 났네요. 일 났어!
        16. }
        17.  
        18. Rational w, x, y, z;
        19. w = x * y * z; // operator*(operator*(x, y), z)와 같습니다.
        20. // 이 경우 메모리 누수가 발생합니다.
        21.  
        22.  
        23. //-------------------------------------------------------------------------
        24. // 잘못된 코드 3: 지역 정적 객체에 대한 참조자 반환
        25. const Rational& operator*(const Rational& lhs, const Rational& rhs)
        26. { // 경고! 사고를 아주 3부작으로 치시는군요!
        27.  
        28. static Rational result; // 반환할 참조자가 가리킬 정적 객체
        30. result = ... ; // lhs와 rhs를 곱하고 그 결과를
        31. // result에 저장합니다.
        32. return result;
        33. }
        34.  
        35. Rational a, b, c, d;
        36.  
        37. if ((a * b) == (c * d)) {
        38. // 항상 이 문장 수행
        39. }
        40. else {
        41. // 이 문장은 절대로 수행되지 않음
        42. }
        43.  
        44.  
        45. //-------------------------------------------------------------------------
        46. // 올바른 코드: 반환 값 최적화(RVO: return value optimization)를 활용한 올바른 코드
        47. inline const Rational operator*(const Rational& lhs, const Rational& rhs)
        48. {
        49. return Rational(lhs.n * rhs.n, lhs.d * rhs.d);
        50. }
        51.  

        
        
        예제 코드 접기
        
        
        

  22. 데이터 멤버가 선언될 곳은 private 영역임을 명심하자 / 160

      • 데이터 멤버는 private 멤버로 선언합시다. 이를 통해 클래스 제작자는 문법적으로 일관성 있는 데이터 접근 통로를 제공할 수 있고, 필요에 따라서는 세밀한 접근 제어도 가능하며, 클래스의 불변속성을 강화할 수 있을 뿐 아니라, 내부 구현의 융통성도 발휘할 수 있습니다.

      • protected는 public보다 더 많이 '보호'받고 있는 것이 절대로 아닙니다.

        왜냐하면 파생 클래스에서는 여전히 protected 데이터 멤버에 직접 접근할 수 있기 때문입니다.

  23. 멤버 함수보다는 비멤버 비프렌드 함수와 더 가까워지자 / 164

      • 멤버 함수보다는 비멤버 비프렌드 함수를 자주 쓰도록 합시다. 캡슐화 정도가 높아지고, 패키징 유연성도 커지며, 기능적인 확장성도 늘어납니다.

        • 캡슐화 정도가 높아진다: 비멤버 비프렌드 함수는 private 데이터 멤버에 접근하는 함수의 수를 늘리지 않기 때문이다.
        • 패키징 유연성이 커진다: 반드시 사용해야 하는 핵심 기능들을 멤버함수로 만들어 하나의 헤더에 선언해 두고, 나머지 부가기능들은 같은 네임스페이스 내의 다른 헤더에 기능별로 분류하여 비멤버 비프렌드 함수로 선언해 두면 사용자는 필수 헤더와 사용하고자 하는 기능이 포함된 헤더만 include하여 라이브러리를 사용할 수 있다.
        • 기능적인 확장성이 높다: 사용자가 기능 확장을 원하는 클래스와 동일한 네임스페이스 안에 편의를 위한 비멤버 비프렌드 함수를 추가로 정의해 넣을 수 있다. 단 std네임스페이스에는 사용자가 내용을 추가해선 안 된다.

  24. 타입 변환이 모든 매개변수에 대해 적용되어야 한다면 비멤버 함수를 선언하자 / 169

      • 어떤 함수에 들어가는 모든 매개변수(this 포인터가 가리키는 객체도 포함해서)에 대해 타입 변환을 해 줄 필요가 있다면, 그 함수는 비멤버이어야 합니다.

        예제 코드 보기
        
        
        

        1. class Rational { ... }; // 정수형을 암시적으로 유리수로 변환할 수 있습니다.
        2.  
        3. // 비멤버 함수입니다.
        4. const Rational operator*(const Rational& lhs, const Rational& rhs)
        5. {
        6. return Rational(lhs.numerator() * rhs.numerator(),
        7. lhs.denominator() * rhs.denominator());
        8. }
        9.  
        10. Rational oneFourth(1, 4);
        11. Rational result;
        12.  
        13. result = oneFourth * 2; // 이건 멤버함수여도 자동 형변환이 일어납니다.
        14. result = 2 * oneFourth; // 비멤버 함수일때만 자동 형변환이 일어납니다.

        
        
        예제 코드 접기
        
        
        

  25. 예외를 던지지 않는 swap에 대한 지원도 생각해 보자 / 173

      • std::swap이 여러분의 타입에 대해 느리게 동작할 여지가 있다면 swap 멤버 함수를 제공합시다. 이 멤버 swap은 예외를 던지지 않도록 만듭시다.

        예제 코드 보기
        
        
        

        1. class Widget {
        2. public:
        3. ...
        4. void swap(Widget& other) {
        5. using std::swap; // std::swap을 이 함수 안으로 끌어올 수 있도록 만드는 문장
        7. swap(pImpl, other.pImpl); // Widget을 맞바꾸기 위해, 각 Widget의
        8. } // pImpl 포인터를 맞바꿉니다.
        9. ...
        10. private:
        11. WidgetImpl *pImpl; // 실제 Widget을 구현한 클래스의 포인터
        12. };

        
        
        예제 코드 접기
        
        
        

      • 멤버 swap을 제공했으면, 이 멤버를 호출하는 비멤버 swap(동일 네임스페이스)도 제공합니다. 클래스(템플릿이 아닌)에 대해서는, std::swap도 특수화해 둡시다.

        예제 코드 보기
        
        
        

        1. //-----------------------------------------------
        2. // Widget클래스가 템플릿이 아닌 경우에만 std::swap을 특수화 한다.
        3. // 왜냐하면 C++에서 함수의 부분 특수화를 지원하지 않기 때문이다.
        4. namespace std {
        5. template<> // std::swap의 특수화 버전
        6. void swap<Widget>(Widget& a, Widget& b)
        7. {
        8. a.swap(b); // Widget을 맞바꾸기 위해,
        9. } // swap 멤버 함수를 호출합니다.
        10. }
        11.  
        12.  
        13. //-----------------------------------------------
        14. // Widget클래스가 클래스 템플릿인 경우 대처 방법
        15. // std 네임 스페이스에는 어떤 것이라도 새로 '추가'할 수 없기 때문이다.
        16. namespace WidgetStuff {
        17. template <typename T>
        18. class Widget { ... };
        19. ...
        20. template <typename T>
        21. void swap(Widget<T>& a, Widget<T>& b)
        22. {
        23. a.swap(b);
        24. }
        25. }

        
        
        예제 코드 접기
        
        
        

      • 사용자 입장에서 swap을 호출할 때는, std::swap에 대한 using 선언을 넣어 준 후에 네임스페이스 한정 없이 swap을 호출합시다.

        ※ 이 항목의 첫 번째 예제 참조

      • 사용자 정의 타입에 대한 std 템플릿을 완전 특수화하는 것은 가능합니다. 그러나 std에 어떤 것이라도 새로 '추가'하려고 들지는 마십시오.

        ※ 이 항목의 두 번째 예제 참조

• Chapter 5   구현

  26. 변수 정의는 늦출 수 있는 데까지 늦추는 근성을 발휘하자 / 183

      • 변수 정의는 늦출 수 있을 때까지 늦춥시다. 프로그램이 더 깔끔해지며 효율도 좋아집니다.

        예제 코드 보기
        
        
        

        1. //----------------------------------------------------------------
        2. // 이 함수는 "encrypted" 변수를 너무 일찍 정의해 버립니다.
        3. std::string encryptPassword(const std::string& password)
        4. {
        5. using namespace std;
        7. string encrypted;
        9. if (password.length() < MinimumPasswordLength) {
        10. throw logic_error("Password is too short");
        11. }
        12. ... // 주어진 비밀번호를 암호화하여 encrypted
        13. // 변수에 넣는 데 필요한 일들을 여기서 합니다.
        14. return encrypted;
        15. }
        16.  
        17. // 이 경우 비밀번호의 길이가 짧아 예외를 던지게 되면
        18. // 쓸데없이 string을 생성 & 파괴 하게 됩니다.
        19.  
        20.  
        21. //----------------------------------------------------------------
        22. // 이 함수는 encrypted 변수가 필요해질 때까지 이 변수의 정의를
        23. // 늦추긴 했지만, 여전히 쓸데없이 비효율적입니다.
        24. std::string encryptPassword(const std::string& password)
        25. {
        26. ... // 길이를 점검하는 부분은 똑같으므로 생략
        28. std::string encrypted; // 기본 생성자에 의해 만들어지는 encrypted
        29. encrypted = password; // encrypted에 password를 대입
        31. encrypt(encrypted);
        32. return encrypted;
        33. }
        34.  
        35. // 이 경우 불필요한 기본 생성자가 호출됩니다.
        36.  
        37.  
        38. //----------------------------------------------------------------
        39. // 결국 여기까지 오다: encrypted를 정의하고 초기화 하는 가장 좋은 방법
        40. std::string encryptPassword(const std::string& password)
        41. {
        42. ... // 길이를 점검합니다.
        44. std::string encrypted(password); // 변수를 정의함과 동시에 초기화합니다.
        45. // 이때 복사 생성자가 쓰입니다.
        46. encrypt(encrypted);
        47. return encrypted;
        48. }
        49.  
        50.  
        51. //----------------------------------------------------------------
        52. // 루프 안에서 사용되는 변수의 생성에 관해...
        53.  
        54. // A 방법: 루프 바깥쪽에 정의
        55. Widget w;
        56. for (int i = 0; i < n; ++i) {
        57. w = i에 따라 달라지는 값;
        58. ...
        59. }
        60.  
        61. // B 방법: 루프 안쪽에 정의
        62. for (int i = 0; i < n; ++i) {
        63. Widget w(i에 따라 달라지는 값);
        64. ...
        65. }
        66.  
        67. // A 방법: 생성자 1번 + 소멸자 1번 + 대입 n번
        68. // B 방법: 생성자 n번 + 소멸자 n번
        69.  
        70. // 대입에 들어가는 비용이 생성자-소멸자 쌍보다 적게 나오는 경우에는 A 방법이 효율이 좋습니다.
        71. // 그렇지 않은 경우에는 물론 B 방법이 효율이 좋겠죠.
        72.  
        73. // 하지만 A 방법을 쓰면 프로그램의 이해도와 유지보수성이 역으로 안 좋아질 수도 있습니다.
        74. // 따라서
        75. // 1. 대입이 생성자-소멸자 쌍보다 비용이 덜 들고
        76. // 2. 전체 코드에서 수행 성능에 민감한 부분을 건드리는 중
        77. // 이라고 생각하지 않는다면, 앞뒤 볼 것 없이 B 방법으로 가는 것이 좋습니다.

        
        
        예제 코드 접기
        
        
        

  27. 캐스팅은 절약, 또 절약! 잊지 말자 / 187

      • 다른 방법이 가능하다면 캐스팅은 피하십시오. 특히 수행 성능에 민감한 코드에서 dynamic_cast는 볓 번이고 다시 생각하십시오. 설계 중에 캐스팅이 필요해졌다면, 캐스팅을 쓰지 않는 다른 방법을 시도해 보십시오.

        예제 코드 보기
        
        
        

        1. //---------------------------------------------------------------------
        2. // 아래 코드는 포인터 캐스팅의 위험성을 보여줍니다.
        3. class Base { ... };
        4.  
        5. class Derived: public Base { ... };
        6.  
        7. Derived d;
        8.  
        9. Derived *pd = &d;
        10. Base *pb = &d; // Derived* => Base*의 암시적 변환이 이루어집니다.
        11.  
        12. // 여기서 pd가 가리키는 주소와 pb가 가리키는
        13. // 주소가 다를 수도 있다는 사실이 중요합니다.
        14. // 따라서 어떤 객체의 주소를 char* 포인터로
        15. // 바꿔서(캐스팅 해서) 포인터 산술 연산을
        16. // 적용하는 등의 코드는 거의 항상 미정의 동작을
        17. // 낳을 수 있습니다.
        18.  
        19.  
        20. //---------------------------------------------------------------------
        21. // dynamic_cast를 피하는 법
        22.  
        23. // dynamic_cast가 사용된 코드
        24. class Window { ... };
        25.  
        26. class SpecialWindow: public Window {
        27. public:
        28. void blink(void);
        29. ...
        30. };
        31.  
        32. typedef
        33. std::vector<std::tr1::shared_ptr<Window> > VPW;
        34.  
        35. VPW winPtrs;
        36.  
        37. ...
        38.  
        39. // 그다지 바람직스럽지 않은 코드: dynamic_cast를 쓰고 있습니다.
        40. for (VPW::iterator iter = winPtrs.begin();
        41. iter != winPtrs.end();
        42. ++iter) {
        43. if (SpecialWindow *psw = dynamic_cast<SpecialWindow*>(iter->get()))
        44. psw->blink();
        45. }
        46.  
        47.  
        48. // dynamic_cast를 피하는 방법 1
        49. typedef std::vector<std::tr1::shared_ptr<SpecialWindow> > VPSW;
        50. ...
        51. // 더 괜찮은 코드: dynamic_cast가 없습니다.
        52. for (VPSW::iterator iter = winPtrs.begin();
        53. iter != winPtrs.end();
        54. ++iter)
        55. (*iter)->blink();
        57. // 이와 같은 식으로 구현하게 되면 Window에서
        58. // 파생될 수 있는 모든 녀석들에 대한 포인터를
        59. // 똑같은 컨테이너에 저장할 수는 없습니다.
        60. // 즉 다른 타입의 포인터를 담으려면 타입 안전성을 갖춘
        61. // 컨테이너가 여러 개가 필요할 것입니다.
        62.  
        63.  
        64. // dynamic_cast를 피하는 방법 2
        65. class Window {
        66. public:
        67. virtual void blink(void) {} // 기본 구현은 '아무 동작 안하기'입니다.
        68. ...
        69. };
        70.  
        71. class SpecialWindow: public Window {
        72. public:
        73. virtual void blink(void) { ... } // 이 클래스에서는 blink 함수가
        74. ... // 특정한 동작을 수행합니다.
        75. };
        76.  
        77. typedef std::vector<std::tr1::shared_ptr<Window> > VPW;
        78. VPW winPtrs; // 이 컨테이너는 Window에서
        79. // 파생된 모든 타입의 객체
        80. ... // (에 대한 포인터)들을 담습니다.
        81.  
        82. for (VPW::iterator iter = winPtrs.begin();
        83. iter != winPtrs.end();
        84. ++iter) // 놓치지 말고 잘 보세요.
        85. (*iter)->blink(); // dynamic_cast가 없습니다.

        
        
        예제 코드 접기
        
        
        

      • 캐스팅이 어쩔 수 없이 필요하다면, 함수 안에 숨길 수 있도록 해보십시오. 이렇게 하면 최소한 사용자는 자신의 코드에 캐스팅을 넣지 않고 이 함수롤 호출할 수 있게 됩니다.

        캐스팅을 해야 하는 코드를 내부 함수 속에 몰아 놓고, 그 안에서 일어나는 '천한' 일들은 이 함수를 호출하는 외부에서 알 수 없도록 인터페이스로 막아두는 식으로 해결하면 됩니다.

      • 구형 스타일의 캐스트를 쓰려거든 C++스타일의 캐스트를 선호하십시오. 발견하기도 쉽고, 설계자가 어떤 역할을 의도했는지가 더 자세하게 드러납니다.

        C++의 캐스트 연산자
        • const_cast: 객체의 상수성을 없애는 용도로 사용됩니다.
        • dynamic_cast: 안전한 다운캐스팅(safe downcasting)을 할 때 사용하는 연산자 입니다. 신경쓰일 정도로 런타임 비용이 높아 쓰지 않는 것이 좋습니다.
        • reinterpret_cast: 포인터를 int로 바꾸는 등의 하부 수준 캐스팅을 위한 연산자로서, 이것의 작용 결과는 구현환경에 의존적입니다.(이식성이 없습니다.) 이런 캐스트는 하부 수준 코드 외에는 거의 없어야 합니다.
        • static_cast: 암시적 변환[비상수 객체를 상수 객체로 바꾸거나(반대는 const_cast만 가능) int를 double로 바꾸는 등의 변환]을 강제로 진행할 때 사용합니다.

  28. 내부에서 사용하는 객체에 대한 "핸들"을 반환하는 코드는 되도록 피하자 / 196

      • 어떤 객체의 내부요소에 대한 핸들(참조자, 포인터, 반복자)을 반환하는 것은 되도록 피하세요. 캡슐화 정도를 높이고, 상수 멤버 함수가 객체의 상수성을 유지한 채로 동작할 수 있도록 하며, 무효참조 핸들이 생기는 경우를 최소화할 수 있습니다.

        무효참조 핸들(dangling handle) 예제 코드 보기
        
        
        

        1. class Rectangle {
        2. public:
        3. ...
        4. // 객체 내부의 핸들(참조자)을 반환합니다.
        5. const Point& upperLeft(void) const { return pData->ulhc; }
        6. const Point& lowerRight(void) const { return pData->lrhc; }
        7. ...
        8. };
        9.  
        10. class GUIObject { ... };
        11.  
        12. // Rectangle 객체를 값으로 반환합니다.
        13. const Rectangle boundingBox(const GUIObject& obj);
        14.  
        15. // pgo를 써서 임의의 GUIObject를 가리키도록 합니다.
        16. GUIObject *pgo;
        17. ...
        18. // pgo가 가리키는 GUIObject의
        19. // 사각 테두리 영역으로부터 좌측 상단 꼭짓점의
        20. // 포인터를 얻습니다.
        21. const Point *pUpperLeft =
        22. &(boundingBox(*pgo).upperLeft());
        24. // 바로 위의 문장이 끝날 때, pUpperLeft포인터가
        25. // 가리키는 Point객체는, boundingBox함수의
        26. // 반환값인 임시 Rectangle객체가 소멸되면서 함께
        27. // 소멸되어 버립니다.

        
        
        무효참조 핸들(dangling handle) 예제 코드 접기
        
        
        

  29. 예외 안전성이 확보되는 그날 위해 싸우고 또 싸우자! / 201

      • 예외 안전성을 갖춘 함수는 실행 중 예외가 발생되더라도 자원을 누출시키지 않으며 자료구조를 더럽힌 채로 내버려 두지 않습니다. 이런 함수들이 제공할 수 있는 예외 안전성 보장은 기본적인 보장, 강력한 보장, 예외 금지 보장이 있습니다.

        ※ 예외 안전성을 가진 함수라면 예외가 발생할 때 이렇게 동작해야 합니다.
        • 자원이 새도록 만들지 않습니다.
        • 자료구조가 더럽혀지는 것을 허용하지 않습니다.
        
        ※ 예외 안전성을 갖춘 함수는 아래의 세 가지 보장(guarantee) 중 하나를 제공합니다.
        • 기본적인 보장(basic guarantee): 함수 동작 중에 예외가 발생하면, 실행 중인 프로그램에 관련된 모든 것들을 유효한 상태로 유지하겠다는 보장입니다. 어떤 객체나 자료구조도 더럽혀지지 않으며, 모든 객체의 상태는 내부적으로 일관성을 유지하고 있습니다. 하지만 프로그램의 상태가 정확히 어떠한지는 예측이 안 될 수도 있습니다.(유효한 상태이기만 하면 어떤 상태든 될 수 있습니다.)
        • 강력한 보장(strong guarantee): 함수 동작 중에 예외가 발생하면, 프로그램의 상태를 절대로 변경하지 않겠다는 보장입니다. 이런 함수를 호출하는 것은 원자적인(atomic) 동작이라고 할 수 있습니다. 호출이 성공하면(예외가 발생하지 않으면) 마무리까지 완벽하게 성공하고, 호출이 실패하면 함수 호출이 없었던 것처럼 프로그램의 상태가 되돌아갑니다.
        • 예외불가 보장(nothrow guarantee): 예외를 절대로 던지지 않겠다는 보장입니다.
        현실적으로 대부분의 함수에 있어서 기본적인 보장과 강력한 보장 중 하나를 고르게 됩니다.

      • 강력한 예외 안전성 보장은 '복사-후-맞바꾸기' 방법을 써서 구현할 수 있지만, 모든 함수에 대해 강력한 보장이 실용적인 것은 아닙니다.

        ※ '복사-후-맞바꾸기'란 현재 객체의 복사본을 만들고 복사본을 수정한 뒤 수정에 성공한 경우 현재의 객체와 수정된 복사본을 바꿔치기 하는 것입니다.

      • 어떤 함수가 제공하는 예외 안전성 보장의 강도는, 그 함수가 내부적으로 호출하는 함수들이 제공하는 가장 약한 보장을 넘지 않습니다.

  30. 인라인 함수는 미주알고주알 따져서 이해해 두자 / 210

      • 함수 인라인은 작고, 자주 호출되는 함수에 대해서만 하는 것으로 묶어둡시다. 이렇게 하면 디버깅 및 라이브러리이 바이너리 업그레이드가 용이해지고, 자칫 생길 수 있는 코드 부풀림 현상이 최소화되며, 프로그램의 속력이 더 빨라질 수 있는 여지가 최고로 많아집니다.

        ※ 생성자와 소멸자는 인라인으로 만들기에 그리 좋지 않은 함수입니다. 왜냐하면 생성자나 소멸자 내에는 부모 클래스의 생성자나 소멸자, 그리고 멤버 객체들의 생성자나 소멸자를 호출하는 코드가 포함되기 때문입니다(생성자와 소멸자는 크기가 클 가능성이 큽니다).

      • 함수 템플릿이 대개 헤더 파일에 들어간다는 일반적인 부분만 생각해서 이들을 inline으로 선언하면 안 됩니다.

  31. 파일 사이의 컴파일 의존성을 최대로 줄이자 / 217

      • 컴파일 의존성을 최소화하는 작업의 배경이 되는 가장 기본적인 아이디어는 '정의' 대신에 '선언'에 의존하게 만들자는 것입니다. 이 아이디어에 기반한 두 가지 접근 방법은 핸들 클래스와 인터페이스 클래스입니다.

        • 객체 참조자 및 포인터로 충분한 경우에는 객체를 직접 쓰지 않습니다.
          어떤 타입에 대한 참조자 및 포인터를 선언할 때는 그 타입의 선언부만 필요합니다. 반면, 어떤 타입의 객체를 정의할 때는 그 타입의 정의가 준비되어 있어야 합니다.
        • 할 수 있으면 클래스 정의 대신 클래스 선언에 최대한 의존하도록 만듭니다.
          어떤 클래스를 사용하는 함수를 선언할 때는 그 클래스의 정의를 가져오지 않아도 됩니다. 심지어 그 클래스 객체를 값으로 전달하거나 반환하더라도 클래스 정의가 필요 없습니다.
        • 선언부와 정의부에 대해 별도의 헤더 파일을 제공합니다.
          "클래스를 둘로 쪼개자"라는 지침을 제대로 쓸 수 있도록 하려면 헤더 파일이 짝으로 있어야 합니다. 하나는 선언부를 위한 헤더 파일이고, 또 하나는 정의부를 위한 헤더 파일이겠지요. 당연한 이야기이겠지만 이 두 파일은 관리도 짝 단위로 해야 합니다. 한쪽에서 어떤 선언이 바뀌면 다른 쪽도 똑같이 바뀌어야 한다는 거죠. 그렇기 때문에, 라이브러리 사용자 쪽에서는 전방 선언 대신에 선언부 헤더 파일을 항상 #include해야 할 것이고, 라이브러리 제작자 쪽에서는 헤더 파일 두 개를 짝지어 제공하는 일을 잊으면 안 됩니다.
        
        핸들 클래스[pimpl 관용구(pointer to implementation)] 예제 코드 보기
        
        
        

        1. // 핸들 클래스 예제[pimpl 관용구("pointer to implementation")]
        2. //-----------------------------------------------------------------------------
        3. // 구현을 맡은 클래스의 이름이 PersonImpl이라고 하면
        4. // Person 클래스는 다음과 같이 정의할 수 있을 거에요.
        5. // "Person.h" 파일
        6. #include <string> // 표준 라이브러리의 구성요소는
        7. // 전방 선언을 하면 안 됩니다.
        9. #include <memory> // tr1::shared_ptr을 위한 헤더입니다.
        10.  
        11. class PersonImpl; // Person의 구현 클래스에 대한 전방 선언
        12.  
        13. class Date; // Person 클래스 안에서 사용하는
        14. class Address; // 것들에 대한 전방 선언
        15.  
        16. class Person {
        17. public:
        18. Person(const std::string& name, const Date& birthday,
        19. const Address& addr);
        20. std::string name(void) const;
        21. std::string birthDate(void) const;
        22. std::string address(void) const;
        23. ...
        24. private: // 구현 클래스 객체에 대한 포인터
        25. std::tr1::shared_ptr<PersonImpl> pImpl;
        26. };
        27.  
        28.  
        29. //-----------------------------------------------------------------------------
        30. // Person 클래스의 멤버 함수 중 두 개를 다음과 같이 구현해 보겠습니다.
        31. // "Person.cpp"파일
        32. #include "Person.h" // Person 클래스를 구현하고 있는 중이기 때문에
        33. // 이 Person의 클래스 정의를 #include해야 합니다.
        34.  
        35. #include "PersonImpl.h" // 이와 동시에 PersonImpl의 클래스 정의도
        36. // #include해야 하는데, 이렇게 하지 않으면
        37. // 멤버 함수를 호출할 수 없습니다. 잘 보시면
        38. // PersonImpl의 멤버 함수는 Person의 멤버 함수와
        39. // 일대일로 대응되고 있음을 알 수 있습니다.
        40. // 인터페이스가 똑같습니다.
        41.  
        42. Person::Person(const std::string& name, const Date& birthday,
        43. const Address& addr)
        44. : pImpl(new PersonImpl(name, birthday, addr))
        45. {}
        46.  
        47. std::string Person::name(void) const
        48. {
        49. return pImpl->name();
        50. }

        
        
        핸들 클래스[pimpl 관용구(pointer to implementation)] 예제 코드 접기
        
        
        인터페이스 클래스 예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 인터페이스 클래스 예제
        3. // Person 클래스의 인터페이스 클래스는 다음과 같이 만들어 볼 수 있겠습니다.
        4. // "Person.h" 파일
        5. #include <string>
        6. #include <memory>
        7.  
        8. class Person {
        9. public:
        10. virtual ~Person(void);
        12. virtual std::string name(void) const = 0;
        13. virtual std::string birthDate(void) const = 0;
        14. virtual std::string address(void) const = 0;
        15. ...
        16. static std::tr1::shared_ptr<Person> // 주어진 매개변수로 초기화되는 Person
        17. create(const std::string& name, // 객체를 새로 생성하고, 그것에 대한
        18. const Date& birthday, // tr1::shared_ptr을 반환합니다.
        19. const Address& addr); // (팩토리 함수 혹은 가상 생성자라 불립니다.)
        20. ...
        21. };
        22.  
        23. // 이 클래스르 코드에 써먹으려면 Person에 대한
        24. // 포인터 혹은 참조자로 프로그래밍하는 방법밖에 없습니다.
        25. // 순수 가상 함수를 포함한 클래스를 인스턴스로 만들기는
        26. // 불가능하니까요. 단 Person클래스의 파생 클래스는
        27. // 인스턴스로 만들 수 있습니다.
        28.  
        29.  
        30. //-----------------------------------------------------------------------------
        31. // 사용자 쪽에서는 다음과 같이 사용하면 됩니다.
        32. // 사용자의 cpp파일
        33. std::string name;
        34. Date dateOfBirth;
        35. Address address;
        36. ...
        37. // Person 인터페이스를 지원하는 객체 한 개를 생성합니다.
        38. std::tr1::shared_ptr<Person> pp(Person::create(name, dateOfBirth, address));
        39.  
        40. ...
        41.  
        42. std::cout << pp->name() // Person 인터페이스를 통해
        43.   << " was born on " // 그 객체를 사용합니다.
        44.   << pp->birthDate()
        45.   << " and now lives at "
        46.   << pp->address();
        47. ...
        48.  
        49.  
        50. //-----------------------------------------------------------------------------
        51. // RealPerson이라는 구체 클래스는 다음과 같이 구현될 수 있습니다.
        52. // "RealPerson.h" 파일
        53. #include "Person.h"
        54.  
        55. class RealPerson: public Person {
        56. public:
        57. RealPerson(const std::string& name, const Date& birthday,
        58. const Address& addr)
        59. : theName(name), theBirthDate(birthday), theAddress(addr)
        60. {}
        62. virtual ~RealPerson(void) {}
        64. std::string name(void) const; // 이들 멤버 함수에 대한 구현은 보이지
        65. std::string birthDate(void) const; // 않지만, 어떻게 되어 있을지는
        66. std::string address(void) const; // 쉽게 예상할 수 있을 거예요.
        68. private:
        69. std::string theName;
        70. Date theBirthDate;
        71. Address theAddress;
        72. };
        73.  
        74.  
        75. //-----------------------------------------------------------------------------
        76. // 이제 남은것은 Person::create 함수인데, 정말 간단하게 만들 수 있습니다.
        77. // "Person.cpp" 파일
        78. #include "Person.h"
        79. #include "RealPerson.h"
        80.  
        81. ...
        82.  
        83. std::tr1::shared_ptr<Person> Person::create(const std::string& name,
        84. const Date& birthday,
        85. const Address& addr)
        86. {
        87. return std::tr1::shared_ptr<Person>(new RealPerson(name, birthday,
        88. addr));
        89. }
        90.  
        91. ...

        
        
        인터페이스 클래스 예제 코드 접기
        
        
        

      • 라이브러리 헤더는 그 자체로 모든 것을 갖추어야 하며 선언부만 갖고 있는 형태여야 합니다. 이 규칙은 템플릿이 쓰이거나 쓰이지 않거나 동일하게 적용합시다.

• Chapter 6   상속, 그리고 객체 지향 설계

  32. public 상속 모형은 반드시 "is-a(...는 ...의 일종이다)"를 따르도록 만들자 / 232

      • public 상속의 의미는 "is-a(...는 ...의 일종)"입니다. 기본 클래스에 적용되는 모든 것들이 파생 클래스에 그대로 적용되어야 합니다. 왜냐하면 모든 파생 클래스 객체는 기본 클래스 객체의 일종이기 때문입니다.

        수학에서는 "정사각형은 직사각형의 일종이다." 라는 말은 참이 되지만 이를 그대로 public 상속으로 나타내면 안됩니다. 직사각형으로 할 수 있는 모든 일을 정사각형이 할 수 없기 때문입니다.(예를 들어 가로 길이만 변경한다던지...)
        ※ public 상속은 기본 클래스 객체가 가진 모든 것들이 파생 클래스 객체에도 그대로 적용된다고 단정하는 상속입니다.

  33. 상속된 이름을 숨기는 일은 피하자 / 239

      • 파생 클래스의 이름은 기본 클래스의 이름을 가립니다. public 상속에서는 이런 이름 가림 현상은 바람직하지 않습니다.

      • 가려진 이름을 다시 볼 수 있게 하는 방법으로, using 선언 혹은 전달 함수를 쓸 수 있습니다.

        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // using 선언을 이용하여 가려진 이름을 다시 볼 수 있게 하기.
        3. class Base {
        4. private:
        5. int x;
        7. public:
        8. virtual void mf1(void) = 0;
        9. virtual void mf1(int);
        10. virtual void mf2(void);
        11. void mf3(void);
        12. void mf3(double);
        13. ...
        14. };
        15.  
        16. class Derived: public Base {
        17. public:
        18. using Base::mf1; // Base에 있는 것들 중 mf1과 mf3을 이름으로 가린 것들을
        19. using Base::mf3; // Derived의 유효범위에서 볼 수 있도록 (또 public 멤버로)
        20. // 만듭니다.
        21. virtual void mf1(void);
        22. void mf3(void);
        23. void mf4(void);
        24. ...
        25. };
        26.  
        27.  
        28. //-----------------------------------------------------------------------------
        29. // 전달 함수를 이용하여 가려진 이름을 다시 볼 수 있게 하기.
        30. class Base {
        31. public:
        32. virtual void mf1(void) = 0;
        33. virtual void mf1(int);
        34. ... // 예전과 동일합니다.
        35. };
        36.  
        37. class Derived: public Base {
        38. public:
        39. virtual void mf1(void) { // 전달 함수입니다. 암시적으로
        40. Base::mf1(); // 인라인 함수가 됩니다.
        41. }
        42. };
        43.  
        44. ...
        45. Derived d;
        46. int x;
        47.  
        48. d.mf1(); // 좋습니다. Derived::mf1(매개변수 없는 버전)을
        49. // 호출합니다.
        50. d.mf1(x); // 에러입니다. Base::mf1()은 가려져 있습니다.
        51. // 매개변수가 있는 mf1()에 대해서도 전달 함수를 만들면
        52. // d.mf1(x)도 호출 가능합니다.

        
        
        예제 코드 접기
        
        
        

  34. 인터페이스 상속과 구현 상속의 차이를 제대로 파악하고 구별하자 / 246

      • 인터페이스 상속은 구현 상속과 다릅니다. public 상속에서, 파생 클래스는 항상 기본 클래스의 인터페이스를 모두 물려받습니다.

      • 순수 가상 함수는 인터페이스 상속만을 허용합니다.

      • 단순(비순수) 가상 함수는 인터페이스 상속과 더불어 기본 구현의 상속도 가능하도록 지정합니다.

        ※ 알고 보면 단순 가상 함수에서 함수 인터페이스와 기본 구현을 한꺼번에 지정하도록 내버려 두는 것은 위험할 수도 있습니다. 왜냐하면 새로운 파생 클래스를 만들 때, 실수로 몇 개의 가상 함수를 필요에 따라 재정의하는 것을 잊더라도 컴파일러가 경고를 주지 않기 때문입니다. 이를 해결하기 위한 방법은 아래 예제 코드를 참고하세요.
        
        예제 코드 보기
        
        
        

        1. //---------------------------------------------------------
        2. // 가상 함수의 인터페이스와 그 가상 함수의
        3. // 기본 구현을 잇는 연결 관계를 끊어 버리는 것입니다.
        4. class Airplane {
        5. public:
        6. virtual void fly(const Airport& destination) = 0;
        7. ...
        8. protected:
        9. void defaultFly(const Airport& destination);
        10. };
        11.  
        12. void Airplane::defaultFly(const Airport& destination)
        13. {
        14. 주어진 목적지로 비행기를 날려 보내는 기본 동작 원리를 가진 코드
        15. }
        16.  
        17. class ModelA: public Airplane {
        18. public:
        19. virtual void fly(const Airport& destination) {
        20. defaultFly(destination);
        21. }
        22. ...
        23. };
        24.  
        25. class ModelB: public Airplane {
        26. public:
        27. virtual void fly(const Airport& destination) {
        28. defaultFly(destination);
        29. }
        30. ...
        31. };
        32.  
        33. // 이제는 ModelA, ModelB와 전혀 다른 방식으로
        34. // 비행하는 ModelC가 자신과 맞지 않는 기본 구현을
        35. // 우연찮게 물려받을 가능성은 없어졌습니다.
        36. // fly가 순수 가상 함수로 선언되어 있어서,
        37. // ModelC 자신만의 버전을 재정의 하지 않고
        38. // ModelC 클래스의 인스턴스를 생성하려 들면
        39. // 컴파일러가 오류를 뱉어낼 것입니다.
        40.  
        41. class ModelC: public Airplane {
        42. public:
        43. virtual void fly(const Airport& destination);
        44. ...
        45. };
        46.  
        47. void Modelc::fly(const Airport& destination)
        48. {
        49. 주어진 목적지로 ModelC 비행기를 날려 보내는 코드
        50. }
        51.  
        52.  
        53. //---------------------------------------------------------
        54. // 또 다른 방법으로는 defaultFly함수의 구현을
        55. // 순수 가상 함수 fly의 구현으로 옮기는 방법이 있습니다.
        56. class Airplane {
        57. public:
        58. virtual void fly(const Airport& destination) = 0;
        59. ...
        60. };
        61.  
        62. // 순수 가상 함수의 구현
        63. void Airplane::fly(const Airport& destination)
        64. {
        65. 주어진 목적지로 비행기를 날려 보내는 기본 코드
        66. }
        67.  
        68. class ModelA: public Airplane {
        69. public:
        70. virtual void fly(const Airport& destination) {
        71. Airplane::fly(destination);
        72. }
        73. ...
        74. };
        75.  
        76. class ModelB: public Airplane {
        77. public:
        78. virtual void fly(const Airport& destination) {
        79. Airplane::fly(destination);
        80. }
        81. ...
        82. };
        83.  
        84. class ModelC: public Airplane {
        85. public:
        86. virtual void fly(const Airport& destination);
        87. ...
        88. };
        89.  
        90. void ModelC::fly(const Airport& destination)
        91. {
        92. 주어진 목적지로 ModelC 비행기를 날려 보내는 코드
        93. }
        94.  
        95. // 첫 번째 해결 방법과 거의 동일하지만, fly와 defaultFly가
        96. // 하나로 합쳐지는 바람에 함수 양쪽에 각기 다른 보호 수준을
        97. // 부여할 수 있는 융통성은 날아가고 말았습니다.
        98. // 그러니까 defaultFly에 들어 있음으로써
        99. // protected 영역에 있었던 코드가 이제는
        100. // public 영역에 있게 되었습니다.

        
        
        예제 코드 접기
        
        
        

      • 비가상 함수는 인터페이스 상속과 더불어 필수 구현의 상속도 가하도록 지정합니다.

  35. 가상 함수 대신 쓸 것들도 생각해 두는 자세를 시시때때로 길러 두자 / 256

      • 가상 함수 대신에 쓸 수 있는 다른 방법으로 NVI 관용구 및 전략 패턴을 들 수 있습니다. 이 중 NVI 관용구는 그 자체가 템플릿 메서드 패턴의 한 예입니다.

        • 비가상 인터페이스 관용구(NVI 관용구)를 사용합니다: 공개되지 않은 가상 함수를 비가상 public 멤버 함수로 감싸서 호출하는, 템플릿 메서드 패턴의 한 형태입니다.
          
          예제 코드 보기
          
          
          

          1. // ※ 비가상 함수 인터페이스(non-virtual interface: NVI) 관용구를 통한 템플릿 메서드 패턴
          2.  
          3. // public 비가상 멤버 함수를 통해
          4. // private 가상함수를 간접적으로 호출하게
          5. // 만드는 방법
          6. class GameCharacter {
          7. public:
          8. int healthValue(void) const // 파생 클래스는 이제 이 함수를 재정의할 수
          9. { // 없습니다.
          10.  
          11. ... // 사전 동작을 수행합니다.
          13. int retVal = doHealthValue(); // 실제 동작을 수행합니다.
          15. ... // 사후 동작을 수행합니다.
          17. return retVal;
          18. }
          19. ...
          20. private:
          21. virtual int doHealthValue(void) const // 파생 클래스는 이 함수를 재정의할 수
          22. { // 있습니다.
          24. ... // 캐릭터 체력치 계산을 위한
          25. // 기본 알고리즘 구현
          26. }
          27. };
          28.  
          29. // 가상 함수가 엄격하게 private일 필요는 없으나,
          30. // protected나 public으로 선언된다면
          31. // NVI 관용구를 쓰는 의미가 없어집니다.

          
          
          예제 코드 접기
          
          
          
        • 가상 함수를 함수 포인터 데이터 멤버로 대체합니다: 군더더기 없이 전략 패턴의 핵심만을 보여주는 형태입니다.
          
          예제 코드 보기
          
          
          

          1. // ※ 함수 포인터로 구현한 전략 패턴
          2.  
          3. // 캐릭터의 체력치 계산이 구태여
          4. // 어떤 캐릭터의 일부일 필요가 없습니다.
          5. class GameCharacter; // 전방 선언
          6.  
          7. // 체력치 계산에 대한 기본 알고리즘을 구현한 함수
          8. int defaultHealthCalc(const GameCharacter& gc);
          9.  
          10. class GameCharacter {
          11. public:
          12. typedef int(*HealthCalcFunc)(const GameCharacter&);
          14. explicit GameCharacter(HealthCalcFunc hcf = defaultHealthCalc)
          15. : healthFunc(hcf)
          16. {}
          18. int healthValue(void) const {
          19. return healthFunc(*this);
          20. }
          21. ...
          22. private:
          23. HealthCalcFunc healthFunc;
          24. };
          25.  
          26. // GameCharacter 클래스 계통에
          27. // 가상 함수를 심는 방법과 비교하면,
          28. // 꽤 재미있는 융통성을 갖고 있습니다.
          29.  
          30. // 1. 같은 캐릭터 타입으로부터 만들어진 객체(인스턴스)들도
          31. // 체력치 계산 함수를 각각 다르게 가질 수 있습니다.
          32. class EvilBadGuy: public GameCharacter {
          33. public:
          34. explicit EvilBadGuy(HealthCalcFunc hcf = defaultHealthCalc)
          35. : GameCharacter(hcf) {
          36. ...
          37. }
          38. ...
          39. };
          40.  
          41. // 다른 동작 원리로 구현된 체력치 계산 함수들
          42. int loseHealthQuickly(const GameCharacter&);
          43. int loseHealthSlowly(const GameCharacter&);
          44.  
          45. // 같은 타입인데도 체력치 변화가 다르게 나오는 캐릭터들
          46. EvilBadGuy ebg1(loseHealthQuickly);
          47. EvilBadGuy ebg2(loseHealthSlowly);
          48.  
          49. // 2. 게임이 실행되는 도중에 특정 캐릭터에 대한
          50. // 체력치 계산 함수를 바꿀 수 있습니다.
          51.  
          52. // 예를 들어 GameCharacter 클래스에서
          53. // setHealthCalculator라는 멤버 함수를
          54. // 제공하고 있다면 이를 통해 현재 쓰이는
          55. // 체력치 계산 함수의 교체가 가능해지는 것이죠.

          
          
          예제 코드 접기
          
          
          
        • 가상 함수를 tr1::function 데이터 멤버로 대체하여, 호환되는 시그너처를 가진 함수호출성 개체를 사용할 수 있도록 만듭니다: 역시 전략 패턴의 한 형태입니다.
          
          예제 코드 보기
          
          
          

          1. // ※ tr1::function으로 구현한 전략 패턴
          2.  
          3. // 함수 포인터 대신 tr1::function을
          4. // 사용하여 호환되는 시그너처를 가진 함수호출성
          5. // 개체를 사용할 수 있도록 만들 수도 있습니다.
          6. class GameCharacter; // 이전과 같습니다.
          7. int defaultHealthCalc(const GameCharacter& gc); // 이전과 같습니다.
          8.  
          9. class GameCharacter {
          10. public:
          11. // HealthCalcFunc는 함수호출성 객체로서, GameCharacter와 호환되는
          12. // 어떤 것이든 넘겨받아서 호출될 수 있으며 int와 호환되는 모든 타입의
          13. // 객체를 반환합니다.
          14. typedef std::tr1::function<int (const GameCharacter&)>
          15. HealthCalcFunc;
          16. explicit GameCharacter(HealthCalcFunc hcf = defaultHealthCalc)
          17. : healthFunc(hcf)
          18. {}
          20. int healthValue(void) const {
          21. return healthFunc(*this);
          22. }
          23. ...
          24. private:
          25. HealthCalcFunc healthFunc;
          26. };
          27.  
          28. // 함수 포인터를 사용한 것과 크게 다를 것은 없습니다.
          29. // 다른 점이 있다면 좀더 "일반화된" 함수포인터를
          30. // 사용했다는 것입니다.
          31.  
          32. // 덕분에 사용자 쪽에선 체력치 계산 함수를
          33. // 지정하는 데 있어서 머리가 멍해질 정도로
          34. // 불어난 융통성을 만끽할 수 있게 되었습니다.
          35.  
          36. // 반환 타입이 int와 호환되기만 하면 됩니다.
          37. short calcHealth(const GameCharacter&);
          38.  
          39. // 체력치 계산용 함수 객체를 만들기 위한 클래스
          40. struct HealthCalculator {
          41. int operator()(const GameCharacter&) const {
          42. ...
          43. }
          44. };
          45.  
          46. class GameLevel {
          47. public:
          48. // 반환 타입이 int와 호환되기만 하면 됩니다.
          49. float health(const GameCharacter&) const;
          50. ...
          51. };
          52.  
          53. // 바로 이전의 예제 코드에 나온 그것과 동일합니다.
          54. class EvilBadGuy: public GameCharacter {
          55. ...
          56. };
          57.  
          58. // 또 하나의 캐릭터 타입.
          59. // 생성자는 EvilBadGuy의 그것과
          60. // 똑같다고 가정합니다.
          61. class EyeCandyCharacter: public GameCharacter {
          62. ...
          63. };
          64.  
          65. // 체력치 계산을 위한 함수를 사용하는 캐릭터
          66. EvilBadGuy ebg1(calcHealth);
          67.  
          68. // 체력치 계산을 위한 함수를 사용하는 캐릭터
          69. EyeCandyCharacter eccl(HealthCalculator());
          70.  
          71. GameLevel currentLevel;
          72. ...
          73. // 체력치 계산을 위한 멤버 함수를 사용하는 캐릭터입니다.
          74. EvilBadGuy ebg2(
          75. std::tr1::bind(&GameLevel::health,
          76. currentLevel,
          77. _1)
          78. );

          
          
          예제 코드 접기
          
          
          
        • 한쪽 클래스 계통에 속해 있는 가상 함수를 다른 쪽 계통에 속해 있는 가상 함수로 대체합니다: 전략 패턴의 전통적인 구현 형태입니다.
          
          예제 코드 보기
          
          
          

          1. // ※ "고전적인" 전략 패턴
          2.  
          3. // 체력치 계산 함수를 나타내는 클래스 계통을
          4. // 아예 따로 만들고, 실제 체력치 계산 함수는
          5. // 이 클래스 계통의 가상 멤버 함수로 만드는
          6. // 것입니다.
          7.  
          8. class GameCharacter; // 전방 선언
          9.  
          10. class HealthCalcFunc {
          11. public:
          12. ...
          13. virtual int calc(const GameCharacter& gc) const {
          14. ...
          15. }
          16. ...
          17. };
          18.  
          19. HealthCalcFunc defaultHealthCalc;
          20.  
          21. class GameCharacter {
          22. public:
          23. explicit GameCharacter(HealthCalcFunc *phcf = &defaultHealthCalc)
          24. : pHealthCalc(phcf)
          25. {}
          27. int healthValue(void) const {
          28. return pHealthCalc->calc(*this);
          29. }
          30. ...
          31. private:
          32. HealthCalcFunc *pHealthCalc;
          33. };

          
          
          예제 코드 접기
          
          
          

      • 객체에 필요한 기능을 멤버 함수로부터 클래스 외부의 비멤버 함수로 옮기면, 그 비멤버 함수는 그 클래스의 public 멤버가 아닌 것들을 접근할 수 없다는 단점이 생깁니다.

      • tr1::function 객체는 일반화된 함수 포인터처럼 동작합니다. 이 객체는 주어진 대상 시그너처와 호환되는 모든 함수호출성 개체를 지원합니다.

  36. 상속받은 비가상 함수를 파생 클래스에서 재정의하는 것은 절대 금물! / 267

      • 상속받은 비가상 함수를 재정의하는 일은 절대로 하지 맙시다.

        • 만약 비가상 함수를 정말 원해서 재정의 한 것이고, 재정의한 비가상 함수는 반드시 기본 클래스와 그 파생 클래스에서 같은 동작을 해야 한다고 정한것도 진짜라면, 비가상 함수의 재정의로 인해 "모든 파생 클래스는 기본 클래스의 일종" 이라는 명제는 거짓이 됩니다. 이런 상황이라면 두 클래스를 public 상속 관계로 만들면 안 됩니다.
        • 클래스 D는 클래스 B로부터 public 상속을 받아 파생시킬 수밖에 없는 사정이 있고, 진짜로 D에서 B의 비가상 함수를 재정의해야 한다면, "비가상 함수는 클래스 파생에 상관없이 B에 대한 불변동작을 나타낸다."라는 점도 거짓이 됩니다. 이런 경우라면 그 비가상 함수는 가상 함수가 되어야 하는 것이 맞습니다.

  37. 어떤 함수에 대해서도 상속받은 기본 매개변수 값은 절대로 재정의하지 말자 / 270

      • 상속받은 기본 매개변수(디폴트 매개변수) 값은 절대로 재정의해서는 안 됩니다. 왜냐하면 기본 매개변수 값은 정적으로 바인딩되는 반면, 가상 함수(여러분이 오버라이드할 수 있는 유일한 함수이죠)는 동적으로 바인딩되기 때문입니다.

        ※ 가상함수에 기본 매개변수를 쓰는 것은 좋지 못한 생각입니다. 자세한 것은 예제 코드를 참고하세요.
        
        예제 코드 보기
        
        
        

        1. //------------------------------------------------------------------
        2. class Shape {
        3. public:
        4. enum ShapeColor { Red, Green, Blue };
        6. virtual void draw(ShapeColor color = Red) const = 0;
        7. ...
        8. };
        9.  
        10. class Rectangle: public Shape {
        11. public:
        12. virtual void draw(ShapeColor color = Red) const;
        13. ...
        14. };
        15.  
        16. // 에그머니, 언제 보아도 반갑지 않은 코드 중복입니다.
        17. // 더 안 좋은 것은 코드 중복에
        18. // 의존성 까지 걸려 있다는 점입니다.
        19.  
        20. // Shape 클래스에서 기본 매개변수 값이
        21. // 변하기라도 해 보세요. 이 값을
        22. // 반복하고 있는 파생 클래스는
        23. // 모두 그 값을 바꿔야 할 것입니다.
        24.  
        25.  
        26. //------------------------------------------------------------------
        27. // 이것은 비가상 인터페이스 관용구(NVI 관용구)
        28. // 를 써서 해결할 수 있습니다.
        29.  
        30. class Shape {
        31. public:
        32. enum ShapeColor { Red, Green, Blue };
        34. // 이제는 비가상 함수입니다.
        35. void draw(ShapeColor color = Red) const {
        36. doDraw(color); // 가상 함수를 호출합니다.
        37. }
        38. ...
        40. private:
        41. // 진짜 작업은 이 함수에서 이루어 집니다.
        42. virtual void doDraw(ShapeColor color) const = 0;
        43. };
        44.  
        45. class Rectangle: public Shape {
        46. public:
        47. ...
        48. private:
        49. // 기본 매개변수 값이 없습니다. 잘 보세요.
        50. virtual void doDraw(ShapeColor color) const;
        51. ...
        52. };

        
        
        예제 코드 접기
        
        
        

  38. "has-a(...는 ...를 가짐)" 혹은 "is-implemented-in-terms-of(...는 ...를 써서 구현됨)"를 모형화할 때는 객체 합성을 사용하자 / 275

      • 객체 합성(composition)의 의미는 public 상속이 가진 의미와 완전히 다릅니다.

        • public 상속의 의미: is-a(...는 ...의 일종)
        • 객체 합성의 의미: has-a(...는 ...를 가짐) 혹은 is-implemented-in-terms-of(...는 ...를 써서 구현됨)

      • 응용 영역에서 객체 합성의 의미는 has-a(...는 ...를 가짐)입니다. 구현 영역에서는 is-implemented-in-terms-of(...는 ...를 써서 구현됨)의 의미를 갖습니다.

        • 일상생활에서 볼 수 있는 사물을 본뜬 객체는 소프트웨어의 응용 영역에 속합니다.
        • 응용 영역에 속하지 않는 나머지(버퍼, 뮤텍스, 탐색 트리 등 순수하게 시스템 구현만을 위한 인공물) 객체는 소프트웨어의 구현 영역에 속합니다.
        여기서 객체 합성이 응용 영역의 객체들 사이에서 일어나면 has-a 관계입니다. 반면, 구현 영역에서 일어나면 그 객체 합성의 의미는 is-implemented-in-terms-of 관계를 나타내는 것입니다.

  39. private 상속은 심사숙고해서 구사하자 / 279

      • private 상속의 의미는 is-implemented-in-terms-of(...는 ...를 써서 구현됨)입니다. 대개 객체 합성과 비교해서 쓰이는 분야가 많지는 않지만, 파생 클래스 쪽에서 기본 클래스의 protected 멤버에 접근해야 할 경우 혹은 상속받은 가상 함수를 재정의해야 할 경우에는 private 상속이 나름대로 의미가 있습니다.

        ※ 가급적이면 private 상속보다는 객체 합성을 사용하되 꼭 필요한 경우에만 private 상속을 사용합시다.
        
        private 상속을 피하는 방법에 대한 예제 코드 보기
        
        
        

        1. class Timer {
        2. public:
        3. explicit Timer(int tickFrequency);
        5. virtual void onTick(void) const; // 일정 시간이 경과할 때마다 자동으로
        6. ... // 이것이 호출됩니다.
        7. };
        8.  
        9. class Widget: private Timer {
        10. private:
        11. virtual void onTick(void) const; // Widget 사용 자료 등을 수집합니다.
        12. ...
        13. };
        14.  
        15. // 이 경우 Widget은 Timer의 일종이 아니므로
        16. // private 상속을 사용하기에 적당합니다.
        17.  
        18. // 그러나 private 상속을 쓰지 않고도
        19. // 해결할 수 있는 방법이 있습니다.
        20.  
        21. class Widget {
        22. private:
        23. class WidgetTimer: public Timer {
        24. public:
        25. virtual void onTick(void) const;
        26. ...
        27. };
        29. WidgetTimer timer;
        30. };
        31.  
        32. // 아래와 같은 방법이 많이 쓰이는 이유는 다음과 같습니다.
        33.  
        34. // 첫째, Widget 클래스를 설계하는 데 있어서
        35. // 파생은 가능하게 하되, 파생 클래스에서 onTick을
        36. // 재정의할 수 없도록 설계 차원에서 막고 싶을 때
        37. // 유용합니다.
        38.  
        39. // 둘째, Widget의 컴파일 의존성을 최소화하고
        40. // 싶을 때 좋습니다. Widget이 Timer에서
        41. // 파생된 상태라면, Widget이 컴파일될 때
        42. // Timer의 정의도 끌어올 수 있어야 하기 때문에,
        43. // Timer.h 같은 헤더를 #include 해야
        44. // 할지도 모릅니다. 반면, 후자의 경우
        45. // WidgetTimer의 정의를 Widget으로부터
        46. // 빼내고 Widget이 WidgetTimer 객체에 대한
        47. // 포인터만 갖도록 만들어 두면, WidgetTimer
        48. // 클래스를 간단히 선언하는 것만으로도 컴파일
        49. // 의존성을 슬쩍 피할 수 있습니다.

        
        
        private 상속을 피하는 방법에 대한 예제 코드 접기
        
        
        

      • 객체 합성과 달리, private 상속은 공백 기본 클래스 최적화(EBO)를 활성화시킬 수 있습니다.이 점은 객체 크기를 가지고 고민하는 라이브러리 개발자에게 꽤 매력적인 특징이 되기도 합니다.

        공백 기본 클래스 예제 코드 보기
        
        
        

        1. // ※ 비정적 데이터 멤버, 가상 멤버 함수, 가상 기본 클래스를
        2. // 모두 갖고 있지 않은 클래스를 공백 클래스(empty class)
        3. // 라고 합니다.
        4.  
        5. // 공백 클래스는 개념적으로는 메모리 공간을 차지하지 않아야
        6. // 하지만, C++에는 "독립 구조의 객체는 반드시 크기가
        7. // 0을 넘어야 한다"라는 요상한 금기사항 같은 것이 있어서
        8. // 대부분의 경우 sizeof(char)와 같은 크기를 갖게 됩니다.
        9.  
        10. class Empty {};
        11.  
        12. class HoldsAnInt {
        13. private:
        14. int x;
        15. Empty e;
        16. };
        17.  
        18. // 따라서 sizeof(HoldsAnInt) > sizeof(int)
        19. // 와 같은 상황이 발생합니다. 게다가 위와 같이 공백 클래스가
        20. // 멤버로 선언된 경우 바이트 정렬에 의해 sizeof(char)
        21. // 보다 큰 공간을 차지하게 될 수도 있습니다.
        22.  
        23. // 반면, 다음과 같은 경우는, Empty 클래스가
        24. // 전혀 메모리를 차지하지 않게 됩니다.
        25.  
        26. class HoldsAnInt: private Empty {
        27. private:
        28. int x;
        29. };
        30.  
        31. // 즉 sizeof(HoldsAnInt) == sizeof(int)
        32. // 가 성립하며, 이를 공백 기본 클래스 최적화
        33. // (empty base optimization: EBO)
        34. // 라고 합니다.
        35.  
        36. // 이러한 최적화는 단일 상속하에서만 적용되고,
        37. // 다중 상속하에서는 적용되지 않습니다.

        
        
        공백 기본 클래스 예제 코드 접기
        
        
        

  40. 다중 상속은 심사숙고해서 사용하자 / 286

      • 다중 상속은 단일 상속보다 확실히 복잡합니다. 새로운 모호성 문제를 일으킬 뿐만 아니라 가상 상속이 필요해질 수도 있습니다.

        예제 코드 보기
        
        
        

        1. //-------------------------------------------------------------------
        2. // ※ 다중상속을 사용하는 경우 발생하는 모호성
        3. class BorrowableItem { // 라이브러리로부터 여러분이
        4. public: // 가져올 수 있는 어떤 것
        5.  
        6. void checkOut(void); // 라이브러리로부터 체크아웃합니다.
        7. ...
        8. };
        9.  
        10. class ElectronicGadget {
        11. private:
        12. bool checkOut(void) const; // 자체 테스트를 실시하고,
        13. ... // 성공 여부를 반환합니다.
        14. };
        15.  
        16. class Mp3Player: // MP3 플레이어를 위해
        17. public BorrowableItem, // 몇몇 라이브러리로부터
        18. public ElectronicGadget // 기능을 가져옵니다.(다중 상속)
        19. { ... };
        20.  
        21. Mp3Player mp;
        22.  
        23. mp.checkOut(); // 모호성 발생!
        24.  
        25. // C++컴파일러는 최적 일치 함수를 찾은 후에
        26. // 비로소 함수의 접근가능성을 점검합니다.
        27.  
        28. // 이 경우 두 checkOut함수는
        29. // C++ 규칙에 의한 일치도가 서로 같기
        30. // 때문에, 최적 일치 함수가 결정되지
        31. // 않습니다.
        32.  
        33. // 따라서 ElectronicGadget::checkOut
        34. // 함수의 접근가능성이 점검되는 순서조차
        35. // 오지 않습니다.
        36.  
        37. // 이러한 모호성을 해결하려면, 호출할
        38. // 기본 클래스의 함수를 다음과 같이
        39. // 손수 지정해 주어야 합니다.
        40.  
        41. mp.BorrowableItem::checkOut();
        42.  
        43.  
        44. //-------------------------------------------------------------------
        45. // ※ 가상 상속이 필요해지는 경우
        46. class File { ... };
        47.  
        48. class InputFile: public File { ... };
        49.  
        50. class OutputFile: public File { ... };
        51.  
        52. class IOFile:
        53. public InputFile,
        54. public OutputFile
        55. { ... };
        56.  
        57. // 이와 같은 경우 IOFile은 File 클래스를
        58. // 간접적으로 두 번 상속받게 됩니다.
        59.  
        60. // 만일 File 안에 fileName이라는
        61. // 멤버가 있다면, IOFile에는
        62. // fileName이 두 개가 있게 됩니다.
        63.  
        64. // 만일 fileName이 하나만 있어야 한다면,
        65. // 다음과 같이 File클래스를 가상 기본 클래스로
        66. // 만들어야 합니다.
        67.  
        68. class File { ... };
        69.  
        70. class InputFile: virtual public File { ... };
        71.  
        72. class OutputFile: virtual public File { ... };
        73.  
        74. class IOFile:
        75. public InputFile,
        76. public OutputFile
        77. { ... };
        78.  
        79. // 이제 IOFile 안에는 fileName이
        80. // 하나만 있게 됩니다.

        
        
        예제 코드 접기
        
        
        

      • 가상 상속을 쓰면 크기 비용, 속도 비용이 늘어나며, 초기화 및 대입 연산의 복잡도가 커집니다. 따라서 가상 기본 클래스에는 데이터를 두지 않는 것이 현실적으로 가장 실용적입니다.

        1. 구태여 쓸 필요가 없다면 가상 기본 클래스를 사용하지 마세요.(비가상 상속을 기본으로 삼으라 이겁니다.)
        2. 가상 기본 클래스를 정말 쓰지 않으면 안 될 상황이라면, 가상 기본 클래스에는 데이터를 넣지 않는 쪽으로 최대한 신경을 쓰세요.

      • 다중 상속을 적법하게 쓸 수 있는 경우가 있습니다. 여러 시나리오 중 하나는, 인터페이스 클래스로부터 public 상속을 시킴과 동시에 구현을 돕는 클래스로부터 private 상속을 시키는 것입니다.

        예제 코드 보기
        
        
        

        1. class IPerson { // 이 클래스가 나타내는 것은
        2. public: // 용도에 따라 구현될 인터페이스입니다.
        3. virtual ~IPerson(void);
        5. virtual std::string name(void) const = 0;
        6. virtual std::string birthDate(void) const = 0;
        7. };
        8.  
        9. class DatabaseID { ... }; // 아래에서 쓰입니다.
        10.  
        11.  
        12. class PersonInfo { // 이 클래스에는 IPerson 인터페이스를
        13. public: // 구현하는 데 유용한 함수가 들어
        14. explicit PersonInfo(DatabaseID pid); // 있습니다.
        15. virtual ~PersonInfo(void);
        17. virtual const char * theName(void) const;
        18. virtual const char * theBirthDate(void) const;
        20. virtual const char * valueDelimOpen(void) const;
        21. virtual const char * valueDelimClose(void) const;
        22. ...
        23. };
        24.  
        25. const char * PersonInfo::valueDelimOpen(void) const
        26. {
        27. return "["; // 기본적으로 지정된 시작 구분자
        28. }
        29.  
        30. const char * PersonInfo::valueDelimClose(void) const
        31. {
        32. return "]"; // 기본적으로 지정된 끝 구분자
        33. }
        34.  
        35. const char * PersonInfo::theName(void) const{
        36. // 반환 값을 위한 버퍼를 예약해 둡니다. 이 버퍼는
        37. // 정적 메모리이기 때문에, 자동으로 모두 0으로 초기화 됩니다.
        38. static char value[Max_Formatted_Field_Value_Length];
        40. // 시작 구분자를 value에 씁니다.
        41. std::strcpy(value, valueDelimOpen());
        43. value에 들어 있는 문자열에 이 객체의 name 필드를 덧붙입니다.
        44. (버퍼 오버런이 일어나지 않도록 주의해야 합니다!)
        46. // 끝 구분자를 value에 추가합니다.
        47. std::strcat(value, valueDelimClose());
        48. return value;
        49. }
        50.  
        51. // 요컨데 valueDelimOpen함수와 valueDelimClose함수를
        52. // 재정의 해야 theName 함수가 반환하는 이름의 포맷을
        53. // 변경할 수 있습니다.
        54.  
        55. class CPerson: public IPerson, private PersonInfo { // 다중 상속이 쓰였습니다.
        56. public:
        57. explicit CPerson(DatabaseID pid) : PersonInfo(pid) {}
        58.  
        59. virtual std::string name(void) const { // IPerson 클래스의
        60. return PersonInfo::theName(); // 순수 가상 함수에
        61. } // 대해 파생 클래스의
        62. virtual std::string birthDate(void) const { // 구현을 제공합니다.
        63. return PersonInfo::theBirthDate();
        64. }
        66. private:
        67. const char * valueDelimOpen(void) const { // 가상 함수들도
        68. return ""; // 상속되므로
        69. } // 이 함수들에 대한
        70. const char * valueDelimClose(void) const { // 재정의 버전을 만듭니다.
        71. return "";
        72. }
        73. };

        
        
        예제 코드 접기
        
        
        

• Chapter 7   템플릿과 일반화 프로그래밍

  41. 템플릿 프로그래밍의 천릿길도 암시적 인터페이스와 컴파일 타임 다형성부터 / 296

      • 클래스 및 템플릿은 모두 인터페이스와 다형성을 지원합니다.

      • 클래스의 경우, 인터페이스는 명시적이며 함수의 시그너처를 중심으로 구성되어 있습니다. 다형성은 프로그램 실행 중에 가상 함수를 통해 나타납니다.

        예제 코드 보기
        
        
        

        1. // 아래는 의미없는 예시용 코드입니다.
        2. class Widget {
        3. public:
        4. Widget(void);
        5. virtual ~Widget(void);
        6. virtual std::size_t size(void) const;
        7. virtual void normalize(void);
        8. void swap(Widget& other);
        9. ...
        10. };
        11.  
        12. void doProcessing(Widget& w)
        13. {
        14. if (w.size() > 10 && w != someNastyWidget) {
        15. Widget temp(w);
        16. temp.normalize();
        17. temp.swap(w);
        18. }
        19. }
        20.  
        21. // ※ w는 Widget 타입으로 선언되었기 때문에,
        22. //   w는 Widget 인터페이스를 지원해야 합니다.
        23. //   이 인터페이스를 소스 코드(Widget이 선언된
        24. //   .h 파일 등)에서 찾으면 이것이 어떤
        25. //   형태인지를 확인할 수 있으므로, 이런 인터페이스를
        26. //   가리켜 명시적 인터페이스라고 합니다.
        27. //   다시 말해 소스 코드에 명시적으로 드러나는
        28. //   인터페이스를 일컫습니다.
        29.  
        30. // ※ Widget의 멤버 함수 중 몇 개는
        31. //   가상 함수이므로, 이 가상 함수에 대한 호출은
        32. //   런타임 다형성에 의해 이루어집니다.
        33. //   다시 말해, 특정한 함수에 대한 실제 호출은
        34. //   w의 동적 타입을 기반으로 프로그램 실행 중,
        35. //   즉 런타임에 결정됩니다.

        
        
        예제 코드 접기
        
        
        

      • 템플릿 매개변수의 경우, 인터페이스는 암시적이며 유효 표현식에 기반을 두어 구성됩니다. 다형성은 컴파일 중에 템플릿 인스턴스화와 함수 오버로딩 모호성 해결을 통해 나타납니다.

        예제 코드 보기
        
        
        

        1. // 아래는 의미없는 예시용 코드입니다.
        2. template <typename T>
        3. void doProcessing(T& w)
        4. {
        5. if (w.size() > 10 && w != someNastyWidget) {
        6. T temp(w);
        7. temp.normalize();
        8. temp.swap(w);
        9. }
        10. }
        11.  
        12. // ※ w가 지원해야 하는 인터페이스는 이 템플릿 안에서
        13. //   w에 대해 실행되는 연산이 결정합니다. 지금의
        14. //   경우를 보면, size·normalize·swap
        15. //   멤버 함수를 지원해야 하는 쪽은 w의 타입
        16. //   즉 T입니다. 그 뿐 아니라 T는 복사 생성자도
        17. //   지원해야 하고, 부등 비교를 위한 연산도
        18. //   지원해야 합니다. 진짜 중요한 점은
        19. //   이 템플릿이 제대로 컴파일되려면 몇 개의
        20. //   표현식이 '유효(valid)'해야 하는데
        21. //   이 표현식들은 바로 T가 지원해야 하는
        22. //   암시적 인터페이스라는 점입니다.
        23.  
        24. // ※ w가 수반되는 함수 호출이 일어날 때
        25. //   템플릿의 인스턴스화가 일어납니다.
        26. //   이러한 인스턴스화가 일어나는 시점은
        27. //   컴파일 도중입니다. 인스턴스화를 진행하는
        28. //   함수 템플릿에 어떤 템플릿 매개변수가
        29. //   들어가느냐에 따라 호출되는 함수가
        30. //   달라지기 때문에, 이것을 가리켜
        31. //   컴파일 타임 다형성이라고 합니다.

        
        
        예제 코드 접기
        
        
        

  42. typename의 두 가지 의미를 제대로 파악하자 / 300

      • 템플릿 매개변수를 선언할 때, class 및 typename은 서로 바꾸어 써도 무방합니다.

      • 중첩 의존 타입 이름을 식별하는 용도에는 반드시 typename을 사용합니다. 단, 중첩 의존 이름이 기본 클래스 리스트에 있거나 멤버 초기화 리스트 내의 기본 클래스 식별자로 있는 경우에는 예외입니다.

        예제 코드 보기
        
        
        

        1. template <typename C> // 컨테이너에 들어 있는
        2. void print2nd(const C& container) // 두 번째 원소를 출력합니다.
        3. { // 도저히 제 정신으로 짠 코드가 아닙니다!
        4. if (container.size() >= 2) {
        5. C::const_iterator iter(container.begin());
        6. // 첫째 원소에 대한 반복자를 얻습니다.
        7. ++iter; // iter를 두 번째 원소로 옮깁니다.
        8. int value = *iter; // 이 원소를 다른 int로 복사합니다.
        9. std::cout << value; // 이 int를 출력합니다.
        10. }
        11. }
        12.  
        13. // iter의 타입은 C::const_iterator인데,
        14. // 템플릿 매개변수 C에 따라 달라지는 타입입니다.
        15. // 템플릿 내의 이름 중에 이렇게 템플릿 매개변수에
        16. // 종속된 것을 가리켜 의존 이름(dependent name)
        17. // 이라고 합니다. 의존 이름이 어떤 클래스 안에
        18. // 중첩되어 있는 경우가 있는데, 이를 중첩 의존 타입 이름
        19. // (nested dependent type name)이라고
        20. // 부릅니다. (필자는 중첩 의존 이름(nested
        21. // dependent name)이라고 줄여 부르기도 합니다.)
        22. // 위의 코드에서 C::const_iterator는
        23. // 중첩 의존 타입 이름입니다.
        24.  
        25. // 반면 int와 같이 템플릿 매개변수가 어떻든
        26. // 상관이 없는 타입 이름을 비의존 이름
        27. // (non-dependent name)이라고 합니다.
        28.  
        29.  
        30. template <typename C>
        31. void print2nd(const C& container)
        32. {
        33. C::const_iterator * x;
        34. ...
        35. }
        36.  
        37. // 이런 코드의 경우처럼 C::const_iterator가
        38. // 타입인지, C의 정적 데이터 멤버인지
        39. // (전역 변수 x와 곱하기) 모호한 경우가
        40. // 발생할 수 있습니다. 이 모호성을 해결하기 위해
        41. // C++의 구문 분석기는 템플릿 안에서 중첩 의존 이름을
        42. // 만나면, 프로그래머가 그것이 타입이라고 명시하지 않는 한
        43. // 타입이 아니라고 가정하도록 만들어 집니다.
        44.  
        45. // 따라서 중첩 의존 이름이 타입이라면 프로그래머는
        46. // 컴파일러에게 이 이름이 타입이라는 것을 알려줘야 합니다.
        47.  
        48. template <typename C> // typename 쓸 수 있음("class"와 같은 의미)
        49. void f(const C& container, // typename 쓰면 안 됨
        50. typename C::iterator iter); // typename 꼭 써야 함
        52. // 여기서 typename의 역할이 바로 중첩 의존 이름이
        53. // 타입이라는 것을 컴파일러에게 알려 주는 것입니다.
        54.  
        55. // 예외로 기본 클래스 리스트나 생성자 초기화 리스트에
        56. // 있는 중첩 의존 이름의 경우에는 typename을
        57. // 쓰면 안됩니다.
        58.  
        59. template <typename T>
        60. class Derived: public Base<T>::Nested { // 상속되는 기본 클래스 리스트:
        61. public: // typename 쓰면 안 됨
        62. explicit Derived(int x)
        63. : Base<T>::Nested(x) // 멤버 초기화 리스트에 있는 기본
        64. { // 클래스 식별자: typename 쓰면 안 됨
        66. typename Base<T>::Nested temp; // 중첩 의존 타입 이름이며
        67. ... // 기본 클래스 리스트에도 없고
        68. } // 멤버 초기화 리스트의 기본 클래스
        69. ... // 식별자도 아님: typename 필요
        70. };
        71.  
        72.  
        73. // 또 다른 예
        74. template <typename IterT>
        75. void workWithIterator(IterT iter)
        76. {
        77. // temp의 타입은 "IterT 타입의 객체로 가리키는 대상의 타입" 입니다.
        78. typename std::iterator_traits<IterT>::value_type temp(*iter);
        79. ...
        80. }
        81.  
        82. // 타입 이름이 너무 길어 typedef로 이름을 만듭니다.
        83.  
        84. template <typename IterT>
        85. void workWithIterator(IterT iter)
        86. {
        87. // 특성정보 클래스에 속한 value_type 등의 멤버 이름에 대해
        88. // typedef 이름을 만들 때는 그 멤버 이름과 똑같이 짓는 것이
        89. // 관례로 되어 있습니다.
        90. typedef typename std::iterator_traits<IterT>::value_type value_type;
        92. value_type temp(*iter);
        93. ...
        94. }
        95.  
        96. // typedef typename 처럼 연달아 나오는 것이
        97. // 어색할 수 있으나, 이렇게 써야 적법한 문장이
        98. // 됩니다.

        
        
        예제 코드 접기
        
        
        

  43. 템플릿으로 만들어진 기본 클래스 안의 이름에 접근하는 방법을 알아 두자 / 306

      • 파생 클래스 템플릿에서 기본 클래스 템플릿의 이름을 참조할 때는, "this->"를 접두사로 붙이거나 기본 클래스 한정문을 명시적으로 써 주는 것으로 해결합시다.

        예제 코드 보기
        
        
        

        1. //---------------------------------------------------------------------------------------
        2. class MsgInfo { ... }; // 메시지 생성에 사용되는
        3. // 정보를 담기 위한 클래스
        4. template <typename Company>
        5. class MsgSender {
        6. public:
        7. ... // 생성자, 소멸자, 등등
        8. void sendClear(const MsgInfo& info) {
        9. std::string msg;
        10. info로부터 msg를 만듭니다;
        12. Company c;
        13. c.sendCleartext(msg);
        14. }
        15. ...
        16. };
        17.  
        18. // 여기서 메시지를 보낼 때마다 관련 정보를
        19. // 로그로 남기고 싶어서 파생 클래스를
        20. // 만든다고 가정합니다.
        21.  
        22. template <typename Company>
        23. class LoggingMsgSender: public MsgSender<Company> {
        24. public:
        25. ... // 생성자, 소멸자, 등등
        26. void sendClearMsg(const MsgInfo& info) {
        27. "메시지 전송 전" 정보를 로그에 기록합니다;
        29. sendClear(info); // 기본 클래스의 함수를 호출하는데,
        30. // 이 코드는 컴파일되지 않습니다.
        31. "메시지 전송 후" 정보를 로그에 기록합니다;
        32. }
        33. ...
        34. };
        35.  
        36. // 컴파일러가 LoggingMsgSender 클래스 템플릿의 정의와
        37. // 마주칠 때, 컴파일러는 대체 이 클래스가 어디서 파생된 것인지를
        38. // 모른다는 것이 문제입니다. MsgSender<Company>에서
        39. // 파생되었지만, Company는 템플릿 매개변수이고, 이 템플릿
        40. // 매개변수는 LoggingMsgSender가 인스턴스로 만들어질 때
        41. // 까지 무엇이 될지 알 수 없습니다.
        42.  
        43. // 예를 들면 MsgSender 클래스가 특정한 Company 타입에
        44. // 대해서 sendClear 멤버 함수를 갖지 않도록 특수화 되었을
        45. // 수도 있습니다.
        46.  
        47. // 이를 해결하기 위한 방법은 세 가지나 있습니다.
        48.  
        49.  
        50. //---------------------------------------------------------------------------------------
        51. // 첫째, 기본 클래스 함수에 대한 호출문 앞에 "this->"를 붙입니다.
        52. template <typename Company>
        53. class LoggingMsgSender: public MsgSender<Company> {
        54. public:
        55. ...
        56. void sendClearMsg(const MsgInfo& info) {
        57. "메시지 전송 전" 정보를 로그에 기록합니다;
        59. this->sendClear(info); // 좋습니다. sendClear가
        60. // 상속되는 것으로 가정합니다.
        61. "메시지 전송 후" 정보를 로그에 기록합니다;
        62. }
        63. ...
        64. };
        65.  
        66.  
        67. //---------------------------------------------------------------------------------------
        68. // 둘째, using 선언을 이용합니다.
        69. template <typename Company>
        70. class LoggingMsgSender: public MsgSender<Company> {
        71. public:
        72. using MsgSender<Company>::sendClear; // 컴파일러에게 sendClear 함수가
        73. ... // 기본 클래스에 있다고 가정하라고
        74. // 알려 줍니다.
        75. void sendClearMsg(const MsgInfo& info) {
        76. ...
        77. sendClear(info); // 좋습니다. sendClear가
        78. ... // 상속되는 것으로 가정합니다.
        79. }
        80. ...
        81. };
        82.  
        83.  
        84. //---------------------------------------------------------------------------------------
        85. // 셋째, 호출할 함수가 기본 클래스의 함수라는 점을
        86. // 명시적으로 지정하는 것입니다.
        87. template <typename Company>
        88. class LoggingMsgSender: public MsgSender<Company> {
        89. public:
        90. ...
        91. void sendClearMsg(const MsgInfo& info) {
        92. ...
        93. MsgSender<Company>::sendClear(info); // 좋습니다. sendClear
        94. ... // 함수가 상속되는 것으로
        95. } // 가정합니다.
        96. ...
        97. };
        98.  
        99. // 마지막 방법은 추천하지 않는 방법입니다.
        100. // 왜냐하면 호출되는 함수가 가상 함수인 경우에는,
        101. // 이런 식으로 명시적 한정을 해 버리면
        102. // 가상 함수 바인딩(동적 바인딩)이 무시되기
        103. // 때문입니다.

        
        
        예제 코드 접기
        
        
        

  44. 매개변수에 독립적인 코드는 템플릿으로부터 분리시키자 / 312

      • 템플릿을 사용하면 비슷비슷한 클래스와 함수가 여러 벌 만들어집니다. 따라서 템플릿 매개변수에 종속되지 않는 템플릿 코드는 비대화의 원인이 됩니다.

        템플릿 코드는 템플릿이 아닌 코드와 달리 코드 중복이 암시적입니다. 소스 코드에는 템플릿이 하나밖에 없기 때문에, 어떤 템플릿이 여러 번 인스턴스화될 때 발생할 수 있는 코드 중복을 여러분의 감각으로 알아채야 합니다. 그러기 위해서는 피나는 수련이 필요합니다.

      • 비타입 템플릿 매개변수로 생기는 코드 비대화의 경우, 템플릿 매개변수를 함수 매개변수 혹은 클래스 데이터 멤버로 대체함으로써 비대화를 종종 없앨 수 있습니다.

        예제 코드 보기
        
        
        

        1. template <typename T, // T 타입의 객체를 원소로 하는 n행 n열의
        2.   std::size_t n> // 행렬을 나타내는 템플릿.
        3. class SquareMatrix {
        4. public:
        5. ...
        6. void invert(void); // 주어진 행렬을 그 저장공간에서 역행렬로 만듭니다.
        7. };
        8.  
        9. SquareMatrix<double, 5> sm1;
        10. ...
        11. sm1.invert(); // SquareMatrix<double, 5>::invert를 호출합니다.
        12.  
        13. SquareMatrix<double, 10> sm2;
        14. ...
        15. sm2.invert(); // SquareMatrix<double, 10>::invert를 호출합니다.
        16.  
        17. // 이 코드에서 두 invert 함수는 행렬의 크기만 제외하면
        18. // 같은 코드로 이루어져 있을 것입니다. 이것이
        19. // 비대화의 원인이 됩니다. 이는 다음과 같이 해결합니다.
        20.  
        21. template <typename T> // 정방행렬에 대해 쓸 수 있는
        22. class SquareMatrixBase { // 크기에 독립적인 기본 클래스
        23. protected:
        24. ...
        25. void invert(std::size_t matrixsize);// 주어진 크기의 행렬을 역행렬로 만듭니다.
        26. ...
        27. };
        28.  
        29. template <typename T, std::size_t n>
        30. class SquareMatrix: private SquareMatrixBase<T> {
        31. private:
        32. using SquareMatrixBase<T>::invert; // 기본 클래스의 invert가 가려지는 것을
        33. // 막기 위한 문장입니다. 항목 33을 보세요.
        34. public:
        35. ...
        36. void invert(void) { // invert의 기본 클래스 버전에 대해
        37. this->invert(n); // 인라인 호출을 수행합니다. "this->"가
        38. } // 있는 이유는 항목 43을 보세요.
        39. }; // (using 선언이 있어서 없어도 되긴 합니다.)
        40.  
        41. // 이제 모든 SquareMatrix<T, n> 클래스 템플릿에서
        42. // T(타입)가 동일하다면, SquareMatrixBase<T>
        43. // 클래스 템플릿의 구현을 공유하게 됩니다.
        44. // 즉 코드 비대화가 줄어듭니다.
        45.  
        46. // 여기서 SquareMatrixBase::invert 함수가
        47. // 자신이 상대할 데이터가 어떤 것인지 알아야 합니다.
        48. // 이를 위해 다음과 같은 방법이 있습니다.
        49.  
        50. template <typename T>
        51. class SquareMatrixBase {
        52. protected:
        53. SquareMatrixBase(std::size_t n, T *pMem) // 행렬 크기를 저장하고, 행렬 값에
        54. : size(n), pData(pMem) {} // 대한 포인터를 저장합니다.
        55.  
        56. void setDataPtr(T *ptr) {
        57. pData = ptr; // pData에 다시 대입합니다.
        58. }
        59. ...
        60. private:
        61. std::size_t size; // 행렬의 크기
        62. T *pData; // 행렬 값에 대한 포인터
        63. };
        64.  
        65. // 이렇게 설계해 두면, 메모리 할당 방법의 결정 권한이
        66. // 파생 클래스 쪽으로 넘어가게 됩니다.
        67.  
        68. template <typename T, std::size_t n>
        69. class SquareMatrix: private SquareMatrixBase<T> {
        70. public:
        71. SquareMatrix(void) // 행렬 크기(n) 및 데이터 포인터를
        72. : SquareMatrixBase<T>(n, data) {} // 기본 클래스로 올려보냅니다.
        73. ...
        74. private:
        75. T data[n * n];
        76. };
        77.  
        78. // 이 경우 객체 자체의 크기가 좀 커질 수 있습니다.
        79. // 그래서 이 방법이 마음에 들지 않으면 데이터를
        80. // 힙에 둘 수도 있습니다.
        81.  
        82. template <typename T, std::size_t n>
        83. class SquareMatrix: private SquareMatrixBase<T> {
        84. public:
        85. SquareMatrix(void) // 기본 클래스의 포인터를 널로 설정하고,
        86. : SquareMatrixBase<T>(n, 0), // 행렬 값의 메모리를 할당하고,
        87.   pData(new T[n * n]) // 파생 클래스의 포인터에 그 메모리를
        88. { // 물려 놓은 후, 이 포인터의 사본을
        89. this->setDataPtr(pData.get()); // 기본 클래스로 올려보냅니다.
        90. }
        91. ...
        92. private:
        93. boost::scoped_array<T> pData;
        94. };

        
        
        예제 코드 접기
        
        
        

      • 타입 매개변수로 생기는 코드 비대화의 경우, 동일한 이진 표현구조를 가지고 인스턴스화되는 타입들이 한 가지 함수 구현을 공유하게 만듦으로써 비대화를 감소시킬 수 있습니다.

        예를들면 list<int*>, list<const int*>, list<SquareMatrix<long, 3>*> 등 과 같은 포인터 타입에 대해, 템플릿은 똑같은 이진 코드를 생성할 것입니다. 이런 코드의 경우 내부적으로 list<void*>로 동작하는 버전을 호출하는 식으로 만들어서 코드 비대화를 줄일 수 있습니다.

  45. "호환되는 모든 타입"을 받아들이는 데는 멤버 함수 템플릿이 직방! / 320

      • 호환되는 모든 타입을 받아들이는 멤버 함수를 만들려면 멤버 함수 템플릿을 사용합시다.

        예제 코드 보기
        
        
        

        1. template <typename T>
        2. class SmartPtr {
        3. public:
        4. template <typename U> // "일반화된 복사 생성자"를
        5. SmartPtr(const SmartPtr<U>& other); // 만들기 위해 마련한
        6. ... // 멤버 템플릿
        7. };
        8.  
        9. // 하지만 이렇게 만든 경우 전혀 호환이 되지 않는
        10. // 타입끼리도 복사 생성이 가능해 집니다.
        11. // 예를 들면 SmartPtr<int*>로부터
        12. // SmartPtr<double*>을 생성할 수
        13. // 있게 됩니다. 이를 해결하기 위해 다음과 같은
        14. // 방법을 사용할 수 있습니다.
        15.  
        16. template <typename T>
        17. class SmartPtr {
        18. public:
        19. template <typename U>
        20. SmartPtr(const SmartPtr<U>& other) // 이 SmartPtr에 담긴 포인터를
        21. : heldPtr(other.get()) { ... } // 다른 SmartPtr에 담긴 포인터로 초기화 합니다.
        23. T* get(void) const {
        24. return heldPtr;
        25. }
        26. ...
        27. private: // SmartPtr에 담긴
        28. T *heldPtr; // 기본 제공 포인터
        29. };
        30.  
        31. // 이렇게 한 경우 U*에서 T*로 암시적 변환이
        32. // 가능한 경우에만 컴파일 에러가 나지 않습니다.

        
        
        예제 코드 접기
        
        
        

      • 일반화된 복사 생성 연산과 일반화된 대입 연산을 위해 멤버 템플릿을 선언했다 하더라도, 보통의 복사 생성자와 복사 대입 연산자는 여전히 직접 선언해야 합니다.

        프로그래머가 일반화 복사 생성자만 만들고 보통의 복사 생성자를 만들지 않으면, 컴파일러가 보통의 복사 생성자를 만들어 버립니다. 이것은 일반화 복사 생성자가 보통의 복사 생성자의 역할을 수행할수 있건 없건 상관하지 않고 적용됩니다.

  46. 타입 변환이 바람직할 경우에는 비멤버 함수를 클래스 템플릿 안에 정의해 두자 / 326

      • 모든 매개변수에 대해 암시적 타입 변환을 지원하는 템플릿과 관계가 있는 함수를 제공하는 클래스 템플릿을 만들려고 한다면, 이런 함수는 클래스 템플릿 안에 프렌드 함수로서 정의합시다.

        예제 코드 보기
        
        
        

        1. // 이 항목은 항목 24의 내용과 비슷한데,
        2. // 항목 24에서는 Rational 클래스의
        3. // operator* 함수가 예제로 나왔었죠.
        4.  
        5. // 이번 항목에서는 Rational 클래스와
        6. // operator* 함수를 템플릿으로
        7. // 만들 것입니다.
        8.  
        9. template <typename T>
        10. class Rational {
        11. public:
        12. Rational(const T& numerator = 0, // 매개변수가 참조자로 전달되는 이유는
        13. const T& denominator = 1); // 항목 20을 보면 나옵니다.
        15. const T numerator(void) const; // 반환 값 전달이 여전히 값에 의한 전달인
        16. const T denominator(void) const; // 이유는 항목 28을 보면 나오고요.
        17. ... // 이들 함수가 const인 이유는 항목 3에서...
        18. };
        19.  
        20. template <typename T>
        21. const Rational<T> operator*(const Rational<T>& lhs,
        22. const Rational<T>& rhs)
        23. { ... }
        24.  
        25. // 항목 24에서 그랬듯 혼합형 연산을 위해
        26. // 연산자 함수가 비멤버 함수로 선언되었습니다.
        27. // 하지만 이 상황에서 다음 코드는
        28. // 컴파일 되지 않습니다.
        29.  
        30. Rational<int> oneHalf(1, 2); // Rational이 이제 템플릿인 것만 빼면
        31. // 이 예제는 항목 24이 것과 똑같습니다.
        32.  
        33. Rational<int> result = oneHalf * 2; // 그런데 에러입니다! 컴파일이 안 된다고요.
        34.  
        35. // 두 번째 인자는 int 타입인데,
        36. // 컴파일러는 int타입으로부터 Rational<T>의
        37. // T가 무슨 타입인지를 유추하지 못합니다.
        38. // Rational이 정수형으로부터 암시적으로
        39. // 변환이 가능한데도 말입니다.
        40.  
        41. // 왜냐하면 템플릿 인자 추론(template argument deduction)
        42. // 과정에서는 암시적 타입 변환이 고려되지 않기 때문입니다.
        43.  
        44. // 이런 상황에서, 클래스 템플릿 안에 프렌드 함수를 넣어 두면
        45. // 함수 템플릿으로서의 성격을 주지 않고 특정한 함수 하나를
        46. // 나타낼 수 있다는 사실을 이용할 수 있습니다.
        47.  
        48. // 클래스 템플릿은 템플릿 인자 추론 과정에 좌우되지 않으므로,
        49. // T의 정확한 정보는 Rational<T> 클래스가 인스턴스화될
        50. // 당시에 바로 알 수 있습니다. 그렇기 때문에, 호출 시의
        51. // 정황에 맞는 operator* 함수를 프렌드로 선언하는 데
        52. // 별 어려움이 없는 것입니다.
        53.  
        54. template <typename T>
        55. class Rational {
        56. public:
        57. ...
        58. friend // operator* 함수를
        59. const Rational operator*(const Rational& lhs, // 선언합니다
        60. const Rational& rhs);
        61. };
        62.  
        63. template <typename T> // operator* 함수를
        64. const Rational<T> operator*(const Rational<T>& lhs, // 정의합니다.
        65. const Rational<T>& rhs)
        66. { ... }
        67.  
        68. // 이제 oneHalf 객체가 Rational<int> 타입으로
        69. // 선언되면 Rational<int> 클래스가 인스턴스로
        70. // 만들어지고, 이때 그 과정의 일부로서 Rational<int>
        71. // 타입의 매개변수를 받는 프렌드 함수인 operator*도
        72. // 자동으로 선언됩니다.
        73.  
        74. // 이전과 달리 지금은 함수 템플릿이 아니라 함수가 선언된
        75. // 것이므로 컴파일러는 이 호출문에 대해 암시적 변환 함수를
        76. // 적용할 수 있게 됩니다.
        77.  
        78.  
        79. // 하지만 이 코드는 컴파일은 되지만 링크가 되지 않습니다.
        80. // 가장 간단한 해결법은 선언과 정의를 하나로 합쳐
        81. // 클래스 템플릿 안에 넣어 버리는 것입니다.
        82.  
        83. template <typename T>
        84. class Rational {
        85. public:
        86. ...
        87. friend
        88. const Rational operator*(const Rational& lhs,
        89. const Rational& rhs)
        90. {
        91. // 항목 24에서 그대로 가져온 구현 코드
        92. return Rational(lhs.numerator() * rhs.numerator(),
        93. lhs.denominator() * rhs.denominator());
        94. }
        95. };
        96.  
        97. // 드디어 끝까지 돌아가는 코드가 나왔습니다.
        98. // 하지만 operator* 함수는 클래스 안에
        99. // 정의되었으므로 인라인 함수가 되어 버립니다.
        100.  
        101. // 클래스 바깥에 선언된 도우미 함수만 호출하는
        102. // 식으로 이런 암시적 인라인 선언의 영향을
        103. // 최소화할 수 있습니다.
        104.  
        105. template <typename T> class Rational; // Rational
        106. // 템플릿을
        107. // 선언합니다.
        108.  
        109. template <typename T> // 도우미 함수
        110. const Rational<T> doMultiply(const Rational<T>& lhs, // 템플릿을
        111. const Rational<T>& rhs); // 선언합니다.
        113. template <typename T>
        114. class Rational {
        115. public:
        116. ...
        117. friend
        118. const Rational<T> operator*(const Rational<T>& lhs,
        119. const Rational<T>& rhs) // 프렌드 함수가 도우미
        120. { return doMultiply(lhs, rhs); } // 함수를 호출하게 만듭니다.
        121. ...
        122. };
        123.  
        124. // 대다수의 컴파일러에서 템플릿 정의를
        125. // 헤더 파일에 전부 넣어야 합니다.
        126.  
        127. template <typename T>    // 필요하면,
        128. const Rational<T> doMultiply(const Rational<T>& lhs, // 도우미 함수
        129. const Rational<T>& rhs) // 템플릿을
        130. { // 헤더 파일 안에
        131. return Rational<T>(lhs.numerator() * rhs.numerator(), // 정의합니다.
        132.    lhs.denominator() * rhs.denominator());
        133. }

        
        
        예제 코드 접기
        
        
        

  47. 타입에 대한 정보가 필요하다면 특성정보 클래스를 사용하자 / 332

      • 특성정보 클래스는 컴파일 도중에 사용할 수 있는 타입 관련 정보를 만들어냅니다. 또한 특성정보 클래스는 템플릿 및 템플릿 특수 버전을 사용하여 구합니다.

        특성정보 클래스 예제 코드 보기
        
        
        

        1. // C++ 표준 라이브러리에는 다섯 개의 반복자 범주
        2. // 각각을 식별하는 데 쓰이는 "태그(tag) 구조체"
        3. // 가 정의되어 있습니다.
        4.  
        5. struct input_iterator_tag {};
        6. struct output_iterator_tag {};
        7. struct forward_iterator_tag: public input_iterator_tag {};
        8. struct bidirectional_iterator_tag: public forward_iterator_tag {};
        9. struct random_access_iterator_tag: public bidirectional_iterator_tag {};
        10.  
        11. // 특성정보는 항상 구조체로 구현하는 것으로 굳어진
        12. // 관례가 있습니다.
        13.  
        14. // 특성정보를 다루는 표준적인 방법은
        15. // 해당 특성정보를 템플릿 및 그 템플릿의
        16. // 1개 이상의 특수화 버전에 넣는 것입니다.
        17.  
        18. // 표준 라이브러리에는 다음과 같이
        19. // 준비되어 있습니다.
        20.  
        21. template <typename IterT> // 반복자 타입에 대한
        22. struct iterator_traits; // 정보를 나타내는 템플릿
        23.  
        24. // 위처럼 특성정보를 구현하는 데 사용한 구조체를
        25. // '특성정보 클래스'라고 부릅니다.
        26.  
        27. // iterator_traits 클래스는
        28. // 이 반복자 범주를 두 부분으로
        29. // 나누어 구현합니다.
        30.  
        31. // 첫 번째 부분은 사용자 정의 반복자 타입으로
        32. // 하여금 iterator_category 라는
        33. // 이름의 typedef 타입을 내부에 가질 것을
        34. // 요구사항으로 둡니다. 다음은 예시입니다.
        35.  
        36. template < ... >
        37. class deque {
        38. public:
        39. class iterator {
        40. public:
        41. // deque의 반복자는 임의접근 반복자
        42. typedef random_access_iterator_tag iterator_category;
        43. ...
        44. };
        45. ...
        46. };
        47.  
        48. // 이 iterator 클래스가 내부에 지닌
        49. // 중첩 typedef 타입을 앵무새처럼
        50. // 똑같이 재생한 것이 iterator_traits입니다.
        51.  
        52. // "typedef typename"이 사용된 부분에 대한 설명은
        53. // 항목 42를 보십시오.
        54. template <typename IterT>
        55. struct iterator_traits {
        56. typedef typename IterT::iterator_category iterator_category;
        57. ...
        58. };
        59.  
        60. // 하지만 이것만 가지고는 기본 제공 포인터 타입에
        61. // 적용할 수는 없습니다. 포인터 안에 typedef 타입이
        62. // 중첩된다는 것부터가 말이 안 되기 때문입니다.
        63.  
        64. // 따라서 iterator_traits 구현의 두 번째
        65. // 부분은 반복자가 포인터인 경우의 처리입니다.
        66.  
        67. // iterator_traits는 포인터 타입에 대한
        68. // 부분 특수화(partial template specialization)
        69. // 버전을 제공합니다.
        70.  
        71. template <typename IterT> // 기본제공 포인터 타입에 대한
        72. struct iterator_traits<IterT*> // 부분 템플릿 특수화
        73. {
        74. typedef random_access_iterator_tag iterator_category;
        75. ...
        76. };
        77.  
        78. // ※ 실제로는 std::iterator_traits 입니다.
        79.  
        80.  
        81. // 특성정보 클래스의 설계 및 구현 방법을 정리하면
        82. // 다음과 같습니다.
        83.  
        84. // ※ 다른 사람이 사용하도록 열어 주고 싶은 타입
        85. //   관련 정보를 확인합니다(예를 들어, 반복자
        86. //   라면 반복자 범주 등이 여기에 해당됩니다).
        87.  
        88. // ※ 그 정보를 식별하기 위한 이름을 선택합니다
        89. //   (예: iterator_category).
        90.  
        91. // ※ 지원하고자 하는 타입 관련 정보를 담은
        92. //   템플릿 및 그 템플릿의 특수화 버전
        93. //   (예: iterator_traits)을 제공합니다.

        
        
        특성정보 클래스 예제 코드 접기
        
        
        

      • 함수 오버로딩 기법과 결합하여 특성정보 클래스를 사용하면, 컴파일 타임에 결정되는 타입별 if...else 점검문을 구사할 수 있습니다.

        특성정보 클래스 사용 예제 코드 보기
        
        
        

        1. template <typename IterT, typename DistT> // 임의 접근
        2. void doAdvance(IterT& iter, DistT d, // 반복자에 대해서는
        3. std::random_access_iterator_tag) // 이 구현을 씁니다.
        4. {
        5. iter += d;
        6. }
        7.  
        8. template <typename IterT, typename DistT> // 양방향
        9. void doAdvance(IterT& iter, DistT d, // 반복자에 대해서는
        10. std::bidirectional_iterator_tag) // 이 구현을 씁니다.
        11. {
        12. if (d >= 0) { while (d--) ++iter; }
        13. else { while (d++) --iter; }
        14. }
        15.  
        16. template <typename IterT, typename DistT> // 입력 반복자에 대해서는
        17. void doAdvance(IterT& iter, DistT d, // 이 구현을 씁니다.
        18. std::input_iterator_tag)
        19. {
        20. if (d < 0) {
        21. throw std::out_of_range("Negative distance");
        22. }
        23. while (d--) ++iter;
        24. }
        25.  
        26. // forward_iterator_tag는 input_iterator_tag로부터
        27. // 상속을 받은 것이므로, input_iterator_tag를
        28. // 매개변수로 받는 doAdvance는 순방향 반복자도
        29. // 받을 수 있습니다.
        30.  
        31. // 이제 advance 함수만 만들면 됩니다.
        32. // advance가 해 줄 일은 오버로딩된
        33. // doAdvance를 호출하는 것뿐입니다.
        34.  
        35. template <typename IterT, typename DistT>
        36. void advance(IterT& iter, DistT d)
        37. {
        38. doAdvance( // iter의 반복자
        39. iter, d, // 범주에 적합한
        40. typename // doAdvance의
        41. std::iterator_traits<IterT>::iterator_category()// 오버로드 버전을
        42. ); // 호출합니다.
        43. }
        44.  
        45. // 특성정보 클래스를 어떻게 사용하는지, 마지막으로
        46. // 깔끔히 정리해 봅시다.
        47.  
        48. // ※ "작업자(worker)" 역할을 맡은 함수 혹은
        49. //   함수 템플릿(예: doAdvance)을 특성정보
        50. //   매개변수를 다르게 하여 오버로딩합니다. 그리고
        51. //   전달되는 해당 특성정보에 맞추어 각 오버로드
        52. //   버전을 구현합니다.
        53.  
        54. // ※ 작업자를 호출하는 "주작업자(master)"
        55. //   역할을 맡을 함수 혹은 함수 템플릿(예: advance)
        56. //   을 만듭니다. 이때 특성정보 클래스에서 제공되는
        57. //   정보를 넘겨서 작업자를 호출하도록 구현합니다.

        
        
        특성정보 클래스 사용 예제 코드 접기
        
        
        

  48. 템플릿 메타프로그래밍, 하지 않겠는가? / 340

      • 템플릿 메타프로그래밍(TMP)은 기존 작업을 런타임에서 컴파일 타임으로 전환하는 효과를 냅니다. 따라서 TMP를 쓰면 선행 에러 탐지와 높은 런타임 효율을 손에 거머쥘 수 있습니다.

        • 치수 단위(dimensional unit)의 정확성 확인
          과학 기술 분야의 응용프로그램을 만들 때는 무엇보다도 치수 단위(예를 들면 질량, 거리, 시간 등)가 똑바로 조합되어야 하는 것이 최우선입니다. TMP를 사용하면 프로그램 안에서 쓰이는 모든 치수 단위의 조합이 제대로 됐는지를 컴파일 동안에 맞춰 볼 수 있습니다. 그것도 계산 시간에 상관 없이 말이죠. 여기서 한 가지 재미있는 점은 바로 분수식 지수 표현이 지원된다는 것입니다. 이런 표현이 가능하려면 컴파일러가 확인할 수 있도록 컴파일 도중에 분수의 약분이 되어야 합니다.
        • 행렬 연산의 최적화
          다음의 코드를 보세요.
          
          // 행렬들의 곱을 계산합니다.
          BigMatrix result = m1 * m2 * m3 * m4 * m5;
          
          곱셈 결과를 "보통" 방법으로 계산하려면 네 개의 임시 행렬이 생겨야 합니다. (operator*를 호출할 때 마다 1개의 임시 행렬 생성) 그 뿐 아니라, 행렬 원소들 사이에 곱셈을 해야 하므로 네 개의 루프가 순차적으로 만들어질 수밖에 없습니다. 바로 이런 비싼 연산에 TMP를 사용할 수 있습니다. TMP를 응용한 고급 프로그래밍 기술인 표현식 템플릿(expression template)을 사용하면 덩치 큰 임시 객체를 없애는 것은 물론이고 루프까지 합쳐 버릴 수 있습니다. 게다가 위에 써 놓은 사용자 코드에서 문법 하나 바꾸지 않고도 이 놀라운 기술을 적용할 수 있습니다.

      • TMP는 정책 선택의 조합에 기반하여 사용자 정의 코드를 생성하는 데 쓸 수 있으며, 또한 특정 타입에 대해 부적절한 코드가 만들어지는 것을 막는 데도 쓸 수 있습니다.

        • 맞춤식 디자인 패턴 구현의 생성
          전략(Strategy) 패턴, 감시자(Observer) 패턴, 방문자(Visitor) 패턴 등의 디자인 패턴은 그 구현 방법이 여러 가지일 수 있습니다. TMP를 사용한 프로그래밍 기술인 정책 기반 설계(policy-based design)라는 것을 사용하면, 따로따로 마련된 설계상의 선택 [이것을 "정책(policy)"이라고 합니다]을 나타내는 템플릿을 만들어낼 수 있게 됩니다. 이렇게 만들어진 정책 템플릿은 서로 임의대로 조합되어 사용자의 취향에 맞는 동작을 갖는 패턴으로 구현되는 데 쓰입니다.
          예를 들어 몇 개의 스마트 포인터 동작 정책을 하나씩 구현한 각각의 템플릿을 만들어 놓고, 이들을 사용자가 마음대로 조합하여 수백 가지의 스마트 포인터 타입을 컴파일 도중 생성할 수 있게 하는 것입니다. 이 기술은 생성식 프로그래밍(generative programming)의 기초가 됩니다.
      
      TMP 예제 코드 보기
      
      
      

      1. // 특성정보 클래스를 이용하는 방법도 일종의
      2. // TMP(template metaprogramming)
      3. // 입니다.
      4.  
      5. // TMP로 루프도 만들 수 있는데,
      6. // 반복(iteration) 의미의 진정한 루프는
      7. // 없기 때문에, 재귀(recursion)를
      8. // 사용해서 루프의 효과를 냅니다.
      9.  
      10. // 다음은 컴파일을 통해 계승(factorial)을
      11. // 계산하는 템플릿 예제입니다.
      12.  
      13. template <unsigned n> // 일반적인 경우: Factorial<n>의 값은
      14. struct Factorial { // Factorial<n-1>의 값에 n을
      15. // 곱해서 구합니다.
      16. enum { value = n * Factorial<n-1>::value };
      17. };
      18.  
      19. template <> // 특수한 경우: Factorial<0>의
      20. struct Factorial<0> { // 값은 1입니다.
      21. enum { value = 1 };
      22. };
      23.  
      24. int main(void)
      25. {
      26. std::cout << Factorial<5>::value; // 120을 런타임 계산 없이 출력
      27. std::cout << Factorial<10>::value; // 3628800을 런타임 계산 없이 출력
      29. return 0;
      30. }

      
      
      TMP 예제 코드 접기
      
      
      

• Chapter 8   new와 delete를 내 맘대로

  49. new 처리자의 동작 원리를 제대로 이해하자 / 348

      • set_new_handler 함수를 쓰면 메모리 할당 요청이 만족되지 못했을 때 호출되는 함수를 지정할 수 있습니다.

        사용자가 부탁한 만큼의 메모리를 할당해 주지 못하면, operator new는 충분한 메모리를 찾아낼 때까지 new 처리자를 되풀이해서 호출합니다. set_new_handler로 지정한 new 처리자는 다음 중 하나를 꼭 수행해야 합니다.
        • 사용할 수 있는 메모리를 더 많이 확보합니다.
          operator new가 시도하는 이후의 메모리 확보가 성공할 수 있도록 하자는 전략입니다. 구현 방법은 여러가지가 있지만, 프로그램이 시작할 때 메모리 블록을 크게 하나 할당해 놓았다가 new 처리자가 가장 처음 호출될 때 그 메모리를 쓸 수 있도록 허용하는 방법이 그 한 가지입니다.
        • 다른 new 처리자를 설치합니다.
          현재의 new 처리자가 더 이상 가용 메모리를 확보할 수 없다 해도, 이 경우 자기 몫까지 해 줄 다른 new 처리자의 존재를 알고 있을 가능성도 있겠지요. 만약 그렇다면 현재의 new 처리자 안에서 set_new_handler를 호출하여 다른 new 처리자를 설치할 수 있습니다. operator new 함수가 다시 new 처리자를 호출할 때가 되면, 가장 마지막에 설치된 new 처리자가 호출되는 것입니다. 이 방법을 살짝 비틀면, new 처리자가 자기 자신의 동작 원리를 변경하도록 만들 수도 있습니다. 이렇게 만드는 한 가지 방법은 new 처리자의 동작을 조정하는 데이터를 정적 데이터 혹은 네임스페이스 유효범위 안의 데이터, 아니면 전역 데이터로 마련해 둔 후에 new 처리자가 이 데이터를 수정하게 만드는 것입니다.
        • new 처리자의 설치를 제거합니다.
          다시 말해, set_new_handler에 널 포인터를 넘깁니다. new 처리자가 설치된 것이 없으면, operator new 는 메모리 할당이 실패했을 때 예외를 던지게 됩니다.
        • 예외를 던집니다.
          bad_alloc 혹은 bad_alloc에서 파생된 타입의 예외를 던집니다. operator new에는 이쪽 종류의 에러를 받아서 처리하는 부분이 없기 때문에, 이 예외는 메모리 할당을 요청한 원래의 위치로 전파(propagate, 예외를 다시 던짐)됩니다.
        • 복귀하지 않습니다.
          대게 abort 혹은 exit를 호출합니다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // set_new_handler함수는 <new>에
        3. // 선언되어 있습니다.
        4. namespace std {
        5. typedef void (*new_handler)(void);
        7. new_handler set_new_handler(new_handler p) throw();
        8. }
        9.  
        10. // set_new_handler 함수는
        11. // 지정할 new 처리자(new_handler)를
        12. // 매개변수로 받고, 기존에 설정되어 있던
        13. // new 처리자를 반환하는 함수입니다.
        14.  
        15. // set_new_handler 함수의
        16. // 프로토타입 끝에 throw()는
        17. // 예외를 던지지 않겠다는 의미입니다.
        18.  
        19.  
        20. //-----------------------------------------------------------------------------
        21. // new 처리자 예제
        22. // 충분한 메모리를 operator new 가 할당하지 못핼을 때 호출할 함수
        23. void outOfMem(void)
        24. {
        25. std::cerr << "Unable to satisfy request for memory\n";
        26. std::abort();
        27. }
        28.  
        29. int main(void)
        30. {
        31. std::set_new_handler(outOfMem);
        33. int *pBigDataArray = new int[100000000L];
        34. ...
        35. }
        36.  
        37. // operator new가 1억 개의
        38. // 정수 할당에 실패하면 outOfMem
        39. // 함수가 호출될 것이고, 이 함수는
        40. // 에러 메시지를 출력하면서 프로그램을
        41. // 강제로 끝내 버릴 것입니다.
        42.  
        43. // 그런데 cerr에 에러 메시지를
        44. // 쓰는 과정에서 또 메모리가 동적으로
        45. // 할당되어야 한다면 어떻게 될까요?
        46. // 잠깐만 생각해 보세요.
        47.  
        48.  
        49. //-----------------------------------------------------------------------------
        50. // 특정 클래스(예 Widget)만을 위한
        51. // 할당에러 처리자 구현 예제
        52. class Widget {
        53. public:
        54. static std::new_handler set_new_handler(std::new_handler p) throw();
        55. static void * operator new(std::size_t size) throw(std::bad_alloc);
        56. private:
        57. static std::new_handler currentHandler;
        58. };
        59.  
        60. std::new_handler currentHandler = 0; // NULL로 초기화합니다.
        61. // 클래스 구현 파일에 두어야 하지요.
        63. std::new_handler Widget::set_new_handler(std::new_handler p) throw()
        64. {
        65. std::new_handler oldHandler = currentHandler;
        66. currentHandler = p;
        67. return oldHandler;
        68. }
        69.  
        70. // 이전에 쓰이고 있던 전역 new 처리자
        71. // 복원의 자동화를 위한 객체
        72. class NewHandlerHolder {
        73. public:
        74. explicit NewHandlerHolder(std::new_handler nh) // 현재의 new 처리자를
        75. : handler(nh) {} // 획득합니다.
        77. ~NewHandlerHolder(void) { // 이것을 해제합니다.
        78. std::set_new_handler(handler);
        79. }
        80. private:
        81. std::new_handler handler; // 이것을 기억해 둡니다.
        83. NewHandlerHolder(const NewHandlerHolder&); // 복사를 막기 위한 부분
        84. NewHandlerHolder& // (항목 14를 참고하세요)
        85. operator=(const NewHandlerHolder&);
        86. };
        87.  
        88. void * Widget::operator new(std::size_t size) throw(std::bad_alloc)
        89. {
        90. NewHandlerHolder // Widget의 new 처리자를
        91. h(std::set_new_handler(currentHandler)); // 설치합니다.
        93. return ::operator new(size); // 메모리를 할당하거나
        94. // 할당이 실패하면 예외를 던집니다.
        96. } // 이전의 전역 new 처리자가
        97. // 자동으로 복원됩니다.
        99. // Widget클래스를 사용하는 쪽에서의 예제
        100.  
        101. void outOfMem(void); // Widget 객체에 대한 메모리 할당이
        102. // 실패했을 때 호출될 함수의 선언
        103.  
        104. Widget::set_new_handler(outOfMem); // Widget의 new 처리자 함수로서
        105. // outOfMem을 설치합니다.
        106.  
        107. Widget *pw1 = new Widget; // 메모리 할당이 실패하면
        108. // outOfMem이 호출됩니다.
        109.  
        110. std::string *ps = new std::string; // 메모리 할당이 실패하면
        111. // 전역 new 처리자 함수가
        112. // (있으면) 호출됩니다.
        113.  
        114. Widget::set_new_handler(0); // Widget 클래스만을 위한
        115. // new 처리자 함수가 아무것도 없도록
        116. // 합니다(즉, null로 설정합니다).
        117.  
        118. Widget *pw2 = new Widget; // 메모리 할당이 실패하면 이제는
        119. // 예외를 바로 던집니다.(Widget
        120. // 클래스를 위한 new 처리자 함수가
        121. // 없습니다.
        122.  
        123.  
        124. //-----------------------------------------------------------------------------
        125. // 위의 예제를 여러 다른 클래스에 적용해도
        126. // 비슷한 코드가 만들어질 것 같습니다.
        127. // 따라서 이 경우 "믹스인(mixin) 양식"의
        128. // 기본 클래스를 만드는 것을 추천합니다.
        129. template <typename T> // 클래스별 set_new_handler를
        130. class NewHandlerSupport { // 지원하는 "믹스인 양식"의
        131. public: // 기본 클래스
        132. static std::new_handler set_new_handler(std::new_handler p) throw();
        133. static void * operator new(std::size_t size) throw(std::bad_alloc);
        135. ... // operator new의 다른 버전들을
        136. // 이 자리에 둡니다. 항목 52를 참고하세요.
        137. private:
        138. static std::new_handler currentHandler;
        139. };
        140.  
        141. template <typename T>
        142. std::new_handler
        143. NewHandlerSupport<T>::set_new_handler(std::new_handler p) throw()
        144. {
        145. std::new_handler oldHandler = currentHandler;
        146. currentHandler = p;
        147. return oldHandler;
        148. }
        149.  
        150. template <typename T>
        151. void* NewHandlerSupport<T>::operator new(std::size_t size)
        152. throw(std::bad_alloc);
        153. {
        154. NewHandlerHolder h(std::set_new_handler(currentHandler));
        155. return ::operator new(size);
        156. }
        157.  
        158. // 클래스별로 만들어지는 currentHandler 멤버를 널로 초기화합니다.
        159. template <typename T>
        160. std::new_handler NewHandlerSupport<T>::currentHandler = 0;
        161.  
        162.  
        163. // 이제 Widget 클래스에 set_new_handler
        164. // 기능을 추가하는 것은 별로 어려워지지 않게 됩니다.
        165. // 그저 NewHandlerSupport<Widget>로부터
        166. // 상속만 받으면 끝이거든요.
        167.  
        168. class Widget: public NewHandlerSupport<Widget> {
        169. ... // 이전과 같지만, 이제는 set_new_handler 혹은
        170. }; // operator new에 대한 선언문이 빠져 있습니다.

        
        
        예제 코드 접기
        
        
        

      • 예외불가(nothrow) new는 영향력이 제한되어 있습니다. 메모리 할당 자체에만 적용되기 때문입니다. 이후에 호출되는 생성자에서는 얼마든지 예외를 던질 수 있습니다.

        ※ new 처리자는 예외를 던지는 new와 예외불가 new, 모두에게 적용됩니다. 따라서 new 처리자의 동작 원리를 제대로 이해해 둡시다.
        
        예제 코드 보기
        
        
        

        1. class Widget { ... };
        2.  
        3. Widget *pw1 = new Widget; // 할당이 실패하면
        4. // bad_alloc 예외를 던집니다.
        5.  
        6. if (pw1 == 0) ... // 이 점검 코드는 꼭 실패합니다.
        7.  
        8. Widget *pw2 = new(std::nothrow) Widget; // Widget을 할당하다 실패하면
        9. // 0(널)을 반환합니다.
        10.  
        11. if (pw2 == 0) ... // 이 점검 코드는 성공할 수 있습니다.
        12.  
        13. // 여기서 new가 예외를 던지지 않는다 하더라도
        14. // Widget의 생성자에서 예외를 던질 수도 있습니다.
        15. // 즉 예외불가 new는 그때 호출되는
        16. // operator new에서만 예외가 발생되지
        17. // 않도록 보장할 뿐, "new(std::nothrow) Widget"
        18. // 등의 표현식에서 예외가 나오지 않게 막아 준다는
        19. // 이야기는 아닙니다. 이러한 이유 때문에
        20. // 십중팔구는 예외불가 new를 필요로 할 일이
        21. // 없을 것입니다.

        
        
        예제 코드 접기
        
        
        

  50. new 및 delete를 언제 바꿔야 좋은 소리를 들을지를 파악해 두자 / 358

      • 개발자가 스스로 사용자 정의 new 및 delete를 작성하는 데는 여러 가지 나름대로 타당한 이유가 있습니다. 여기에는 수행 성능을 향상시키려는 목적, 힙 사용 시의 에러를 디버깅하려는 목적, 힙 사용 정보를 수집하려는 목적 등이 포함됩니다.

        operator new와 operator delete를 바꾸는 가장 흔한 이유 세 가지는 다음과 같습니다.
        
        • 잘못된 힙 사용을 탐지하기 위해
          new한 메모리에 delete를 하는 것을 잊는다던지, delete한 메모리를 한 번 더 delete한다던지, 데이터 오버런(overrun, 할당된 메모리 블록의 끝을 넘어 뒤에 기록하는 것), 데이터 언더런(underrun, 할당된 메모리 블록의 시작을 넘어 앞에 기록하는 것) 과 같은 실수들을 잡아내기 위해 operator new 와 operator delete를 바꿀 수 있습니다.
        • 효율을 향상시키기 위해
          기본으로 제공되는 operator new 와 operator delete는 어떤 환경에서든 무난히 동작하도록 만들어져 있습니다. 이는 어떤 환경에서도 나쁜 성능을 발휘하지는 않지만, 그렇다고 좋은 성능을 발휘하지도 못한다는 말입니다. 프로그래머가 개발하는 소프트웨어의 환경에 적합하도록 operator new 와 operator delete를 바꾼다면, 더 좋은 성능을 내도록 만들 수 있을 것입니다.
        • 동적 할당 메모리의 실제 사용에 관한 통계 정보를 수집하기 위해
          여러분이 만드는 소프트웨어가 동적 메모리를 어떻게 사용하는지에 대한 정보를 수집하고, 이를 바탕으로 new 와 delete를 입맛대로 바꾸는 것이 더 좋습니다. 할당된 메모리 블록의 크기가 어떤 분포를 이루는지, 사용 시간은 또 어떤 분포를 보이는지, 메모리를 할당하고 해제하는 순서가 FIFO인지 LIFO인지 그것도 아니라면 임의의 순서인지, 시간 경과에 따라 사용 패턴의 변화는 어떠한지, 동적 할당 메모리의 최대량은 어떤지, 등과 같은 정보를 수집하기 위해 new 와 delete를 바꿀 수 있겠습니다.
        
        operator new 와 operator delete를 바꾸는 이유를 좀 더 자세히 알아봅시다.
        
        • 할당 및 해제 속력을 높이기 위해
          기본으로 제공되는 범용 할당자는 사용자 정의 버전보다 꽤 느린 경우가 적지 않습니다(항상은 아니지만 말이죠). 특히 사용자 정의 버전이 특정 타입의 객체에 맞추어 설계되어 있으면 더욱 그렇죠. 예를 들어 여러분이 만들 응용프로그램은 단일 스레드로 동작하는데 컴파일러에서 기본으로 제공하는 메모리 관리 루틴이 다중 스레드에 맞게 만들어져 있다면, 스레드 안전성이 없는 할당자를 여러분이 직접 만들어 씀으로써 상당한 속력 이득을 볼 수 있을 것입니다. 물론 operator new 와 operator delete 를 바꾸기 전에, 적절한 프로파일링을 통해 여러분 프로그램 안에서 이들이 진짜로 병목 현상을 일으키는 걸림돌인지 확인하는 센스는 기본입니다.
        • 기본 메모리 관리자의 공간 오버헤드를 줄이기 위해
          범용 메모리 관리자는 사용자 정의 버전과 비교해서 속력이 느린 경우도 많은데다가 메모리도 많이 잡아먹는 사례가 허다합니다. 할당된 각각의 메모리 블록에 대해 전체적으로 지우는 부담이 꽤 되기 때문입니다. 크기가 작은 객체에 대한 튜닝된 할당자를 사용하면 이러한 오버헤드를 실질적으로 제거할 수 있습니다.
        • 적당히 타협한 기본 할당자의 바이트 정렬 동작을 보장하기 위해
          예를 들어 x86 아키텍쳐에서는 double이 8바이트 단위로 정렬되어 있을 때 읽기·쓰기 속도가 가장 빠릅니다. 하지만 일부 컴파일러 중에는 operator new 함수가 double에 대한 동적 할당 시에 8바이트 정렬을 보장하지 않는 것들이 있다는 슬픈 소식이 나돌고 있습니다. 이런 경우, 기본제공 operator new 대신에 8바이트 정렬을 보장하는 사용자 정의 버전으로 바꿈으로써 프로그램 수행 성능을 확 끌어올릴 수 있습니다.
        • 임의의 관계를 맺고 있는 객체들을 한 군데에 나란히 모아 놓기 위해
          한 프로그램에서 특정 자료구조 몇 개가 대게 한 번에 동시에 쓰이고 있습니다. 이들에 대해서 페이지 부재(page fault)발생 횟수를 최소화하고 싶은 경우, 해당 자료구조를 담을 별도의 힙을 생성함으로써 이들이 가능한 한 적은 페이지를 차지하도록 하면 상당히 좋은 효과를 볼 수 있겠지요. 이러한 메모리 군집화는 위치지정(placement) new 및 위치지정 delete를 통해 쉽게 구현할 수 있습니다.
        • 그때그때 원하는 동작을 수행하도록 하기 위해
          기본제공 new와 delete가 해 주지 못하는 일을 operator new 및 operator delete가 해 주길 바랄 때가 있게 마련입니다. 메모리 할당과 해제를 공유 메모리에다 하고 싶은데 공유 메모리를 조작하는 일은 C API로밖에 할 수 없을 때가 한 가지 예이죠. 이 때 사용자 정의 버전 위치지정 new와 위치지정 delete를 만드는 것입니다. 또 다른 예로는 응용프로그램 데이터의 보안 강화를 위해 해제한 메모리 블록에 0을 덮어 쓰는 사용자 정의 operator delete를 만드는 경우도 생각해 볼 수 있습니다.

  51. new 및 delete를 작성할 때 따라야 할 기존의 관례를 잘 알아 두자 / 364

      • 관례적으로, operator new 함수는 메모리 할당을 반복해서 시도하는 무한 루프를 가져야 하고, 메모리 할당 요구를 만족시킬 수 없을 때 new처리자를 호출해야 하며, 0바이트에 대한 대책도 있어야 합니다. 클래스 전용 버전은 자신이 할당하기로 예정된 크기보다 더 큰(틀린) 메모리 블록에 대한 요구도 처리해야 합니다.

        operator new[]를 구현할 때 주의할 점은 operator new[] 안에서 해 줄 일은 단순히 원시 메모리의 덩어리를 할당하는 것밖엔 없다는 것입니다. 왜냐하면 상속 때문에, 파생 클래스 객체의 배열을 할당하는 데 기본 클래스의 operator new[] 함수가 호출될 수 있는데, 그렇기 때문에 Base::operator new[] 안에서조차 배열에 들어가는 객체 하나의 크기가 sizeof(Base)라는 가정을 할 수 없습니다. 이 말을 풀이해 보면, Base::operator new[]에서 할당한 배열 메모리에 들어가는 객체의 개수를 (요구된 바이트 수 / sizeof(Base))로 계산할 수 없다는 뜻입니다. 또한, operator new[]에 넘어가는 size_t 타입의 인자는 객체들을 담기에 딱 맞는 메모리 양보다 더 많게 설정되어 있을 수도 있습니다. 왜냐하면 동적으로 할당된 배열에는 배열 원소의 개수를 담기 위한 자투리 공간이 추가로 들어가기 때문입니다.
        
        예제 코드 보기
        
        
        

        1. //-------------------------------------------------------------------
        2. // 사용자 정의 operator new 의 예제
        3. void * operator new(std::size_t size) throw(std::bad_alloc)
        4. { // 여러분의 operator new 함수는 다른
        5. // 매개변수를 추가로 가질 수 있습니다.
        6. using namespace std;
        8. if (size == 0) { // 0바이트 요청이 들어오면
        9. size = 1; // 이것을 1바이트 요구로
        10. } // 간주하고 처리합니다.
        12. while (true) {
        13. size바이트를 할당해 봅니다;
        14. if ( 할당이 성공했음 )
        15. return ( 할당된 메모리에 대한 포인터 );
        17. // 할당이 실패했을 경우, 현재의 new 처리자 함수가
        18. // 어느 것으로 설정되어 있는지 찾아냅니다(아래를 보세요).
        19. new_handler globalHandler = set_new_handler(0);
        20. set_new_handler(globalHandler);
        22. if (globalHandler) (*globalHandler)();
        23. else throw std::bad_alloc();
        24. }
        25. }
        26.  
        27. // 현재의 전역 new 처리자 함수를 얻어오는
        28. // 직접적인 방법은 없기 때문에 set_new_handler의
        29. // 반환값을 통해 얻어와야 합니다.
        30.  
        31.  
        32. //-------------------------------------------------------------------
        33. // 어떤 클래스의 멤버 operator new도
        34. // 상속 대상이 됩니다. 이것이 문제를
        35. // 일으킬 수 있습니다. 다음을 보세요.
        36. class Base {
        37. public:
        38. static void * operator new(std::size_t size) throw(std::bad_alloc);
        39. ...
        40. };
        41.  
        42. class Derived: public Base // Derived에서는 operator new가
        43. { ... }; // 선언되지 않았습니다.
        44.  
        45. Derived *p = new Derived; // Base::operator new가 호출되네!
        46.  
        47. // Derived의 크기는 Base보다
        48. // 클 수 있기 때문에 문제가
        49. // 발생할 수 있습니다.
        50.  
        51. // 전체 설계를 바꾸지 않고 쓸 수 있는
        52. // 가장 좋은 해결 방법은 다음과 같습니다.
        53. void * Base::operator new(std::size_t size) throw(std::bad_alloc)
        54. {
        55. if (size != sizeof(Base)) // "틀린" 크기가 들어오면,
        56. return ::operator new(size); // 표준 operator new 쪽에서 메모리
        57. // 할당 요구를 처리하도록 넘깁니다.
        59. ... // 맞는 크기가 들어오면 메모리 할당된
        60. // 요구를 여기서 처리합니다.
        61. }
        62.  
        63. // 0바이트 점검 코드는 sizeof(Base)와
        64. // 비교하는 곳에서 한꺼번에 처리됩니다.
        65. // 왜냐하면 C++에는 모든 독립 구조(freestanding)의
        66. // 객체는 반드시 크기가 0을 넘어야 한다는
        67. // 요상한 금기사항 때문입니다.

        
        
        예제 코드 접기
        
        
        

      • operator delete 함수는 널 포인터가 들어왔을 때 아무 일도 하지 않아야 합니다. 클래스 전용 버전의 경우에는 예정 크기보다 더 큰 블록을 처리해야 합니다.

        중요한 점을 하나 더 말씀드리자면, 가상 소멸자가 없는 기본 클래스로부터 파생된 클래스의 객체를 삭제하려고 할 경우에는 operator delete로 C++가 넘기는 size_t 값이 엉터리일 수 있습니다. 이것만으로도 기본 클래스에 가상 소멸자를 꼭 두어야 하는 충분한 이유가 선다고 말씀드릴 수 있을 것 같습니다. (기본 클래스에서 가상 소멸자를 빼먹으면 operator delete 함수가 똑바로 동작하지 않을 수 있다는 사실을 잊지 마세요)
        
        예제 코드 보기
        
        
        

        1. //-------------------------------------------------------------------
        2. // 사용자 정의 operator delete 의 예제
        3. void operator delete(void * rawMemory) throw()
        4. {
        5. if (rawMemory == 0) return; // 널 포인터가 delete되려고 할 경우에는
        6. // 아무것도 하지 않게 합니다.
        8. rawMemory 가 가리키는 메모리를 해제합니다;
        9. }
        10.  
        11.  
        12. //-------------------------------------------------------------------
        13. // 클래스 전용 operator delete 의 예제
        14. // 클래스 전용 operator new와 마찬가지로
        15. // 삭제될 메모리의 크기를 점검하는 코드를
        16. // 넣어 주어야 합니다.
        17. class Base { // 이전과 같으나, 지금은
        18. public: // operator delete가 선언된 상태
        19. static void * operator new(std::size_t size) throw(std::bad_alloc);
        20. static void operator delete(void *rawMemory, std::size_t size) throw();
        21. ...
        22. };
        23.  
        24. void Base::operator delete(void *rawMemory, std::size_t size) throw()
        25. {
        26. if (rawMemory == 0) return; // 널 포인터에 대한 점검
        28. if (size != sizeof(Base)) { // 크기가 "틀린" 경우
        29. ::operator delete(rawMemory); // 표준 operator delete가
        30. return; // 메모리 삭제 요청을 맡도록 합니다.
        31. }
        33. rawMemory가 가리키는 메모리를 해제합니다;
        35. return;
        36. }

        
        
        예제 코드 접기
        
        
        

  52. 위치지정 new를 작성한다면 위치지정 delete도 같이 준비하자 / 370

      • operator new 함수의 위치지정(placement) 버전을 만들 때는, 이 함수와 짝을 이루는 위치지정 버전의 operator delete 함수도 꼭 만들어 주세요. 이 일을 빼먹었다가는, 찾아내기도 힘들며 또 생겼다가 안 생겼다 하는 메모리 누출 현상을 경험하게 됩니다.

        예제 코드 보기
        
        
        

        1. Widget *pw = new Widget;
        2.  
        3. // 위의 코드에서는 먼저 operator new 함수가
        4. // 불려 메모리를 할당한 뒤 Widget의 생성자가
        5. // 호출됩니다.
        6.  
        7. // 그런데 Widget의 생성자에서 예외가 발생한 경우
        8. // 프로그래머는 메모리 누수를 해결할 수 없습니다.
        9.  
        10. // 동적 할당 받은 메모리의 시작 주소가 pw에
        11. // 담기기도 전에 예외가 던져지기 때문이죠.
        12.  
        13. // 이 경우 메모리의 해제는 C++
        14. // 런타임 시스템께서 맡이 주시게 됩니다.
        15.  
        16. // 하지만 C++ 런타임 시스템이 알아서
        17. // 메모리를 해제하려면 new와 짝이 맞는
        18. // delete를 알아야 합니다.
        19.  
        20. // 일반적인 경우 이것은 큰 문제가 되지 않습니다.
        21.  
        22. // 왜냐하면 기본형 operator new는
        23. void* operator new(std::size_t) throw(std::bad_alloc);
        24.  
        25. // 역시 기본형 operator delete와
        26. // 짝을 맞추기 때문입니다.
        27.  
        28. void operator delete(void *rawMemory) throw(); // 전역 유효범위에서의
        29. // 기본형 시그너처
        30.  
        31. void operator delete(void *rawMemory, // 클래스 유효범위에서의
        32. std::size_t size) throw(); // 전형적인 기본형
        33. // 시그너처
        34.  
        35. // 따라서 표준 형태의 new 및 delete만
        36. // 사용하는 한, 런타임 시스템은 new의 동작을
        37. // 되돌릴 방법을 알고 있는 delete을
        38. // 문제없이 찾아낼 수 있습니다.
        39.  
        40. // 하지만 operator new의 기본형이 아닌
        41. // 형태를 선언하기 시작하면 new와 delete짝을
        42. // 맞추는 데 문제가 뽀송뽀송 피어나게 됩니다.
        43.  
        44. // 비기본형이란 바로 다른 매개변수를 추가로 갖는
        45. // operator new를 뜻합니다.
        46. // (이런 operator new를 위치지정
        47. // (placement) new 라고 합니다.)
        48.  
        49. class Widget {
        50. public:
        51. ...
        52. static void* operator new(std::size_t size, // 비표준 형태의
        53.   std::ostream& logStream) // operator new
        54. throw(std::bad_alloc);
        55. static void operator delete(void *pMemory // 클래스 전용
        56. size_t size) throw(); // operator delete의
        57. // 표준 형태
        58. ...
        59. };
        60.  
        61. Widget *pw = new(std::cerr) Widget; // operator new를 호출하는 데
        62. // cerr을 ostream 인자로 넘기는데, 이때
        63. // Widget 생성자에서 예외가 발생하면
        64. // 메모리가 누출됩니다.
        65.  
        66. // 위에서 호출된 new는 ostream& 타입의
        67. // 매개변수를 추가로 받아들이므로, 이것과 짝을
        68. // 이루는 operator delete 역시 똑같은
        69. // 시그너처를 가진 것이 마련되어 있어야 합니다.
        70.  
        71. void operator delete(void *, std::ostream&) throw();
        72.  
        73. // 이러한 operator delete를
        74. // 위치지정 delete라고 합니다.
        75.  
        76. // 따라서 예제에서 위치지정 delete를 추가해
        77. // 주면 메모리 누출 위험이 사라집니다.
        78.  
        79. class Widget {
        80. public:
        81. ...
        82. static void* operator new(std::size_t size, std::ostream& logStream)
        83. throw(std::bad_alloc);
        84. static void operator delete(void *pMemory) throw();
        85. static void operator delete(void *pMemory, std::ostream& logStream)
        86. throw();
        87. ...
        88. };
        89.  
        90. Widget *pw = new(std::cerr) Widget; // 이전과 같은 코드이지만
        91. // 메모리 누출이 없습니다.
        92.  
        93. delete pw; // 기본형의 operator delete가 호출됩니다.
        94.  
        95. // 일반적인 경우에는 위치지정 delete 대신
        96. // 기본형의 operator delete 가 호출됩니다.

        
        
        예제 코드 접기
        
        
        

      • new 및 delete의 위치지정 버전을 선언할 때는, 의도한 바도 아닌데 이들의 표준 버전이 가려지는 일이 생기지 않도록 주의해 주세요.

        예제 코드 보기
        
        
        

        1. class Base {
        2. public:
        3. ...
        4. static void* operator new(std::size_t size, // 이 new가
        5.   std::ostream& logStream) // 표준 형태의
        6. throw(std::bad_alloc); // 전역 new를 가립니다.
        7. ...
        8. };
        9.  
        10. Base *pb = new Base; // 에러! 표준 형태의 전역
        11. // operator new가 가려지거든요.
        12.  
        13. Base *pb = new(std::cerr) Base; // 이건 문제없습니다. Base의
        14. // 위치지정 new를 호출합니다.
        15.  
        16. // 파생 클래스는 전역 operator new는
        17. // 물론이고 자신이 상속받는 기본 클래스의
        18. // operator new까지 가려 버립니다.
        19.  
        20. class Derived: public Base { // 위의 Base로부터 상속받은 클래스
        21. public:
        22. ...
        23. static void* operator new(std::size_t size) // 기본형 new를 클래스 전용으로
        24. throw(std::bad_alloc); // 다시 선언합니다.
        25. ...
        26. };
        27.  
        28. Derived *pd = new(std::cerr) Derived; // 에러! Base의 위치지정
        29. // new가 가려져 있기 때문입니다.
        30.  
        31. Derived *pd = new Derived; // 문제없습니다. Derived의
        32. // operator new를 호출합니다.
        33.  
        34. // C++가 전역 유효 범위에서 제공하는
        35. // operator new의 형태는 다음
        36. // 세 가지가 표준입니다.
        37.  
        38. void* operator new(std::size_t) throw(std::bad_alloc); // 기본형 new
        39.  
        40. void* operator new(std::size_t, void*) throw(); // 위치지정 new
        41.  
        42. void* operator new(std::size_t, // 예외불가 new
        43.    const std::nothrow_t&) throw(); // (항목 49 참조)
        44.  
        45. // 어떤 형태든 간에 operator new가
        46. // 클래스 안에 선언되는 순간,
        47. // 앞의 예제처럼 위의 표준 형태들이
        48. // 몽땅 가려지는 것입니다.
        49.  
        50. // 다음과 같은 한 가지 해결책이 있습니다.
        51. // 기본 클래스 하나를 만들고, 이 안에
        52. // new 및 delete의 기본 형태를
        53. // 전부 넣어두십시오.
        54.  
        55. class StandardNewDeleteForms {
        56. public:
        57. // 기본형 new/delete
        58. static void* operator new(std::size_t size) throw(std::bad_alloc)
        59. { return ::operator new(size); }
        61. static void operator delete(void *pMemory) throw()
        62. { ::operator delete(pMemory); }
        64. // 위치지정 new/delete
        65. static void* operator new(std::size_t size, void *ptr) throw()
        66. { return ::operator new(size, ptr); }
        68. static void operator delete(void *pMemory, void *ptr) throw()
        69. { return ::operator delete(pMemory, prt); }
        71. // 예외불가 new/delete
        72. static void* operator new(std::size_t,
        73.   const std::nothrow_t& nt) throw()
        74. { return ::operator new(size, nt); }
        76. static void operator delete(void *pMemory,
        77. const std::nothrow_t&) throw()
        78. { ::operator delete(pMemory); }
        79. };
        80.  
        81. // 표준 형태에 덧붙여 사용자 정의 형태를 추가하고 싶다면,
        82. // 이제는 이 기본 클래스를 축으로 넓혀 가면 됩니다.
        83.  
        84. // 상속과 using 선언을 2단 콤보로 사용해서 표준 형태를
        85. // 파생 클래스 쪽으로 끌어와 외부에서 사용할 수 있게 만든
        86. // 후에, 원하는 사용자 정의 형태를 선언해 주세요.
        87.  
        88. class Widget: public StandardNewDeleteForms { // 표준 형태를 물려받습니다.
        89. public:
        90. using StandardNewDeleteForms::operator new; // 표준 형태가 (Widget
        91. using StandardNewDeleteForms::operator delete; // 내부에) 보이도록 만듭니다.
        93. static void* operator new(std::size_t size, // 사용자 정의 위치지정
        94. std::ostream& logStream) // new를 추가합니다.
        95. throw(std::bad_alloc);
        97. static void operator delete(void *pMemory, // 앞의 것과 짝이 되는
        98. std::ostream& logStream) // 위치 지정 delete를
        99. throw(); // 추가합니다.
        100. ...
        101. };

        
        
        예제 코드 접기
        
        
        

• Chapter 9   그 밖의 이야기들

  53. 컴파일러 경고를 지나치지 말자 / 379

      • 컴파일러 경고를 쉽게 지나치지 맙시다. 여러분의 컴파일러에서 지원하는 최고 경고 수준에도 경고 메시지를 내지 않고 컴파일되는 코드를 만드는 쪽에 전력을 다 하십시오.

      • 컴파일러 경고에 너무 기대는 인생을 지양하십시오. 컴파일러마다 트집을 잡고 경고를 내는 부분들이 천차만별이기 때문입니다. 지금 코드를 다른 컴파일러로 이식하면서 여러분이 익숙해져 있는 경고 메시지가 온 데 간 데 없이 사라질 수도 있습니다.

      예제 코드 보기
      
      
      

      1. class B {
      2. public:
      3. virtual void f(void) const;
      4. };
      5.  
      6. class D: public B {
      7. public:
      8. virtual void f(void);
      9. };
      10.  
      11. // B::f는 const 멤버인데 반해
      12. // D::f는 const 멤버가 아닙니다.
      13. // 이런 실수가 있는 경우 컴파일러
      14. // 경고가 뜹니다.
      15.  
      16. // warning: D::f() hides virtual B::f()
      17.  
      18. // 하지만 어떤 컴파일러의 경우 아무런
      19. // 경고를 띄우지 않을 수도 있습니다.

      
      
      예제 코드 접기
      
      
      

  54. TR1을 포함한 표준 라이브러리 구성요소와 편안한 친구가 되자 / 381

      • 최초에 상정된 표준 C++ 라이브러리의 주요 구성요소는 STL, iostream, 로케일 등입니다. 여기에는 C89의 표준 라이브러리도 포함되어 있습니다.

        • 표준 템플릿 라이브러리(Standard Template Library: STL)
          주요 구성요소로서 컨테이너(vector, string, map 등), 반복자, 알고리즘(find, sort, transform 등), 함수 객체(less, greater 등) 외에 이런저런 컨테이너 어댑터와 함수 객체 어댑터(stack, priority_queue, mem_fun, not1 등)가 있습니다.
        • iostream
          사용자 정의 버퍼링, 국제화 기능이 가능한 입출력을 지원하며, 그 외에 cin, cout, cerr, clog 등의 사전정의 객체를 지원합니다.
        • 국제화 지원
          여러 로케일(locale)을 활성화시킬 수 있는 기능이 포함되어 있습니다. 또한 wchar_t 등의 타입(대개 16비트/문자) 및 wstring(wchar_t 타입으로 정의한 string)을 쓰면 유니코드를 사용할 수 있습니다.
        • 수치 처리 지원
          복소수를 나타내는 템플릿(complex) 및 수치 배열을 나타내는 템플릿(valarray)이 여기에 해당됩니다.
        • 예외 클래스 계통
          최상위 클래스인 exception 및 이것으로부터 갈라져 나온 파생 클래스들, 예를 들어 logic_error 및 runtime_error 등이 여기에 포함됩니다.
        • C89의 표준 라이브러리
          1989년 버전의 C에 포함된 표준 라이브러리는 전부 C++에도 들어 있습니다.

      • TR1이 도입되면서 추가된 것은 스마트 포인터(tr1::shared_prt 등), 일반화 함수 포인터(tr1::function), 해시 기반 컨테이너, 정규 표현식 그리고 그 외의 10개 구성요소입니다.

        TR1을 통해 명시된 새로운 구성요소는 총 14개 입니다. 14개 모두 std::tr1 네임스페이스 안에 들어 있습니다.
        
        
        • 스마트 포인터(smart pointer)
          tr1::shared_prt, tr1::weak_ptr이 여기에 해당합니다. shared_prt은 비순환형 자료구조 내에 자원의 누출을 방지하는 용도로 적합합니다. 순환형이 되는 경우 순환 구조 때문에 각 개체의 참조 카운트가 0이 되지 않는 현상이 생길 수 있습니다. 이럴때 사용하는 것이 weak_ptr 입니다. weak_ptr은 참초 카운팅에는 영향을 주지 않기 때문에, 어떤 객체를 물고 있는 마지막 shared_prt이 소멸될 때 weak_ptr이 그 객체를 물고 있더라도 객체는 소멸됩니다. 단 이 경우 weak_ptr은 무효상태(invalid)로 표시됩니다.
        • tr1::function
          어떤 함수가 가진 시그너처와 호환되는 시그너처를 갖는 함수호출성 개체(callable entity)의 표현을 가능하게 해 주는 템플릿입니다. 보통 int를 받고 string을 반환하는 콜백 함수를 등록하도록 만들고 싶으면 다음과 같이 합니다.
          
          // int를 받고 string을
          // 반환하는 함수가
          // 매개변수 타입입니다.
          void registerCallback(std::string func(int));
          
          매개변수 이름으로 쓰인 func는 사실 없어도 되는 선택사항이므로, 다음과 같이 쓸 수도 있습니다.
          
          // 위와 동일합니다.
          // 매개변수 이름만 빠졌습니다.
          void registerCallback(std::string (int));
          
          여기서 매개변수 타입에 해당하는 "std::string (int)" 부분이 바로 함수 시그너처 입니다. 이런 용도에 tr1::function 템플릿을 사용하면 registerCallback이 훨씬 융통성 있게 만들어집니다. int타입과 호환되는 어떤 타입도 전달받으며, string과 호환 가능한 어떤 타입도 반환할 수 있는 그런 함수를 registerCallback의 매개변수로 설정할 수 있는 것이죠.
          
          // 매개변수인 "func"는 이제
          // "std::string (int)"와 호환되는
          // 시그너처를 갖는 어떤 함수호출성
          // 개체도 될 수 있습니다.
          void registerCallback(std::tr1::function
          <std::string (int)> func);
          
          항목 35에서 예제를 볼 수 있습니다.
        • tr1::bind
          현역 STL 바인더로 잘 쓰이고 있는 bind1st 및 bind2nd와 똑같이 동작함은 물론, 그보다 훨씬 더 많은 기능이 있는 범용 바인더 입니다. TR1 이전의 바인더들과 달리 tr1::bind는 상수 멤버 함수 및 비상수 멤버 함수에 상관없이 동작합니다. 또한 참조로 전달되는 매개변수에 대해서도 동작합니다. 마지막으로 외부 보조 없이도 함수 포인터를 자체적으로 다룰 수 있습니다. 항목 35를 보시면 사용 예를 확인하실 수 있습니다.
        • 해시 테이블(hash table)
          세트·멀티세트·맵·멀티맵을 구현하는 데 이 해시 테이블이 쓰였습니다. 이들 각각의 인터페이스는 똑같은 이름을 갖는 TR1 이전의 연관 컨테이너의 인터페이스를 본떠서 만들어졌습니다. 각각의 이름은 tr1::unordered_set, tr1::unordered_multiset, tr1::unordered_map, tr1::unordered_multimap 인데 set, multiset, map, multimap에 저장되는 원소와 달리, 원소가 저장되는 순서를 예측할 수 없다는 점을 강조하는 듯한 인상이 팍팍 풍깁니다.
        • 정규 표현식(regular expression)
          정규 표현식 기반의 탐색과 문자열에 대한 대체 연산이 가능하며, 일치되는 원소들 사이의 순회도 지원합니다.
        • 투플(tuple)
          pair 템플릿의 신세대 버전. pair의 경우에는 두 개만 담을 수 있지만, tuple 객체는 몇 개라도 담을 수 있습니다.
        • tr1::array
          근본부터 "STL스럽게 된" 배열입니다. 다시 말해 begin 및 end 등의 멤버 함수를 지원하는 배열입니다. tr1::array 객체의 크기는 컴파일 과정에서 고정됩니다(동적 메모리를 쓰지 않는다는 뜻이죠).
        • tr1::mem_fn
          멤버 함수 포인터를 적응시키는(adapt) 용도에 쓸 수 있는, 문법적으로 천하통일을 이룬 템플릿. C++98의 mem_fun 및 mem_fun_ref를 그대로 껴안음과 동시에 기능을 확장하였습니다.
        • tr1::reference_wrapper
          기존의 참조자가 객체처럼 행세할 수 있도록 만들어 주는 템플릿입니다. 무엇보다, 이것을 사용하면 참조자를 담은 것처럼 동작하는 컨테이너를 만들 수 있다는 점이 가장 큽니다(컨테이너는 객체 혹은 포인터만 담을 수 있습니다).
        • 난수 발생
          C++가 C 표준 라이브러리로부터 물려받은 rand 함수보다 몇 배는 우수한 난수 발생 기능입니다.
        • 특수 용도의 수학 함수
          라게르(Laguerre) 다항식, 베셀(Bessel) 함수, 완전 타원 적분(complete elliptic integral) 등이며 그 외에도 많이 있습니다.
        • C99 호환성 확장 기능
          C99의 새로운 라이브러리를 C++로 가져올 목적으로 설계된 함수 및 템플릿 모음
        나머지 TR1 구성요소의 두 번째 부류는 더 세련된 템플릿 프로그래밍 기법, 이를테면 템플릿 메타프로그래밍(항목 48 참조) 같은 기법을 지원하는 기술들입니다.
        • 타입 특성정보(type traits)
          주어진 타입에 대한 컴파일 타임 정보를 제공하는 특성정보 클래스(항목 47 참조)의 모음입니다. 어떤 T타입에 대해 TR1의 타입 특성정보 기능을 적용하면, T가 기본제공 타입인지, 가상 소멸자를 지원하는지, 공백 클래스(항목 39 참조)인지, 다른 U타입으로 암시적 변환이 가능한지 등의 정보를 들추어낼 수 있습니다. 심지어, 주어진 타입의 적절한 바이트 정렬까지 잡아내어 줍니다.
        • tr1::result_of
          어떤 함수 호출의 반환 타입을 추론해 주는 템플릿입니다. 이런저런 복잡한 사정 때문에 반환 타입은 그 함수의 매개변수 타입에 따라 달라질 수 있습니다. tr1::result_of 템플릿을 쓰면 함수 반환 타입을 쉽게 참조할 수 있습니다.

      • TR1 자체는 단순히 명세서일 뿐입니다. TR1의 기능을 사용하기 위해서는 명세를 구현한 코드를 구해야 합니다. TR1 구현을 구할 수 있는 자료처 중 한 군데가 바로 부스트입니다.

        부스트의 TR1스러운 라이브러리를 쓰고자 할 때 다음과 같은 꼼수를 쓸 수 있습니다. 부스트의 라이브러리는 boost 네임스페이스 안에 들어있지만 TR1 구성요소는 std::tr1 네임스페이스 안에 있어야 합니다.
        
        // std::tr1 네임스페이스는 이제
        // boost 네임스페이스의 별칭으로 설정됩니다.
        namespace std {
        namespace tr1 = ::boost;
        }
        
        std 네임스페이스 안에는 아무것도 추가하면 안되지만 실제로는 아무런 문제가 일어나지 않을 가능성이 큽니다. 만일 여러분의 컴파일러가 자체적으로 TR1을 지원한다면 위의 꼼수를 제거해 버리면 됩니다. 그렇게 하더라도 std::tr1을 참조하는 기존의 코드는 여전히 유효할 것입니다.

  55. Boo子有親(부자유친)! 부스트를 늘 여러분 가까이에 / 388

      https://www.boost.org/

      • 부스트는 동료 심사를 거쳐 등록되고 무료로 배포되는 오픈 소스 C++ 라이브러리를 개발하는 모임이자 웹사이트입니다. 또한 C++ 표준화에 있어서 영향력 있는 역할을 맡고 있습니다.

      • 부스트에서 배포되는 라이브러리들 중엔 TR1 구성요소에 들어간 것도 있지만, 그 외에 다른 라이브러리들도 아주 많습니다.

        부스트의 라이브러리 군단은 크게 십수 개의 범주로 나뉘어 있습니다. 여기에 각각을 소개합니다.
        • 문자열 및 텍스트 처리
          주요 구성요소로 타입 안전성을 갖춘 printf 비슷한 서식화 기능, 정규 표현식(TR1에 있는 바로 그 정규 표현식이 이것에서 나왔습니다. 항목 54 참조) 및 토큰화와 구문분석 기능이 있습니다.
        • 컨테이너
          STL 양식의 인터페이스를 제공하는 고정 크기 배열(항목 54 참조), 가변 크기 비트세트, 다차원 배열 등이 포함되어 있습니다.
        • 함수 객체 및 고차(higher-order) 프로그래밍
          TR1의 기능을 구현하는 데 사용된 몇 개의 기반 라이브러리가 여기에 해당됩니다. 재밌는 라이브러리 하나를 소개하면 람다(Lambda) 라이브러리를 들 수 있습니다. 이 라이브러리는 별도의 준비 없이 즉석해서 함수 객체를 생성해 주는 기막힌 기능을 제공합니다.
          
          // boost::lambda의 기능을
          // 쓸 수 있도록 만듭니다.
          using namespace boost::lambda;
          
          std::vector<int> v;
          ...
          // v 안에 들어있는 각각의 원소
          // x에 대해 x*2+10을 출력합니다.
          // "_1"은 Lambda 라이브러리에서
          // 사용하는, '현재 원소'를 뜻하는
          // 자리채움자입니다.
          std::for_each(v.begin(), v.end(), std::cout << _1 * 2 + 10 << "\n");
          
        • 일반화 프로그래밍
          매우 다양한(많은) 특성정보(traits) 클래스를 만나실 수 있습니다(특성정보에 대한 자세한 이야기는 항목 47에서 확인하세요).
        • 템플릿 메타프로그래밍(TMP, 항목 48 참조)
          컴파일 타임 단정문, 부스트 MPL 라이브러리 등이 여기에 포함됩니다. MPL 에서 한가지 꼽는다면 타입 등의 컴파일 타임 개체를 STL스러운 자료구조로 관리할 수 있도록 지원 한다는 것입니다. 역시 예제를 보시죠.
          
          // 세 개의 타입(float, double, long double)을 담는 컴파일 타임
          // 컨테이너를 list 비슷하게 만들고, 이것을 "floats"라고 부릅니다.
          typedef boost::mpl::list<float, double, long double> floats;
          
          // 기존의 "floats"에 들어 있는 타입 집합은 물론이고 그 집합의 앞에 "int"가 삽입된
          // 새로운 타입 리스트를 만들고, 이것을 "types"라고 부릅니다.
          typedef boost::mpl::push_front<floats, int>::type types;
          
          타입을 담아 관리할 수 있는 이런 컨테이너[타입리스트(typelist)라고 알려져 있습니다.] 덕택에, 정말 강력하고 많은 주목을 받고 있는 TMP의 무궁무진한 활용이 더욱 쉬워졌다고 할 수 있겠습니다.
        • 수학 및 수치 조작
          유리수, 4원수(quaternion) 및 8원수(octonion), 최대 공약수 및 최소 공배수, 난수(TR1의 그 난수 기능에 지대한 영향을 준 라이브러리) 등이 포함됩니다.
        • 정확성 유지 및 테스트
          암시적 템플릿 인터페이스(항목 41 참조)를 형식화해 주는 라이브러리와 테스트 우선 프로그래밍을 가능하게 해 주는 라이브러리가 있습니다.
        • 자료구조
          타입 안전성을 갖춘 공용체(크기와 쓰임이 가지가지인 "어떤" 타입도 담을 수 있는 자료구조), 그리고 TR1에서 지원하는 것의 뿌리격인 바로 그 투플 라이브러리(항목 54 참조)가 이 범주에 들어갑니다.
        • 타 언어와의 연동 지원
          C++와 파이썬 사이의 걸림돌 없는 상호운용을 가능하게 하는 라이브러리도 지원합니다.
        • 메모리
          고성능의 크기 고정 할당자를 지원하는 풀(Pool) 라이브러리(항목 50 참조) TR1에도 (일부) 포함된 가지각색의 스마트 포인터(항목 13 참조)가 이 범주에 들어갑니다. TR1에 속하지 않은 스마트 포인터 중 하나가 scoped_array 입니다. 동적으로 할당된 배열에 대해 동작하는 auto_ptr 같은 스마트 포인터라고 보시면 되겠는데요, 항목 44에서 살짝 구경하실 수 있습니다.
        • 기타
          CRC 점검, 날짜 및 시간 조작, 파일 시스템 횡단 등을 지원하는 라이브러리가 주요 구성요소입니다.
        위에서 언급된 몇 개의 라이브러리는 부스트 사이트에서 자주 눈에 띄게 될 것들을 뽑아 놓았을 뿐이라는 점을 덧붙여 둡니다.