Effective STL(번역서) 정리

• Chapter 1   효과적인 컨테이너(Container) 요리법

  1. 적재적소에 알맞은 컨테이너를 사용하자 / 40

     • STL에는 많은 컨테이너들이 있습니다. 다양한 컨테이너의 종류를 정리해 보도록 합시다.

       • 표준 STL 시퀸스(sequence) 컨테이너: vector, string, deque, list.
       • 표준 STL 연관(associative) 컨테이너: set, multiset, map, multimap.
       • 비표준 시퀸스 컨테이너: slist(단일 연결 리스트), rope(대용량 string). 비표준 컨테이너에 대해서는 항목 50에서 간략히 정리해 두었습니다.
       • 비표준 연관 컨테이너: hash_set, hash_multiset, hash_map, hash_multimap. 항목 25에서 이것에 대해 다루게 되겠습니다.
       • string 대신에 사용되는 vector<char>: 간혹 이렇게 쓰면 괜찮을 때가 있는데, 항목 13에서 이것에 대해 설명하고 있습니다.
       • 표준 연관 컨테이너 대신 사용되는 vector: vector가 수행 속도나 크기 면에서 표준 연관 컨테이너보다 더 나은 경우가 있습니다. 항목 23에서 다룰 내용입니다.
       • STL에 속하지 않은 표준 컨테이너: 배열(C++ 배열), bitset, valarray, stack, queue, priority_queue. STL에 속해 있지 않기 때문에 여기에선 이것들에 대해 할 이야기는 별로 없습니다. 항목 16에서 STL컨테이너 보다 배열이 더 나은 경우를 언급하고 있고, 항목 18에서는 vector<bool> 대신 bitset을 써야 하는 이유에 대해 이야기하고 있습니다.

     • 여러분이 가장 많이 고려하는 것이 알고리즘적인 복잡도라면 다음 조언만으로도 충분하겠지만, 살다보면 신경써야 하는 것이 이것만은 아닙니다.

       vector, list, deque는 각자의 계산 복잡도를 제공하기 때문에 이를 고려하여 사용해야 한다. vector는 기본적으로 사용되는 시퀸스이다. list는 시퀸스의 중간에 빈번한 삽입, 삭제가 수행될 필요가 있을 때 사용한다. deque는 대부분의 삽입과 삭제가 시퀸스의 앞과 끝에서 일어나는 경우에 사용되는 자료 구조이다.

     • 상황에 맞는 컨테이너를 고르는 테크닉을 알아보기 전에, 우선 STL 컨테이너를 분류하는 방법에 대해 소개할 필요가 있을 것 같습니다. 우선, STL 컨테이너는 연속 메모리(continuous-memory) 컨테이너와 노드 기반(node-based) 컨테이너로 나눌 수 있습니다.

       • 연속 메모리 컨테이너(배열 기반 컨테이너(array-based container)라고도 합니다)
         동적 할당된 하나 이상(대개 하나)의 메모리 단위(chunk)에다가 데이터 요소를 저장해 두는 컨테이너입니다. 새 요소가 삽입되거나 이미 있던 요소가 지워지면(erase), 같은 메모리 단위에 있던 다른 요소들은 앞 혹은 뒤로 밀려나면서 새 요소가 삽입될 공간을 만들던지, 지워진 공간을 메웁니다. 이러한 "밀어내기" 때문에 수행 성능의 발목을 잡을 수 있고(항목 5와 14를 참고하세요), 예외 안전성(exception safety)에도 영향을 미칩니다.
         
         여기에 속하는 컨테이너는 vector, string, deque입니다. 비표준 컨테이너인 rope 역시 연속 메모리 컨테이너입니다.
       • 노드 기반 컨테이너
         동적 할당된 하나의 메모리 단위에다가 하나의 요소만을 저장합니다. 컨테이너 요소를 삽입 혹은 삭제했을 때 노드의 포인터만이 영향을 받지, 노드의 내용은 그대로입니다. 따라서, 삭제나 삽입이 일어났다고 해도 나머지 요소들이 밀려난다든지 하는 일이 없습니다.
         
         연결 리스트를 나타내는 컨테이너, 즉 list와 slist가 노드 기반이고, 표준 연관 컨테이너 모두가 노드 기반 입니다(이것들은 전형적으로 균형 트리(balanced tree)로 구현되어 있습니다). 항목 25에서 확인하겠지만 비표준인 해쉬 컨테이너도 노드 기반으로 구현되어 있습니다.

     • 이제는 "어떤 상황에 어떤 컨테이너를 쓰면 가장 좋을까?"에 관련된 문답을 수월하게 정리할 수 있을 것입니다.

       • 컨테이너의 아무 위치에 요소를 삽입할 수 있어야 하나요? 그렇다면, 시퀸스 컨테이너가 필요합니다. 연관 컨테이너는 이것이 불가능합니다.
       • 컨테이너 내의 요소들의 순서 결정에 직접 관여하고 싶나요? 그렇지 않은 경우에는 해쉬 컨테이너가 가장 괜찮은 선택이고, 그렇다면 해쉬 컨테이너는 피해야 합니다.
       • 표준 C++에 포함된 컨테이너를 사용해야 하나요? 그런 경우에는 해쉬 컨테이너, slist, rope는 쓸 수 없습니다.
       • 어떤 타입의 반복자가 필요하십니까? 임의 접근 반복자이어야 한다면 여러분의 선택 폭은 vector, deque, string으로 좁아지고요, rope도 고려해 볼 수 있습니다(rope에 대해서는 항목 50을 참고하세요). 양방향 반복자가 필요한 경우에는 slist(항목 50 참조)와 해쉬 컨테이너는 쓸 수 없습니다.
       • 요소 삽입이나 삭제시 다른 컨테이너 요소들이 밀려나는 일이 없어야 한다면요? 그런 경우에는 연속 메모리 컨테이너에 손도 대지 마세요.
       • 컨테이너 내의 데이터가 C의 데이터 타입과 메모리 배열 구조적으로 호환되어야 하나요? 이 때에는 vector 밖에 쓸 것이 없습니다.
       • 탐색 속도가 가장 중요한 관심사인가요? 그렇다면 해쉬 컨테이너(항목 25 참조), 정렬된 vector(항목 23 참조), 그리고 표준 연관 컨테이너 중 하나를 택하세요.이 순서대로 고려하면 될 것입니다.
       • 컨테이너의 참조 카운팅이 신경 쓰이나요? 그렇다면 string 가까이에는 가지 않는 것이 좋습니다. 많은 string 코드가 참조 카운팅이 되도록 구현되어 있습니다(항목 13 참조). rope도 피하세요. rope는 확실히 참조 카운팅에 기반하여 구현되어 있기 때문이죠(항목 50 참조). 물론 어떻게든 문자열을 나타낼 필요가 있으므로, 이럴 때 vector<char>를 쓰는 것입니다.
       • 삽입과 삭제가 트랜잭션적인 의미를 가지고 이루어졌으면 하나요? 즉, 삽입과 삭제 동작을 안정적으로 되돌릴(roll back) 수 있어야 하느냐란 뜻입니다. 그렇다면 노드 기반 컨테이너를 고려해 보시기 바랍니다. 트랜잭션적인 삽입이 여러 개의 요소(범위로 주어집니다)에 대해 이루어져야 할 경우에는 list를 선택합니다. 그 요구를 만족할 수 있는 유일한 STL 표준 컨테이너입니다. 트랜잭션적인 동작은 코드에 예외 안전성(exception safety)을 추가하고자 하는 경우에 대단히 중요한 특징입니다(연속 메모리 컨테이너라고 해서 이것이 되지 않는다는 법은 없지만, 수행성능의 비용도 만만치 않고 코드가 간단하지 않습니다. 여기에 대해서는 항목 17과 서터의 Exceptional C++ [8]을 참고하세요).
       • 반복자, 포인터, 참조자가 무효화(포인터가 가리키고 있던 메모리의 실제 내용이 없어지는 일을 뜻한다)되는 일을 최소화해야 하나요? 이런 경우에는 노드 기반 컨테이너를 사용하기 바랍니다. 노드 기반 컨테이너는 노드 삽입과 삭제가 일어나도 기존의 반복자나 포인터 혹은 참조자가 무효화되지 않기 때문입니다(가리키고 있는 요소를 삭제하지 않는 한 말이죠). 반대로 연속 메모리 컨테이너는 전체적인 메모리 재할당이 빈번하게 일어나기 때문에 반복자나 포인터, 참조자가 무효화되기 쉽습니다.
       • 임의 접근 반복자를 지원하는 시퀸스 컨테이너가 필요한데, 요소 삭제가 일어나지 않고 요소 삽입이 컨테이너의 끝에서만 일어나는 한, 포인터와 참조자가 무효화되지 않는 것이 필요한가요? 아주 특별한 경우이긴 하지만, 어쩌다 이런 경우를 만난다면 deque가 정답입니다. deque는 요소 삽입이 끝에서 일어날 때 반복자만 무효화되는 재미있는 컨테이너입니다(STL 컨테이너 중 포인터와 참조자를 무효화시키지 않고 반복자만 무효화되는 것은 deque가 유일합니다).

  2. "컨테이너에 독립적인(container-independent) 코드"라는 환상을 조심하자 / 44

     • STL의 컨테이너들은 각각이 갖는 장단점과 특징이 있습니다. 만일 이 컨테이너에 독립적인 코드를 작성한다면, 각 컨테이너가 공통적으로 갖는 부분만을 이용해 코드를 작성해야 할 것입니다. 이는 특정 컨테이너만이 갖는 장점을 제대로 활용하기 어렵게 만듭니다.

       시퀸스 컨테이너와 연관 컨테이너 양쪽에 대해 동일하게 동작하는 소프트웨어를 만드는 일은 시도 자체가 무의미 합니다. 우선 대다수의 멤버 함수들이 한쪽 부류의 컨테이너에만 치우쳐 들어 있습니다.
       
       예를 들어 push_back과 push_front는 시퀸스 컨테이너에서만 지원되고, count와 lower_bound 등은 연관 컨테이너에서만 지원됩니다. insert나 erase 등의 기본적인 함수는 양쪽에 다 있긴 하지만, 시그너쳐나 동작 원리가 다릅니다.
       
       만일 시퀸스 컨테이너와 연관 컨테이너 양쪽에 대해 동일하게 동작하는 코드를 작성하려면, 한쪽에서만 지원하는 멤버 함수 모두를 쓸 수 없게 될 것입니다.

     • 가장 많이 쓰이는 시퀸스 컨테이너인 vector, deque, list에 대해서만 쓸 수 있는 코드를 만든다고 가정을 해 볼 수도 있습니다. 하지만, 이 경우에도 쓸만한 함수를 여럿 쓰지 못하게 되는 것은 마찬가지입니다.

       reserve나 capacity 등은 무용지물이 될 것입니다(항목 14 참조). 왜냐하면 deque와 list에서 제공하지 않거든요.
       
       list때문에 operator[]를 포함한 임의 접근 반복자를 사용하는 알고리즘에는 손도 못 대고, 양방향 반복자에 대해 동작하도록 코드를 제한시켜야 합니다. sort, table_sort, partial_sort, nth_element 등의 주옥같은 함수들을 쓸수 없다는 말이죠.
       
       그 뿐만이 아닙니다. vector를 지원하기로 했기 때문에, push_front와 pop_front는 가볍게 탈락이며, vector와 deque 덕분에 splice와 멤버 함수 형태의 sort는 찍소리도 할 수 없습니다.

     • 뭐니뭐니해도 가장 큰 주범은 반복자, 포인터, 참조자를 무효화시키는 방식이 컨테이너마다 다르다는 것에 있을 것입니다.

       vector, deque, list를 가지고 정상적으로 동작하는 코드를 작성하려면, 반복자, 포인터, 혹은 참조자를 무효화시키는 어떤 동작도 여러분이 사용하는 컨테이너에서 이루어진다고 가정해야 합니다.
       
       따라서, 우선 insert를 호출하면 모든 것이 무효화 된다고 보세요. 왜냐하면 deque::insert는 모든 반복자를 무효화하며 capacity가 지원되지 않고, vector::insert는 모든 포인터와 참조자를 무효화한다고 봐야 합니다.
       
       이와 비슷한 가정을 하다 보면 결국 erase는 "모든 것을 무효화한다"라는 결론에 다다릅니다.

     • 컨테이너에서 관리하는 데이터를 C 인터페이스에 넘기고 싶겠지만 그것도 안 됩니다. 왜냐하면 vector만 그것이 가능하기 때문이죠(항목 16 참조).

     • bool 타입을 관리하는 컨테이너를 템플릿 인스턴스로 만들 수도 없습니다. 항목 18에서 이야기하고 있듯, vector<bool>은 절대로 vector처럼 동작하지 않고, 실제로 bool 데이터를 저장하지도 않습니다.

     • list에도 상수 시간에 이루어지는 요소 삽입과 삭제를 기대해서는 되지 않습니다. vector와 deque에서는 선형 시간의 복잡도를 가지니까요.

     • 마음을 독하게 고쳐먹고 list는 지원하지 않는다는 쓰라린 결정을 내렸다고 가정합시다. 그렇다 해도 여전히 reserve, capacity, push_front, pop_front는 사용할 수 없습니다. insert와 erase는 선형 시간이 걸리고 모든 것이 무효화됩니다. C와의 데이터 호환성도 여전히 백일몽이며, bool 저장도 되지 않습니다.

     • 시퀸스 컨테이너는 포기하고 연관 컨테이너에 대해서만 독립적으로 동작하는 코드를 만들어야겠다고 생각한 분은 그럼 다행일까요? 상황은 더 좋지 않습니다.

       우선, set과 map에 대해 코딩하는 것은 불가능에 가깝습니다. set은 하나의 객체를, map은 객체의 pair를 저장하니까요.
       
       set과 multiset(혹은 map과 multimap)에 대한 독립적인 코드 작성도 힘듭니다.
       
       값(value)을 매개 변수로 가지는 insert 멤버 함수의 반환 타입은 set과 map이 각각 다르고, 컨테이너에 어떤 값의 사본(copy)이 몇 개나 저장되는지에 대해 '믿음으로써' 신경을 끄셔야 합니다.
       
       map과 multimap을 동시에 사용하려면 operator[]를 쓸 수 없습니다. 이 멤버 함수(오버로딩된 연산자)는 map에서만 지원됩니다.

     • 경우에 따라 수시로 컨테이너 타입을 바꿀 수밖에 없는 입장이라면, 변경을 조금 용이하게 해주는 방법을 쓸 수는 있습니다. 바로 "캡슐화"이지요. 가장 쉬운 방법은 컨테이너와 반복자 타입에 대해 typedef를 거는 것입니다.

       예제 코드 보기
       
       
       

       1. // 즉 다음과 같이 쓰지 말고
       2.  
       3. class Widget { ... };
       4. vector<Widget> vw;
       5. Widget bestWidget;
       6. ... // bestWidget에다가 어떤 값을 줍니다.
       7. vector<Widget>::iterator i = // bestWidget과 같은 값을 가진 Widget을
       8. find(vw.begin(), vw.end(), bestWidget); // 벡터에서 찾습니다.
       9.  
       10. // 다음과 같이 쓰는 것입니다.
       11.  
       12. class Widget { ... };
       13. typedef vector<Widget> WidgetContainer;
       14. typedef WidgetContainer::iterator WCIterator;
       15. WidgetContainer vw;
       16. Widget bestWidget;
       17. ...
       18. WCIterator i = find(vw.begin(), vw.end(), bestWidget);
       19.  
       20. // 이렇게 하면 컨테이너 타입을
       21. // 훨씬 쉽게 바꿀 수 있습니다.
       22.  
       23. // 자주 필요한 작업이 커스텀
       24. // 할당자를 붙인다든지 하는 것
       25. // (반복자/포인터/참조자 무효화
       26. // 방식에 영향을 주지 않는 변경
       27. // 입니다)이면 특히 편리하지요.
       28.  
       29. class Widget { ... };
       30. template<typename T> // 왜 여기서 템플릿이 필요한지는
       31. SpecialAllocator { ... }; // 항목 10을 참고하세요.
       32. typedef vector<Widget, SpecialAllocator<Widget> > WidgetContainer;
       33. typedef WidgetContainer::iterator WCIterator;
       34. WidgetContainer vw; // 여전히 제대로 작동합니다.
       35. Widget bestWidget;
       36. ...
       37. WCIterator i = find(vw.begin(), vw.end(), bestWidget); // 여전히 제대로 작동합니다.
       38.  
       39. // typedef를 사용한 캡슐화라고 해서
       40. // 여러분의 감동이 적을지도 모르겠지만,
       41. // 이것이 절약해 주는 작업량에 대해서는
       42. // 고마워할 확률이 높을 것입니다.
       43.  
       44. // 예를 들어, 다음과 같은 객체 타입이
       45. // 있다고 합시다.
       46.  
       47. map<string,
       48. vector<Widget>::iterator,
       49. CIStringCompare> // CIStringCompare는 "case-insensitive
       50. // string compare"의 약자입니다.
       51. // 자세한 사항은 항목 19를 참고하세요.
       52.  
       53. // 그리고 이 맵의 내부를 const_iterator를 사용해서
       54. // 이동하고 싶다면, 아마 변수 선언문 타입
       55. // 이름이 이렇게 나와야 할 것입니다.
       56.  
       57. map<string, vector<Widget>::iterator, CIStringCompare>::const_iterator
       58.  
       59. // 이것.., 한번 더 치고 싶으세요?
       60.  

       
       
       예제 코드 접기
       
       
       

     • 사실 typedef는 어떤 타입에 붙인 다른 이름에 불과하기 때문에, 이것으로 할 수 있는 캡슐화의 효과는 지극히 '문자적(lexical)'입니다. 항상 할 수 없는(혹은 의존할 수 없는) 것을 하지(혹은 의존하지) 못하도록 막는 장치는 가지고 있지 않습니다. 여러분이 만든 코드를 사용할 고객에게 '필요한' 것만 보이고 싶다면 좀 더 큰 무기인 클래스(class)를 써야 합니다.

       한 컨테이너를 다른 컨테이너로 바꿀 경우 요구되는 코드의 변경을 제한하기 위해서는 클래스에 컨테이너를 숨기고, 그 컨테이너에 관련된 정보 중에 필요한 것만 클래스 인터페이스를 통해 개방하면 됩니다.
       
       예를 들어 상품 구매자 '리스트'를 만든다고 할 때에 list를 바로 사용하지 말아야 합니다. 그 대신, CustomerList 클래스를 하나 만들고, private 영역에다가 list를 숨기는 것입니다.
       
       예제 코드 보기
       
       
       

       1. class CustomerList
       2. {
       3. private:
       4. typedef list<Customer> CustomerContainer;
       5. typedef CustomerContainer::iterator CCIterator;
       6. CustomerContainer customers;
       7. public:
       8. ... // 리스트에 관련된 정보는 인터페이스를
       9. }; // 통해 제한된 것만 보일 수 있도록 개방
       10. // 합니다.
       11.  
       12. // 나중에 어떠한 이유로
       13. // 이 리스트를 list 대신
       14. // vector나 deque를
       15. // 쓰게 만들어야 할 때,
       16. // CustomerList 클래스의
       17. // 구현 사항에 대한 캡슐화를
       18. // 꼼꼼히 잘 해두었다면
       19. // 이 클래스를 사용하는 고객이
       20. // 받는 충격(?)은 최소화될
       21. // 수 있을 것입니다.

       
       
       예제 코드 접기
       
       
       

  3. 복사(Copy)는 컨테이너 안의 객체에 맞게 비용은 최소화하며, 동작은 정확하게 하자 / 51

     • 컨테이너의 본분은 객체를 담아 관리하는 것입니다. 하지만 컨테이너가 가진 객체는 여러분이 넣어 준 그것은 아닙니다. 컨테이너에서 어떤 객체를 뽑아 내었을 때에도, 여러분의 손에 있는 그 객체는 원래 컨테이너에 있었던 것이 절대로 아닙니다.

       어떤 컨테이너에 어떤 객체를 밀어 넣을 때, 컨테이너에 들어가는 것은 여러분이 지정한 그 객체의 복사본(copy)입니다. 컨테이너에서 어떤 객체를 뽑아낼 때는 컨테이너에 들어 있던 객체의 참조자를 얻어 원하는 객체에 복사(copy)합니다(아닐 수도 있지만요).
       
       복사되어 들어가고(copy in), 복사되어 나오죠(copy out). 이것이 STL의 방식입니다.

     • 컨테이너 안에 들어 있는 객체조차도, 수시로 복사되는 것이 그렇게 유별난 일은 아닙니다. insert를 통해 vector나 string, deque 등에 어떤 데이터를 집어넣든지 아니면 erase로 지우든지 하면, 그 컨테이너에 있던 객체들은 복사를 통해 밀려나고 밀려옵니다(항목 5와 항목 14를 참고하세요).

     • 객체의 복사는 해당 클래스의 복사용 멤버 함수를 사용하여 이루어지는데, 특히 복사 생성자와 복사 대입(assignment) 연산자(operator=)가 사용됩니다.

       복사용 멤버 함수 예제 코드 보기
       
       
       

       1. // 복사 관련 함수는 대개
       2. // 다음과 같이 선언됩니다.
       3.  
       4. class Widget {
       5. public:
       6. ...
       7. Widget(const Widget&); // 복사 생성자
       8. Widget& operator =(const Widget&); // 복사 대입 연산자
       9. ...
       10. };

       
       
       복사용 멤버 함수 예제 코드 접기
       
       
       언제나처럼 이들 함수는 여러분이 클래스 안에다가 직접 선언하지 않으면 컴파일러가 자동으로 만들어 줍니다. 그리고 또 언제나처럼, 자동으로 만들어지는 복사 생성자와 대입 연산자의 동작은 단순히 비트값 자체를 복사하는 것입니다(얕은 복사).
       
       복사 생성자와 대입 연산자에 대한 이야기는 Effective C++의 항목 10과 항목 11, 항목 12에도 나옵니다.

     • 이처럼 STL에서 수시로 복사가 일어나기 때문에, 복사에 드는 비용이 큰 객체를 컨테이너에 넣을 때에는 그냥 단순히 객체를 컨테이너에 넣기만 하면 수행 성능의 병목현상을 일으키고 맙니다. 게다가, 여러분이 만든 객체의 "복사 동작"이 단순한 복사의 의미를 가지고 있지 않은 경우에는 어쩔 수 없는 슬픔이 여러분을 덮치게 됩니다(항목 8 참조).

     • 상속된 객체의 경우 복사 동작 중에 데이터가 싹둑 베이는 경우도 있습니다. 이것을 슬라이스(slice)라고 하는데, 기본 클래스(base class) 객체의 컨테이너를 만들어 놓고 여기다가 파생 클래스(derived class) 객체를 넣으면, 복사 과정에서 기본 클래스의 복사 생성자가 쓰이면서 파생 클래스 부분에 선언된 데이터는 잘려 나간다는 것입니다.

       예제 코드 보기
       
       
       

       1. vector<Widget> vw;
       2. class SpecialWidget: // SpecialWidget은 Widget에서
       3. public Widget { ... }; // 상속받았습니다.
       4.  
       5. SpecialWidget sw;
       6. vw.push_back(sw); // sw는 vw에 추가될 때 기본 클래스
       7. // 객체로서 들어갑니다. 따라서 복사
       8. // 도중에 sw만의 성질을 잃습니다.
       9.  
       10. // 이 "슬라이스 문제(slicing problem)"는
       11. // 파생 클래스 객체를 기본 클래스 객체의
       12. // 컨테이너에 삽입하는 일은 항상 에러를
       13. // 일으킨다는 사실을 알려주고 있습니다.
       14.  
       15. // 즉, 이 컨테이너에서 꺼낸 객체를
       16. // 파생 클래스 객체처럼 사용한다든지
       17. // (이를테면 파생 클래스의 가상 함수를
       18. // 호출한다든지) 하면 한치의 어김 없이
       19. // 에러가 발생합니다.
       20.  
       21. // 항목 38에는 다른 비슷한 예를
       22. // 실어 두었습니다.

       
       
       예제 코드 접기
       
       
       

     • 속도도 빠르고, 정확하고, 그리고 슬라이스 문제에도 끄떡없는 복사를 쉽게 하는 방법을 알려드리겠습니다. 바로 객체의 컨테이너가 아닌, 포인터의 컨테이너입니다. 말하자면, Widget의 컨테이너를 생성하지 않고 Widget*의 컨테이너를 생성하는 것입니다.

       포인터의 복사는 일단 속도가 빠르고, 예상했던 대로 정확히 동작하며(포인터를 이루는 비트를 복사하니까요), 포인터가 복사될 때 잘려나가는 데이터가 생기지도 않습니다.
       
       하지만, 재수 없게도 포인터의 컨테이너는 STL에 관련된 골칫거리를 안고 있습니다. 이것에 대해서는 이야기가 좀 길기 때문에 항목 7과 33에 자리를 따로 마련했습니다. 결론부터 말하자면 방금 이야기한 골칫거리를 피하는 데에는 스마트 포인터(smart pointer)가 괜찮은 한 가지 방법입니다.

     • 어찌 보면 STL은 미친듯이 복사만 하는 라이브러리라고 느끼게 할 수 있을 것 같습니다. 분명히 STL은 복사를 많이 하긴 하지만, STL은 일반적으로 "불필요한" 복사를 피하도록 설계되었습니다. 이것은 사실입니다. 실제로 STL은 일반적으로 불필요한 복사 "생성"을 피하도록 설계되었습니다.

       C나 C++의 '기본 컨테이너'인 배열의 동작 방식과 STL을 비교해 보면 바로 알 수 있습니다. 배열을 생성하면 배열이 담는 원소의 개수만큼의 기본 생성자가 호출됩니다. 즉 당장 사용하지 않는 객체가 배열의 크기만큼 생성됩니다.
       
       반면 STL의 vector는, 필요할 때마다 크기가 자라게 할 수 있습니다. 물론 벡터가 처음부터 일정 수의 객체를 담을 수 있는 공간을 미리 가지고 있게 할 수도 있습니다. 하지만 공간을 미리 가지고 있더라도, 빈 공간에 대해서 기본 생성자는 호출이 되지 않습니다.
       
       STL 컨테이너는 필요한 만큼의 객체만을 생성하고(물론 복사를 통해서), 여러분의 지시가 직접 떨어질 때만 객체 생성을 수행합니다. 게다가 기본 생성자 호출 역시 여러분 허가 없이는 하지 않습니다.

  4. ★ size()의 결과를 0과 비교할 생각이라면 차라리 empty를 호출하자 / 54

     • size()의 결과와 0을 비교하는 것은 empty()를 호출하는 것과 본질적으로 똑같습니다. 하지만 size()는 항상 상수 시간에 수행된다는 보장이 없고, empty()는 항상 상수 시간에 수행됩니다.

       이유는 list의 splice 함수와 밀접한 관련이 있습니다. splice 함수는 객체의 복사를 하지 않고, list의 특정 요소들을 다른 list로 옮길 수 있는 함수입니다.
       
       list의 size()가 상수 시간에 수행되도록 하려면, list 객체 내에 리스트의 요소가 몇 개 존재하는지를 담아두는 멤버를 하나 준비하고, 요소의 수를 변경시킬 수 있는 모든 경우에 이 멤버 변수의 값을 갱신 해야 합니다.
       
       물론 splice 함수도 마찬가지로 요소의 수를 담는 멤버 변수를 갱신 해야 하고, 이를 위해서 splice가 호출될 때마다 옮긴 요소의 수를 세어야 하므로, splice 함수가 상수 시간에 수행되도록 만들 수가 없게 됩니다.
       
       여러 STL 제품에서 list를 다르게 구현해 놓고 있습니다. 예상하고 있겠지만 구현을 맡은 개발자가 size와 splice 중 어디에 비중을 두고 있는지에 따라, splice가 상수 시간에 수행되는 대신 size가 상수 시간에 수행되지 않을 수도 있고 그 반대일 수도 있습니다.
       
       지금 쓰는 라이브러리의 list에서 size()가 상수 시간에 수행된다고 하더라도 나중에 라이브러리를 교체하거나, 다른 플랫폼으로 포팅할 일이 생길 지도 모릅니다. 그러므로 size()의 결과를 0과 비교하기보다는 empty()를 호출하는 것이 좋습니다.

  5. ★ 단일 요소를 단위로 동작하는 멤버 함수보다 요소의 범위를 단위로 동작하는 멤버 함수가 더 낫다 / 57

     • 단일 요소를 단위로 동작하는 멤버 함수(이하 단일 요소 함수)보다 요소의 범위를 단위로 동작하는 멤버 함수(이하 범위 멤버 함수)가 성능 면에서 더 낫습니다. 만일 단일 요소 함수를 사용하여 여러 요소를 삽입하려면, 반복문을 사용할 수 밖에 없습니다. 반복문을 사용하여 요소를 하나씩 삽입하면 타자량도 많고, 가독성도 그다지 좋다고 할 수 없습니다.

       예제 코드 보기
       
       
       

       1. vector<Widget> v1, v2; // v1과 v2는 Widget을 담는 벡터라고
       2. // 가정합시다.
       3. ...
       4.  
       5. // v1의 내용을 v2의 뒷쪽 반과
       6. // 똑같이 만드는 가장 빠른 방법은
       7. // 무엇일까요?
       8.  
       9. // 정답은 assign을 사용하여
       10. // 다음과 같이 짧게 작성할 수 있습니다.
       11.  
       12. v1.assign(v2.begin() + v2.size() / 2, v2.end());
       13.  
       14. // 반복문을 사용하면
       15.  
       16. v1.clear();
       17. for (vector<Widget>::const_iterator ci = v2.begin() + v2.size() / 2;
       18. ci != v2.end();
       19. ++ci) {
       20. v1.push_back(*ci);
       21. }
       22.  
       23. // 직접적으로 루프를 피해야 하는 이유는
       24. // 항목 43에서 상세하게 이야기해
       25. // 두었습니다.
       26.  
       27. // 하지만 assign을 호출하는 것이
       28. // 손이 덜 간다는 것은 뻔합니다.
       29.  
       30. // 루프를 피하는 한 가지 방법은
       31. // 항목 43에 써 둔 제안대로
       32. // 알고리즘을 사용하는 것입니다.
       33.  
       34. v1.clear();
       35. copy(v2.begin() + v2.size() / 2, v2.end(), back_inserter(v1));
       36.  
       37. // 타자량이 훨씬 많이 줄긴 했지만,
       38. // assign을 사용한 예제보다는
       39. // 여전히 타자량이 많습니다
       40. // (약간이지만...).
       41.  
       42. // 게다가 copy의 내부를 보면
       43. // 결국 루프를 사용하여 구현되어 있습니다.
       44.  
       45. // 삽입 연산자(inserter, back_inserter,
       46. // front_inserter)를 사용해서 복사 대상
       47. // 범위를 지정하는 copy는 거의 모두
       48. // 범위 멤버 함수로 바꿀 수 있고,
       49. // 바꿔야 합니다.
       50.  
       51. // 위의 copy는 insert의 범위 함수
       52. // 버전으로 대체할 수 있습니다.
       53.  
       54. v1.insert(v1.end(), v2.begin() + v2.size() / 2, v2.end());
       55.  
       56. // copy는 복사의 의미에 초점이 맞춰진 반면,
       57. // insert는 삽입의 의미에 초점이 맞춰져
       58. // 좀 더 명확하게 의미 전달이 됩니다.

       
       
       예제 코드 접기
       
       
       단일 요소 멤버 함수보다 범위 멤버 함수가 더 좋은 이유를 이미 두 가지나 확인했습니다.
       • 범위 멤버 함수를 사용한 코드가 대개 짧다(즉, 프로그래머의 손이 덜 아프다).
       • 범위 멤버 함수는 훨씬 명확하고 간결한 의미를 전달한다.

     • 만일 배열에 있는 데이터를 벡터의 앞 부분으로 옮긴다고 생각해 봅시다. 이 경우 단일 요소 함수를 쓰는 것 보다 범위 멤버 함수를 쓰는 것이 좋은 이유가 3 가지나 있습니다. 첫째, 단일 요소 함수는 배열의 멤버 수 만큼 호출되어야 하지만, 범위 멤버 함수는 딱 한 번만 호출되면 되므로 함수 호출 비용이 적게 듭니다. 물론 인라인 함수인 경우에는 차이가 없지만 모든 단일 요소 함수가 인라인인 것은 아닙니다.

     • 둘째, 벡터에 들어 있던 기존의 데이터들을 미는 횟수에서 차이가 납니다. 단일 요소 함수는 배열의 요소들을 하나 씩 삽입하기 때문에 총 복사 횟수는 (배열의 총 요소 수) * (벡터에 들어 있던 요소의 수) 만큼이 됩니다. 반면 범위 멤버 함수의 경우 몇 개가 삽입되는지를 미리 알 수 있기 때문에, (벡터에 들어 있던 요소의 수) 만큼만 복사(딱 한번만 밉니다)가 일어납니다.

     • 셋째, 메모리 할당에 관한 것입니다. 대부분의 경우 벡터는 메모리가 꽉 찰 때마다 자신의 용량을 두 배로 늘리도록 구현이 되어 있습니다. 즉 n개의 새 데이터 요소를 하나씩 삽입하려고 하면 메모리 할당을 log₂n번이나 하게 되는 셈입니다. 반면 범위 멤버 함수를 쓰면 삽입할 요소의 수를 미리 알 수 있으므로 딱 한 번 필요한 메모리를 할당하면 됩니다.

     • vector에 대해서 설명드린 내용은 string에서도 동일하게 적용됩니다. deque의 경우에는 비슷하긴 하지만 vector나 string과는 다른 메모리 관리 방식을 취하고 있어서 "반복적인 메모리 재할당"에 관한 이야기는 맞지 않습니다. 하지만 불필요하게 빈번한 컨테이너 내 요소의 이동이나, 불필요한 함수 호출에 관한 이야기는 일반적으로 맞습니다.

     • list 역시, 범위 멤버 함수가 단일 요소 함수보다 수행 성능에서 우수합니다. 되풀이되는 함수 호출에 있어서는 역시 범위 버전이 좋습니다. 하지만 list는 노드 기반으로 동작하기 때문에 메모리 할당에 관한 사항은 딱 맞지 않습니다. 그 대신에 리스트의 노드를 연결하는 next 포인터와 prev 포인터 값이 불필요하게 되풀이해서 세팅되는 문제가 생깁니다.

     • 최소한 표준 시퀸스 컨테이너에 대해서는, 단일 요소 버전의 삽입이냐, 범위 버전의 삽입이냐를 선택하는데 있어서 "프로그래밍 스타일"을 압도하는 많은 요인들을 내새울 수 있게 되었습니다. 그렇다면 연관 컨테이너에 대해서는 어떨까요? 단일 요소 버전의 insert에서 여전히 반복 함수 호출의 오버헤드가 있긴 하지만 딱 부러지게 효율이 어떻다라고는 말씀드리기 힘듭니다. 게다가 몇 가지 특수한 종류의 범위 삽입 함수들의 최적화의 여지를 가지고 있지만 이론적으로만 이러한 최적화가 존재합니다.

       하지만 연관 컨테이너에서 범위 멤버 함수를 쓴다고 해서 효율이 뒤진다든지 하는 것은 없으니 지금 쓰셔도 잃는 것은 없습니다.
       
       굳이 효율 문제가 아니더라도, 타자수를 줄여주고 나중에 읽기도 편해 이해하기 좋기 때문에 연관 컨테이너에서도 범위 멤버 함수를 쓰는 것이 좋습니다.

     • 범위를 지원하는 멤버 함수는 어떤 것인지 미리 알아놓고 정리해 두면, 나중에 이것들을 사용할 기회를 포착하기가 매우 쉬울 것입니다.

       예제 코드 보기
       
       
       

       1. // 다음에 나온 시그너쳐(signature)에서,
       2. // 매개 변수 타입인 iterator는 말 그대로
       3. // 컨테이너의 반복자 타입, 즉 container::iterator
       4. // 란 뜻입니다.
       5.  
       6. // 한편 InputIterator는 어떤 입력
       7. // 반복자도 받아들일 수 있다는 뜻입니다.
       8.  
       9.  
       10. //-----------------------------------------------------------------------------
       11. // ※ 범위 생성(Range Construction)
       12. //   모든 표준 컨테이너는 다음과 같은
       13. //   형태의 생성자를 지원하고 있습니다.
       14.  
       15. container::container(InputIterator begin, // 범위의 시작
       16. InputIterator end); // 범위의 끝
       17.  
       18. // 이 생성자에 넘겨진 반복자가
       19. // istream_iterator 혹은
       20. // istreambuf_iterator이면
       21. // (항목 29 참조), C++에서만
       22. // 볼 수 있는 가장 황당한 분석
       23. // 결과(parse)가 생깁니다.
       24.  
       25. // 이것 때문에 컴파일러는 이것을
       26. // 컨테이너 객체의 정의로 보지 않고
       27. // 함수 선언으로 이해하고 말지요.
       28. // 이에 관한 자세한 내용은
       29. // 항목 6에서 자세히 설명해
       30. // 두었습니다.
       31.  
       32.  
       33. //-----------------------------------------------------------------------------
       34. // ※ 범위 삽입(Range Insertion)
       35. //   모든 표준 컨테이너는 다음과 같은
       36. //   형태의 insert를 지원하고 있습니다.
       37.  
       38. void container::insert(iterator position, // 범위를 삽입할 위치
       39. InputIterator begin, // 삽입할 범위의 시작
       40. InputIterator end); // 삽입할 범위의 끝
       41.  
       42. // 연관 컨테이너는 자신이 가지고 있는
       43. // 비교 함수를 사용하여 삽입될 요소가
       44. // 놓일 위치를 결정하기 때문에 위치
       45. // 매개 변수를 가지고 있지 않은
       46. // 시그너쳐를 제공합니다.
       47.  
       48. void container::insert(InputIterator begin, InputIterator end);
       49.  
       50. // 단일 요소 버전의 insert를
       51. // 범위 버전으로 교체할 부분을 찾을 때
       52. // 잊지 말아야 할 것이 있습니다.
       53.  
       54. // 바로 단일 요소 함수 중에 몇몇은
       55. // 다른 함수 이름으로 위장하고
       56. // 있다는 사실입니다.
       57.  
       58. // 예를 들어, push_front와
       59. // push_back은 하나의 요소를
       60. // 컨테이너에 넣는 함수이지만 "삽입"
       61. // 류로 불리지 않지요.
       62.  
       63.  
       64. //-----------------------------------------------------------------------------
       65. // ※ 범위 삭제(Range Erasure)
       66. //   역시 표준 컨테이너에서 범위 버전의
       67. //   erase를 제공하고 있지만, 반환 타입은
       68. //   시퀸스 컨테이너와 연관 컨테이너에
       69. //   대해서 각각 다릅니다.
       70.  
       71. // 시퀸스 컨테이너에선 다음과 같은
       72. // 형태를 쓸 수 있고,
       73.  
       74. iterator container::erase(iterator begin, iterator end);
       75.  
       76. // 반면에 연관 컨테이너에서는 다음과
       77. // 같은 형태를 쓸 수 있습니다.
       78.  
       79. void container::erase(iterator begin, iterator end);
       80.  
       81. // 반환 타입이 다른 이유는
       82. // 연관 컨테이너 버전의 erase에서
       83. // 지워진 요소의 바로 뒤에 있는
       84. // 요소를 가리키는 반복자를
       85. // 반화하게 하면 납득하기 힘든
       86. // 수행 성능 저하가 생길 수 있다고
       87. // 합니다.
       88.  
       89. // vector와 string의 insert에 대한 이야기가
       90. // erase에서 통하지 않는 부분은 반복되는
       91. // 메모리 할당에 있습니다.
       92.  
       93. // vector와 string의 메모리는
       94. // 새 데이터 요소를 넣을 때에는 자동으로
       95. // 커지지만 내부의 요소 수가 줄어들
       96. // 때에는 자동으로 작아지지 않기
       97. // 때문입니다(vector나 string이
       98. // 가지고 있는 불필요한 메모리를 줄일
       99. // 수 있는 방법을 항목 17에 적어
       100. // 놓았습니다).
       101.  
       102.  
       103. //-----------------------------------------------------------------------------
       104. // ※ 범위 대입(Range Assignment)
       105. //   모든 표준 시퀸스 컨테이너는
       106. //   범위 버전의 assign을 제공하고
       107. //   있습니다.
       108.  
       109. void container::assign(InputIterator begin, InputIterator end);
       110.  
       111.  

       
       
       예제 코드 접기
       
       
       

  6. C++ 컴파일러의 어이없는 분석 결과를 조심하자 / 68

     • C++ 컴파일러는 가끔 문장을 의도하지 않은 방식으로 해석할 때가 있습니다.

       int 데이터가 들어 있는 파일을 가지고 있고, 이 파일에 들어 있는 int를 list에 복사한다고 가정해 보죠. 다음의 코드 정도가 나올 수 있을 것입니다.
       
       ifstream dataFile("ints.dat");
       list<int> data(
       istream_iterator<int>(dataFile),
       istream_iterator<int>());
       // 미리 경고입니다! 이 코드는 분명히
       // 여러분 생각대로 동작하지 않습니다.
       
       이 코드는 잘 컴파일되지만 런타임에 아무런 일도 하지 않습니다. 파일에서 데이터를 읽지도 않을 뿐더러 list 객체를 만들지도 않습니다. 이유는 컴파일러가 이 문장을 list 객체의 선언문이 아니라 함수 선언문으로 해석하기 때문입니다.

     • 기본적인 이야기부터 시작해 보겠습니다. 먼저 함수 선언문이 어떻게 생겼는지 살펴봅시다.

       아래의 코드는 double을 매개 변수로 받아 int를 반환하는 함수 f를 선언합니다.
       
       int f(double d);
       
       다음 문장을 보죠. 앞의 것과 동일한 동작을 하는 문장입니다. 매개 변수 d를 둘러싸고 있는 괄호는 불필요한 것이기 때문에 컴파일러가 무시해 버립니다.
       
       int f(double (d));
       
       앞의 문장은 다음과 같이 매개 변수의 이름을 빼고 써도 똑같습니다.
       
       int f(double);
       
       이 세 가지 형태의 선언문은 크게 낯설지는 않을 것입니다. 매개 변수 이름에 괄호를 써서 넣어 주는 두 번째 형태는 처음 보는 것일 수도 있겠지만요.
       
       이제 다른 형태의 함수 선언문 세 개를 더 보기로 하지요. 첫째 것은 함수 포인터를 매개 변수로 받는 g라는 함수입니다. 매개 변수로 들어가는 함수 포인터는 아무 것도 받아들이지 않고 double을 반환하도록 되어 있습니다.
       
       int g(double (*pf)());
       
       다음은 다른 방법으로 써본 똑같은 선언문입니다. 유일한 차이점이라면 pf에 포인터 표시(*)를 하지 않고 선언했다는 점입니다(C/C++에서 유효한 문법입니다).
       
       int g(double pf());
       
       늘 그렇듯이 매개 변수의 이름은 뺄 수 있습니다. 따라서 앞의 선언문은 다음과 같이 쓸 수 있습니다.
       
       int g(double ());
       
       여기서 알 수 있는 것이 매개 변수를 둘러싼 괄호는 무시되어도 무방한 것이지만, 그냥 괄호는 함수의 매개 변수 리스트가 있음을 나타내는 것입니다. 즉, 그 자체가 함수의 포인터임을 알리는 것이죠.

     • 이제 처음 나왔던 문제의 문장을 컴파일러가 어떻게 해석했는지 살펴봅시다.

       이상한 코드의 재등장입니다.
       
       list<int> data(
       istream_iterator<int>(dataFile),
       istream_iterator<int>());
       
       위의 문장은 리스트 객체가 아니라 data라는 이름의 함수를 선언한 것입니다. list<int>의 반환 타입을 가진 함수 말입니다. 이 함수는 두 개의 매개 변수를 받습니다. 하나씩 설명해 보죠.
       
       
       • 첫째 매개 변수는 dataFile이란 이름을 가지고 있습니다. 타입은 istream_iterator<int>입니다. dataFile를 둘러싸고 있는 괄호는 불필요한 것이므로 컴파일러가 무시해 버립니다.
       • 둘째 매개 변수는 이름을 가지고 있지 않습니다. 타입은 아무 것도 받아들이지 않고 istream_iterator<int>을 반환하는 함수 포인터입니다.

     • C++ 프로그래밍을 조금 해 본 분이라면 이 규칙이 적용된 다른 경우를 분명히 만났을 것입니다.

       다음과 같은 실수를 얼마나 많이 하셨겠습니까?
       
       // Widget 클래스엔
       // 기본 생성자가 있습니다.
       class Widget{...};
       Widget w();
       
       이 문장은 w라는 이름을 가진 Widget 객체를 선언하지 않습니다. 아무 것도 받아들이지 않고 Widget을 반환하는 함수 w를 선언할 뿐이죠. 이런 금기 사항을 알아내는 방법을 배우는 것이 C++ 프로그래머가 거쳐가게 되는 진정한 의식이라고도 합니다.

     • 무엇이 문제인지 알았으니 이제 해결을 봐야겠죠. 처음 나왔던 문장이 원래 의도대로 작동하게 하는 방법을 살펴봅시다.

       형식 매개 변수 선언을 괄호로 둘러싸는 것은 맞지 않지만, 함수의 매개 변수는 괄호로 둘러싸도 됩니다. 따라서 문제의 앞의 코드는 괄호 한 쌍으로 해결할 수 있습니다.
       
       list<int> data(
       (istream_iterator<int>(dataFile)),
       istream_iterator<int>());
       
       이렇게 하면 data라는 리스트 객체가 제대로 생성됩니다. 알아두면 확실히 도움이 될 것입니다.
       
       하지만 운도 참 나쁩니다. 모든 컴파일러가 이 문장을 제대로 컴파일 하는 것은 아닙니다. 여러분이 사용하는 컴파일러가 이 문장을 제대로 컴파일하지 못한다면, 다음의 더 좋은(확실한) 방법을 사용할 수 있습니다.
       
       istream dataFile("ints.dat");
       istream_iterator<int>
       dataBegin(dataFile);
       istream_iterator<int>
       dataEnd;
       list<int> data(dataBegin, dataEnd);
       
       이 방법은 컴파일러에 상관없이 사용할 수 있습니다. STL 프로그래밍 스타일에 거꾸로 가는 방법이긴 하지만, 이 정도는 컴파일러와 프로그래머 모두에게 혼란을 주는 코드 대신에 지불하는 가격이라고 생각하면 인생이 편해집니다.

  7. new로 생성한 포인터의 컨테이너를 사용할 때에는 컨테이너가 소멸되기 전에 포인터를 delete하는 일을 잊지 말자 / 72

     • 컨테이너는 자신이 소멸될 때 각 요소 자체를 없애 주기는 합니다. 하지만 요소의 타입이 포인터인 경우엔 포인터의 소멸자가 아무런 일도 하지 않기 때문에, new로 동적할당한 객체의 포인터를 담는 컨테이너가 소멸될 때에 각 요소를 delete 해 주지 않으면 메모리 누수가 일어납니다.

       예제 코드 보기
       
       
       

       1. // 다음의 코드는 메모리가 줄줄 새는데도
       2. // 자랑이라고 그냥 있는 코드입니다.
       3.  
       4. void doSomething(void)
       5. {
       6. vector<Widget*> vwp;
       7. for (int i = 0; i < SOME_MAGIC_NUMBER; ++i)
       8. vwp.push_back(new Widget);
       9. ... // vwp를 사용합니다.
       10. } // Widget은 여기서 샙니다!!
       11.  
       12. // 앞의 코드는 메모리 삭제가
       13. // 제대로 이루어지도록 아주
       14. // 간단히 고칠 수 있습니다.
       15.  
       16. void doSomething(void)
       17. {
       18. vector<Widget*> vwp;
       19. ... // 예전과 같습니다.
       20. for (vector<Widget*>::iterator i = vwp.begin();
       21. i != vwp.end();
       22. ++i)
       23. delete *i;
       24. }
       25.  
       26. // 이 코드는 무난하지만 여전히
       27. // 문제가 남아 있습니다.
       28.  
       29. // 한 가지 문제는 for_each가 하는
       30. // 일을 for 루프로 대신하고
       31. // 있는데, 이것은 for_each 만큼
       32. // 명확하지 못하다(항목 43을 참조)는
       33. // 것입니다.
       34.  
       35. // 또 한 가지의 문제는
       36. // 이 코드는 예외 안전성
       37. // (exception safety)을
       38. // 갖추고 있지 않다는 것입니다.
       39.  
       40. // delete를 수행하는 for문 직전에
       41. // 예외가 발생하면, 불쌍한
       42. // 메모리는 다시 샙니다.
       43.  
       44. // for_each와 비슷하게 만든
       45. // for 루프를 for_each로 바꾸려면
       46. // 우선 delete를 수행하는 부분을
       47. // 함수 객체(혹은 함수)로
       48. // 바꾸어야 합니다.
       49.  
       50. template<typename T>
       51. struct DeleteObject: // 이러한 상속을 쓴 이유에 대해서는
       52. public unary_function<const T*, void> { // 항목 40에서 알게 됩니다.
       53. void operator()(const T* ptr) const {
       54. delete ptr;
       55. }
       56. };
       57.  
       58. // 이제 코드를 바꾸어 봅시다.
       59.  
       60. void doSomething(void)
       61. {
       62. ... // 종전과 똑같습니다.
       63. for_each(vwp.begin(), vwp.end(), DeleteObject<Widget>());
       64. }
       65.  
       66. // 여기서는 DeleteObject가 삭제하려고
       67. // 하는 객체의 타입을 직접
       68. // 지정해 주어야 합니다.
       69.  
       70. // 이는 추적이 힘든 버그를
       71. // 일으킬 수 있습니다.
       72. // 다음 예시를 봅시다.
       73.  
       74. class SpecialString: public string { ... };
       75.  
       76. // 이 클래스는 시작부터가
       77. // 위험 덩어리입니다.
       78.  
       79. // 왜냐하면 string은 여느
       80. // 표준 STL 컨테이너처럼
       81. // 가상 소멸자를 가지고 있지
       82. // 않기 때문입니다.
       83. // 이것이 문제가 되는 이유는
       84. // Effective C++의 항목 7에
       85. // 다루어져 있습니다.
       86.  
       87. // 이제 진짜 문제가 발생하는
       88. // 부분을 한 번 볼까요?
       89.  
       90. void doSomething(void)
       91. {
       92. deque<SpecialString*> dssp;
       93. ...
       94. for_each(dssp.begin(). dssp.end(), // 정의되지 않은 동작이 일어납니다!
       95. DeleteObject<string>()); // 가상 소멸자가 없는 기본 클래스의
       96. } // 포인터를 가지고 파생 객체를 삭제
       97. // 하려고 합니다.
       98.  
       99. // dssp는 SpecialString* 포인터를
       100. // 담고 있도록 선언된 데크입니다.
       101.  
       102. // 하지만 for_each를 만든
       103. // 사람은 DeleteObject에게
       104. // string* 포인터를 삭제하도록
       105. // 지시하고 있지요.
       106.  
       107. // 어떤 에러가 일어날 지는
       108. // 불을 보듯 뻔합니다.
       109.  
       110. // 이러한 에러를 없애기 위해
       111. // DeleteObject를 조금
       112. // 고칠 수 있습니다.
       113.  
       114. struct DeleteObject { // 템플릿 선언부와 기본 클래스가
       115. // 없어졌습니다.
       116. template <typename T> // 템플릿이 여기서 선언됩니다.
       117. void operator()(const T* ptr) const {
       118. delete ptr;
       119. }
       120. };
       121.  
       122. // 이제 컴파일러는 DeleteObject::operator()에
       123. // 넘겨지는 포인터의 타입을 알 수 있습니다.
       124.  
       125. // 이 방법은 DeleteObject의 응용도를 떨어뜨린다는
       126. // 단점이 있지만(항목 40 참조), DeleteObject가
       127. // 설계된 지금의 용도를 고려하면 얼마나
       128. // 문제가 될지는 모르겠군요.
       129.  
       130. // SpecialString의 사용자는
       131. // 새로 만든 DeleteObject를 가지고
       132. // 다음과 같이 앞의 코드를
       133. // 고칠 수 있습니다.
       134.  
       135. void doSomething(void)
       136. {
       137. deque<SpecialString*> dssp;
       138. ...
       139. for_each(dssp.begin(), dssp.end(),
       140. DeleteObject()); // 이제 예상한 대로 동작합니다!
       141. }
       142.  
       143. // 하지만 예외 안전성이 없다는
       144. // 슬픈 현실은 여전히 남아
       145. // 있습니다.
       146.  
       147. // for_each가 호출되기 전에
       148. // 예외가 발생하면 누수테러단이
       149. // 여러분을 덮치지요.

       
       
       예제 코드 접기
       
       
       

     • 예외 안전성을 갖추는 가장 간단한 방법은 아마도, 포인터의 컨테이너 대신에 스마트 포인터(smart pointer, More Effective C++에서는 항목 28에 다루고 있습니다)의 컨테이너를 사용하는 것입니다.

       그러나 STL 자체에서는 참조 카운팅이 되는 스마트 포인터가 포함되어 있지 않은데다가, 제대로 된 것을 하나 만들기도 꽤 까다롭습니다.
       
       다행스러운 점은 검증된 구현 코드들을 그리 어렵지 않게 찾을 수 있다는 것입니다. 그 중 하나가 Boost(부스트) 사이트(www.boost.org)에 있는 라이브러리(항목 50 참조)에서 구할 수 있는 shared_ptr입니다.
       
       shared_ptr을 사용하면 다음과 같이 코드를 고칠 수 있습니다.
       
       shared_ptr 예제 코드 보기
       
       
       

       1. void doSomething(void)
       2. {
       3. typedef boost::shared_ptr<Widget> SPW; // SPW은 "shared_ptr to
       4. // Widget"이라는 뜻입니다.
       5. vector<SPW> vwp;
       6. for (int i = 0; i < SOME_MAGIC_NUMBER; ++i)
       7. vwp.push_back(SPW(new Widget)); // Widget*을 사용하여 SPW를
       8. // 생성하고, 이 SPW에 대해서
       9. // push_back을 호출합니다.
       10. ... // vwp를 사용합니다.
       11. } // 여기 오더라도 Widget 객체는 새지 않습니다. 또
       12. // 위의 코드가 수행되다가 예외가 발생하더라도
       13. // 객체 메모리가 새지 않습니다.
       14.  

       
       
       shared_ptr 예제 코드 접기
       
       
       

     • 여기서 절대로 하지 말아야 할 어리석은 생각이 있습니다. 바로 auto_ptr의 컨테이너를 생성하여 포인터들이 자동으로 삭제되게 할 수 있지 않을까? 라는 생각입니다. 재앙을 가져 오는 무시무시한 생각이니, 꿈에서나 상상하기 바랍니다. 이것을 피해야 하는 이유는 항목 8에 써 놓았습니다.

     • 마지막으로, DeleteObject같은 구조체에서 힌트를 얻어, 혹시 그와 비슷한 DeleteArray 구조체를 만들어서 배열의 포인터를 가진 컨테이너의 메모리 누수를 막을 수 있지 않을까? 하는 생각한 분들이 있을 것 같습니다. 확실히 가능하긴 하지만 추천할 만한 방법은 아닙니다. 항목 13은 동적 할당된 배열이 vector나 string 객체보다 나쁜 이유를 설명한 항목이니 참고하세요.

  8. auto_ptr의 컨테이너는 절대로 만들지 말자 / 78

     • auto_ptr의 컨테이너(COAP: Container Of A(a)uto_P(p)tr)는 절대 금지입니다. COAP를 만드는 코드는 컴파일조차 되어서는 안됩니다. 이것 때문에 C++ 표준화 위원회에서도 말 못할 노력을 많이 했다고 합니다.

       하지만 아직 몇몇 컴파일러들이 COAP를 허용합니다.

     • 위의 설명과 같은 이유로, COAP를 쓰는 코드는 이식성이 떨어집니다. COAP를 쓰는 코드는, 표준을 따르는(COAP를 허용하지 않는) 컴파일러와 그렇지 않은(COAP를 허용하는) 컴파일러간에 이식이 되지 않을 것입니다.

     • 코드의 이식성을 따지지 않는다고 해도, 이보다 더 중요한 문제가 남아있습니다. auto_ptr의 독특한 복사 방식이 문제가 됩니다.

       auto_ptr 하나를 복사하면, auto_ptr이 가리키는 객체의 소유권은 복사하는(copying) auto_ptr로 옮겨지고 복사되는(copied) auto_ptr는 NULL로 세팅됩니다. auto_ptr을 복사하는 것은 '그 포인터의 값을 바꾸는 것이다'라고 말할 수 있겠습니다.
       
       이러한 auto_ptr의 복사 방식은 여러 문제를 일으킬 수 있습니다.
       
       예제 코드 보기
       
       
       

       1. //-----------------------------------------------------------------------------
       2. // 다음 코드는 겉보기엔 아무런
       3. // 죄가 없어 보입니다.
       4.  
       5. bool WidgetAPCompare(const auto_ptr<Widget>& lhs,
       6. const auto_ptr<Widget>& rhs)
       7. {
       8. return *lhs < *rhs; // 이 코드에서는 Widget에 대해 operator<
       9. } // 연산자가 있다고 가정해 둡시다
       10.  
       11. vector<auto_ptr<Widget> > Widgets; // 벡터를 생성하고 이것에다가 Widget의
       12. ... // auto_ptr를 채웁니다.
       13.  
       14. sort(Widgets.begin(), Widgets.end(), // 벡터를 정렬합니다.
       15. WidgetAPCompare);
       16.  
       17. // 모든 것이 멀쩡해 보입니다.
       18. // 하지만 결과는 그렇지 않습니다.
       19.  
       20. // 우선 Widgets에 들어 있는 한 개
       21. // 이상의 auto_ptr들이 sort가
       22. // 수행되는 도중에 NULL로 세팅될
       23. // 것입니다.
       24.  
       25. // 벡터를 정렬하면 내부 요소의
       26. // 값이 바뀔 수 있다는 것이죠!
       27.  
       28.  
       29. //-----------------------------------------------------------------------------
       30. // 지금부터 그 이유를 살펴봅시다.
       31.  
       32. // sort는 보통 변형된 퀵소트
       33. // 알고리즘을 사용하고 있습니다.
       34.  
       35. // 즉 sort는 다음과 같이
       36. // 구현되어 있다고 할 수 있겠습니다.
       37.  
       38. template<typename RandomAccessIterator, // 이 sort 선언문은
       39. class Compare> // 표준안에서 바로
       40. void sort(RandomAccessIterator first, // 복사해 온 것입니다.
       41. RandomAccessIterator last,
       42. compare comp)
       43. {
       44. // typedef에 대해서는 아래에서 설명하겠습니다.
       45. typedef typename iterator_traits<RandomAccessIterator>::value_type
       46. ElementType;
       47. RandomAccessIterator i;
       48. ... // i가 피벗 요소를 가리키도록 합니다.
       50. ElementType pivotValue(*i); // 피벗 요소를 임시 지역 변수에
       51. // 복사합니다. 이에 대한 자세한 사항은
       52. // 아래에서 설명하겠습니다.
       54. ... // 정렬 작업에 필요한 나머지를 수행합니다.
       55. }
       56.  
       57. // typedef가 사용된 부분은
       58. // sort로 넘겨진 반복자가
       59. // 가리키는 객체의 타입을
       60. // 참조하는 STL 만의 깔끔한(?)
       61. // 방식입니다.
       62.  
       63. // 여기서 문제가 되는 부분은
       64.  
       65. ElementType pivotValue(*i);
       66.  
       67. // 이 부분입니다.
       68.  
       69. // 이 문장은 정렬될 범위
       70. // 안에 있는 요소를 임시
       71. // 지역 변수로 복사합니다.
       72.  
       73. // 현재의 경우 이 요소는
       74. // auto_ptr<Widget>이므로,
       75. // "복사되는" auto_ptr는
       76. // NULL로 세팅됩니다.
       77.  
       78. // 그리고 pivotValue는 스코프
       79. // (변수 유효 범위)를
       80. // 벗어날 때 자신이 가리키고
       81. // 있는 Widget 객체를 자동으로
       82. // 삭제합니다.
       83.  
       84. // sort 함수가 복귀할 때가 되면
       85. // 벡터의 내용이 변해 있을
       86. // 것이고, Widget 객체 중 최소한
       87. // 하나는 삭제되어 있겠지요.
       88.  
       89. // 퀵소트는 재귀 알고리즘이므로
       90. // 재귀 호출이 일어날 때마다
       91. // 피벗 요소를 복사해 사용하기
       92. // 때문에, 여러 개의 벡터
       93. // 요소(auto_ptr)가 NULL로
       94. // 세팅되고 여러 개의 Widget이
       95. // 삭제되는 경우가 다반사일 것입니다.

       
       
       예제 코드 접기
       
       
       

  9. 데이터를 삭제할 때에도 조심스럽게 선택할 것이 많다 / 82

     • 컨테이너에서 특정한 값을 가진 객체를 모두 없애려면:

       컨테이너가 vector, string 혹은 deque이면, erase-remove 합성문을 씁니다.
       
       예제 코드 보기
       
       
       

       1. Container<int> c;
       2.  
       3. // Container c에서 값이 1963인
       4. // 요소를 모두 지우고 싶습니다.
       5.  
       6. // 이 방법은 컨테이너의 종류에
       7. // 따라 모두 다릅니다.
       8.  
       9. // 연속 메모리 컨테이너
       10. // (vector, deque, string)
       11. // 의 경우에는 erase-remove 합성문을
       12. // 사용합니다.
       13.  
       14. c.erase(remove(c.begin(), c.end(), 1963), // 컨테이너가 vector, string 혹은
       15. c.end()); // deque일 때 특정한 값을 가진
       16. // 요소를 없애는 가장 좋은 방법은
       17. // erase-remove 합성문을 사용
       18. // 하는 것입니다.
       19.  

       
       
       예제 코드 접기
       
       
       컨테이너가 list이면, list::remove를 씁니다.
       
       예제 코드 보기
       
       
       

       1. list<int> c;
       2.  
       3. // list에도 erase-remove 합성문이
       4. // 통하지만, 항목 44에서
       5. // 이야기하고 있듯 list의
       6. // 멤버 함수인 remove가 더
       7. // 효율적입니다.
       8.  
       9. c.remove(1963); // 컨테이너가 list일 때에는 remove 멤버 함수가
       10. // 특정한 값을 가진 모든 요소를 없애는 데에
       11. // 더 좋습니다.
       12.  

       
       
       예제 코드 접기
       
       
       컨테이너가 표준 연관 컨테이너이면, erase 멤버 함수를 씁니다.
       
       예제 코드 보기
       
       
       

       1. AssocContainer<int> c;
       2.  
       3. // 연관 컨테이너는 remove 류의
       4. // 멤버 함수를 가지고 있지 않고
       5. // remove 알고리즘을 사용하면
       6. // 컨테이너 값을 덮어써서
       7. // (항목 32 참조), 컨테이너를
       8. // 변형시킬 수 있습니다
       9. // (이에 대한 자세한 설명은
       10. // 항목 22를 참고하세요).
       11.  
       12. // 하여간 연관 컨테이너에서
       13. // 특정한 값을 가진 요소를
       14. // 지우는 것은 erase입니다.
       15.  
       16. c.erase(1963); // 컨테이너가 표준 연관 컨테이너일
       17. // 때에는 erase 멤버 함수가 특정한
       18. // 값을 가진 요소를 모두 없애는 대에
       19. // 가장 좋습니다.
       20.  

       
       
       예제 코드 접기
       
       
       

     • 컨테이너에서 특정한 술어 구문을 만족하는 객체를 모두 없애려면:

       컨테이너가 vector, string, deque이면, erase-remove_if 합성문을 씁니다.
       
       예제 코드 보기
       
       
       

       1. Container<int> c;
       2.  
       3. bool badValue(int x); // x가 "나쁘다"면 true를 반환합니다.
       4.  
       5. // badValue함수가 true를 반환하는
       6. // x를 모두 지우려고 합니다.
       7.  
       8. c.erase(remove_if(c.begin(), c.end(), badValue), // 컨테이너가 vector, string
       9. c.end()); // 혹은 deque일 때, badValue
       10. // 가 true를 반환하는 요소를
       11. // 모두 없애는 가장 좋은 방법
       12. // 입니다.
       13.  

       
       
       예제 코드 접기
       
       
       컨테이너가 list이면, list::remove_if를 씁니다.
       
       예제 코드 보기
       
       
       

       1. list<int> c;
       2.  
       3. bool badValue(int x); // x가 "나쁘다"면 true를 반환합니다.
       4.  
       5. c.remove_if(badValue); // 컨테이너가 list일 때 badValue가
       6. // true를 반환하는 요소를 모두 없애는
       7. // 가장 좋은 방법입니다.
       8.  

       
       
       예제 코드 접기
       
       
       컨테이너가 표준 연관 컨테이너이면, remove_copy_if와 swap을 쓰든지, 컨테이너 내부를 도는 루프에서 erase를 호출하면서 erase에 넘기는 반복자를 후위 증가 연산자로 증가시킵니다.
       
       예제 코드 보기
       
       
       

       1. //-----------------------------------------------------------------------------
       2. // 표준 연관 컨테이너는
       3. // 두 가지 해결 방법이
       4. // 있는데, 첫 번째 방법은
       5. // 코딩하기 쉽고, 둘째
       6. // 방법은 좀 더 효율적
       7. // 입니다.
       8.  
       9.  
       10. //-----------------------------------------------------------------------------
       11. // 쉽지만 비효율적인
       12. // 방법부터 알아보죠.
       13.  
       14. AssocContainer<int> c; // 지금, c는 표준 연관
       15. // 컨테이너 중의
       16. ... // 하나로 가정합니다.
       17.  
       18. AssocContainer<int> goodValues; // 삭제되지 말아야 할
       19. // 값들을 담아 둘 임시
       20. // 컨테이너
       21.  
       22. bool badValue(int x); // x가 "나쁘다"면 true를 반환합니다.
       23.  
       24. remove_copy_if(c.begin(), c.end(), // 삭제되지 말아야 할
       25. inserter(goodValues, // 값들을 c에서 goodValues로
       26. goodValues.end()), // 옮깁니다.
       27. badValue);
       28.  
       29. c.swap(goodValues); // c와 goodValues의 내용을
       30. // 맞바꿉니다.
       31.  
       32. // 이 방법의 단점은
       33. // 삭제되지 않는 요소를
       34. // 모두 복사했다가 옮기기
       35. // 때문에 복사에 걸리는
       36. // 비용이 우리가 생각한
       37. // 가격보다 비싸다는 것입니다.
       38.  
       39.  
       40. //-----------------------------------------------------------------------------
       41. // 원래의 컨테이너에서
       42. // 요소를 직접 삭제해서
       43. // 가격을 후려칠 수는
       44. // 있습니다.
       45.  
       46. // 하지만, 연관 컨테이너는
       47. // remove_if와 비슷한
       48. // 멤버 함수를 제공하지
       49. // 않기 때문에, c 내의
       50. // 요소를 처음부터
       51. // 횡단하는 루프를 넣어,
       52. // 요소를 직접 검사해서
       53. // 지워야 합니다.
       54.  
       55. // 이 작업은 개념상 간단하지만
       56. // 운 나쁘게도 다음과 같은
       57. // 실수를 하기 쉽습니다.
       58.  
       59. AssocContainer<int> c;
       60. ...
       61. for (AssocContainer<int>::iterator i = c.begin();
       62. i != c.end();
       63. ++i) {
       64. if(badValue(*i)) c.erase(i);
       65. }
       66.  
       67. // 이 코드는 정의되지 않은
       68. // 동작을 합니다.
       69.  
       70. // 컨테이너의 어떤 요소가
       71. // erase될 때, 이 요소를
       72. // 가리키고 있는 모든 반복자들이
       73. // 한꺼번에 무효화되고 맙니다.
       74.  
       75. // 일단 c.erase(i)가
       76. // 복귀하자마자 i는 바로
       77. // 무효화됩니다.
       78.  
       79. // 이후 루프의 ++i부분에서
       80. // 무효화된 반복자를 증가시켜
       81. // 에러가 납니다.
       82.  
       83. // 이 문제를 해결하기 위해서
       84. // erase를 호출하기 전에
       85. // 반복자 i가 c의 다음 요소를
       86. // 가리키도록 세팅하면 됩니다.
       87.  
       88. // 가장 쉬운 방법은 erase 호출
       89. // 시점에서 i에 대해 후위 증가
       90. // (postfix ++) 연산자를
       91. // 사용하는 것입니다.
       92.  
       93. AssocContainer<int> c;
       94. ...
       95. for (AssocContainer<int>::iterator i = c.begin(); // for 루프의 세번째 부분이
       96. i != c.end(); // 비어있습니다. i는 이제 아래쪽
       97. /*없음*/) { // 에서 증가됩니다.
       98. if(badValue(*i)) c.erase(i++); // *i가 가리키는 값이 '나쁜 값'이면
       99. else ++i; // i를 erase쪽으로 넘기고 부가 효과
       100. } // 에 의해 i를 증가시킵니다.
       101. // '좋은 값'인 경우 그냥 i를
       102. // 증가시킵니다.
       103.  

       
       
       예제 코드 접기
       
       
       

     • 루프 안에서 무엇인가를 하려면(객체 삭제도 포함해서):

       컨테이너가 표준 시퀸스 컨테이너이면, 컨테이너 요소를 하나씩 사용하는 루프를 작성합니다. 이때 erase를 호출할 때마다 그 함수의 반환값으로 반복자를 업데이트하는 일을 꼭 해야 합니다.
       
       예제 코드 보기
       
       
       

       1. // 루프 안에서 삭제한 데이터에 대한
       2. // 로그를 기록한다고 합시다.
       3.  
       4. // 표준 시퀸스 컨테이너라면
       5. // 다음과 같이 해결할 수 있습니다.
       6.  
       7. ofstream logFile; // 로그 정보를 기록할 파일
       8. SeqContainer<int> c;
       9. ...
       10. bool badValue(int x); // x가 "나쁘다"면 true를 반환합니다.
       11.  
       12. for (SeqContainer<int>::iterator i = c.begin();
       13. i != c.end();) {
       14. if (badValue(*i)) {
       15. logFile << "Erasing " << *i << '\n';
       16. i = c.erase(i); // erase의 반환값을 i에 저장해서
       17. } // 유효성을 유지합니다.
       18. else ++i;
       19. }
       20.  
       21. // 표준 시퀸스 컨테이너는
       22. // 특정 요소를 삭제하면
       23. // 모든 반복자가 무효화되므로
       24. // erase의 결과 반환되는
       25. // 반복자(삭제된 요소의 다음
       26. // 요소를 가리키는 반복자)를
       27. // 사용해야 합니다.

       
       
       예제 코드 접기
       
       
       컨테이너가 표준 연관 컨테이너이면, 역시 컨테이너 요소를 하나씩 사용하는 루프를 작성합니다. 이때 erase를 호출하면서 erase에 넘기는 반복자를 후위 증가 연산자로 증가시킵니다.
       
       예제 코드 보기
       
       
       

       1. // 루프 안에서 삭제한 데이터에 대한
       2. // 로그를 기록한다고 합시다.
       3.  
       4. // 연관 컨테이너의 경우에는
       5. // 삭제를 위한 루프에
       6. // 로그를 기록하는 코드를
       7. // 삽입하기만 하면 됩니다.
       8.  
       9. ofstream logFile; // 로그 정보를 기록할 파일
       10. AssocContainer<int> c;
       11. ...
       12. bool badValue(int x); // x가 "나쁘다"면 true를 반환합니다.
       13.  
       14. for (AssocContainer<int>::iterator i = c.begin(); // for 루프의 조건은 이전과 동일합니다.
       15. i != c.end();) {
       16. if (badValue(*i)) {
       17. logFile << "Erasing " << *i << '\n'; // 로그 파일을 기록합니다.
       18. c.erase(i++);
       19. }
       20. else ++i;
       21. }

       
       
       예제 코드 접기
       
       
       list의 경우 위의 두 가지 방법을 모두 사용할 수 있지만, 일반적인 관례는 vector/string/deque에 쓰는 방법처럼 list를 처리하는 것입니다. list도 마찬가지로 시퀸스 컨테이너이기 때문입니다.

  10. 할당자(allocator)의 일반적인 사항과 제약 사항에 대해 잘 알아두자 / 89

      • 할당자를 템플릿으로 만듭니다. 템플릿 매개 변수에는 여러분이 메모리를 할당하고자 하는 객체의 타입을 나타내는 T를 사용합니다.

      • pointer와 reference라는 typedef 타입을 제공하되, 항상 pointer는 T*, reference는 T&이도록 합니다.

        라이브러리 개발자는 이런 typedef 타입을 무시하고 그대로의 포인터와 참조자를 '직접' 사용할 수 있다는 것입니다. 따라서 어찌어찌 해서 새로운 포인터 타입과 참조자 타입을 제대로 제공한 할당자를 찾아냈다고 해도 별 소용이 없습니다. 왜냐하면 STL 구현 코드 자체에서 그냥 무시해 버릴 수 있거든요.

      • 할당자에는 객체별 상태를 절대로 주지 않습니다. 일반적으로, 할당자는 비정적 데이터 멤버를 가질 수 없습니다.

        이렇게 되어야 하는 근거는 list::splice 멤버 함수에서 찾을 수 있습니다.
        
        기억하고 계시겠지만, splice에 의해 어떤 리스트 요소를 다른 리스트 요소에 옮겨 붙일 때에는 복사가 일어나지 않습니다. 포인터 몇 개가 바뀌면서 원래의 리스트에 있던 노드가 다른 리스트로 자리를 찾아갈 뿐입니다. 이 때문에 splice 동작은 빠르고 예외 안전성을 갖추고 있습니다.
        
        splice함수를 사용하여, list L1에서 list L2로 일부 요소를 옮겼다고 생각해 봅시다. 그리고 이제 L2가 소멸된다고 생각해 봅시다.
        
        L2의 요소들의 일부는 L1에서 왔으므로, 그 요소들은 L1의 할당자가 메모리를 해제하는 방법과 동일한 방법으로 메모리를 해제해야 합니다. 이 때 L2와 L1의 할당자가 서로 다른 방식으로 메모리를 해제한다면 매우 골치가 아플 것이 뻔합니다.
        
        이러한 이유로 표준안에서 STL 제작자는 동일한 타입의 할당자가 동등한 것으로 가정하도록 한 것입니다.

      • 할당자의 allocate 멤버 함수에는 필요한 객체의 개수를 매개 변수로 넘깁니다. 바이트 수가 아닙니다. 또한, 이 함수는 T* 포인터(pointer라는 typedef 타입을 통해)를 반환(비록 T 객체는 아직 생성되지 않았지만)한다는 것도 잊지 맙시다.

        즉 operator new의 프로토타입이 다음과 같다면,
        
        void* operator new(size_t bytes);
        
        할당자자 allocate 멤버 함수의 프로토타입은 다음과 같을 것입니다.
        
        pointer allocator<T>::allocate(
        size_type numObjects);
        // "pointer"는 거의 항상
        // T* 에 대응된 typedef
        // 타입이라는 사실을
        // 기억하세요.
        
        

      • 표준 컨테이너(노드 기반 컨테이너)에서 필요로 하는 rebind라는 중첩 템플릿을 꼭 제공합니다.

        노드 기반 컨테이너 중 하나인 list를 예로 설명해 보겠습니다.
        
        list<int> L;
        
        사실 위의 list 선언문은 아래의 list 선언문 처럼 해석됩니다.
        
        list<int, allocator<int> > L;
        
        여기에서 allocator<int>는 메모리 할당시 전혀 호출되지 않습니다.
        
        잠깐만 고민해 봅시다. 리스트 자체는 노드(ListNode)로 구성되어 있고, 각 노드에는 앞 노드 및 뒷 노드의 포인터와 T 객체가 들어 있을 것입니다.
        
        리스트에 새 노드가 하나 추가되면 할당자에서 필요한 메모리를 떼어 와야 합니다. 하지만 우리가 필요로 하는 것은 T에 대한 메모리가 아니라 T를 담고 있는 ListNode에 대한 메모리입니다.
        
        하지만 allocator<int>는 int를 위한 메모리를 할당하기 때문에, 이 상황에서는 전혀 쓸모가 없습니다.
        
        list가 원하는 것은 자신이 가진 할당자 타입을 통해 이에 해당하는 ListNode에 대한 할당자를 찾아 내는 것인데, 이 일은 할당자 쪽에서 이러한 일을 해주는 typedef 타입을 제공하지 않으면 힘들 것입니다.
        
        예제 코드 보기
        
        
        

        1. template <typename T, // list 구현이 이렇게 되어
        2. typename Allocator = allocator<T> > // 있을 수 있다는 것입니다.
        3. class list {
        4. private:
        5. Allocator alloc; // 타입 T의 객체에 대한 할당자
        6. struct ListNode { // 연결 리스트 내의 노드
        7. T data;
        8. ListNode *prev;
        9. ListNode *next;
        10. };
        11. ...
        12. };
        13.  
        14. template <typename T> // 표준 할당자는 실제로 이렇게 선언되어
        15. class allocator { // 있지만, 사용자가 작성한 할당자
        16. public: // 템플릿이 될 수도 있습니다.
        17. template <typename U>
        18. struct rebind {
        19. typedef allocator<U> other;
        20. };
        21. ...
        22. };
        23.  
        24. // list<T>를 구현한 코드를 보면
        25. // 우리가 T에 대해 만든 할당자에
        26. // 대응하는, ListNode에 대한
        27. // 할당자 타입을 결정해야 한다는
        28. // 것을 알 수 있습니다.
        29.  
        30. // 우리가 T에 대해 만든 할당자
        31. // 타입은 템플릿 매개 변수인
        32. // Allocator입니다.
        33.  
        34. // 즉, 이 경우에 있어서 ListNode에
        35. // 대한 할당자는 이렇게 나오게
        36. // 되겠지요.
        37.  
        38. Allocator::rebind<ListNode>::other
        39.  
        40. // 할당자 템플릿 A(예를 들면
        41. // std::allocator,
        42. // Special-Allocator 등)
        43. // 가 있다고 합시다.
        44.  
        45. // A는 무엇이 되든 간에 rebind라고
        46. // 불리는 중첩된 구조체 템플릿을
        47. // 가져야 합니다. rebind는 U라는
        48. // 타입 매개 변수를 하나 받아들이고,
        49. // 하나의 typedef 타입 외에
        50. // 가지고 있는 것이 전혀 없습니다.
        51.  
        52. // 이것이 other이지요.
        53. // other는 그냥 A<U>를
        54. // 대신하는 이름입니다.
        55.  
        56. // 결과적으로, list<T>는
        57. // Allocator::rebind<ListNode>::other를
        58. // 참조함으로써 T 객체의 할당자를
        59. // 통해 ListNode의 할당자를
        60. // 찾을 수 있는 것이지요.

        
        
        예제 코드 접기
        
        
        

  11. 커스텀 할당자를 제대로 사용하는 방법을 이해하자 / 98

      • 디폴트 STL 메모리 관리자(allocator<T>) 대신 새로운 메모리 관리자가 필요할 때가 있습니다.

        디폴트 STL 메모리 관리자는 속도는 느리고, 메모리 효율은 낮고, 게다가 STL의 요구로 인한 엄청난 메모리 단편화에 몸살을 앓기 일쑤입니다.
        
        디폴트 STL 메모리 관리자가 쓰레드 안전성을 염두해 두고 만든 할당자라는 사실이 마음에 들지 않는 경우도 있습니다. 즉 단일 쓰레드 환경에만 관심이 있어서 동기화 때문에 걸리는 필요 없는 오버헤드를 피하고 싶은 것이죠.
        
        혹은, 컨테이너에 들어 있는 객체들이 하나의 힙 안에서 관리되는 점 때문에 문제를 느낄 수도 있습니다. 같은 종류의 객체를 특정한 힙에 모여있게 하여 메모리 참조 위치의 근접성(locality of reference)을 극대화하는 효과를 얻기에 부족하지요.
        
        아니면 공유 메모리에 해당하는 특수한 힙을 만들어, 하나 이상의 컨테이너를 그 메모리에 두어 여러 프로세스들이 공유할 수 있게 하고 싶을 수도 있습니다.

      • 공유 메모리 힙을 관리할 목적으로 커스텀 할당자를 제대로 사용하는 방법입니다.

        예제 코드 보기
        
        
        

        1. // 공유 메모리 힙을 관리할 목적으로
        2. // malloc과 free 함수를 본떠서 만든
        3. // 다음과 같은 루틴이 있다고 합시다.
        4.  
        5. void* mallocShared(size_t bytesNeeded);
        6. void freeShared(void *ptr);
        7.  
        8. // 그리고, 이것을 STL 컨테이너에 넣어
        9. // 공유 메모리 메커니즘을 쓰고 싶다고
        10. // 가정합시다.
        11.  
        12. template <typename T>
        13. class SharedMemoryAllocator {
        14. public:
        15. ...
        16. pointer allocate(size_type numObjects, const void *localityHint = 0)
        17. {
        18. return static_cast<pointer>(mallocShared(numObjects * sizeof(T)));
        19. }
        21. void deallocate(pointer ptrToMemory, size_type numObjects)
        22. {
        23. freeShared(ptrToMemory);
        24. }
        25. ...
        26. };
        27.  
        28. // allocate 함수를 보면 pointer 타입과
        29. // 캐스팅, 조금 알기 힘든 곱셈식
        30. // 등이 나오는데, 항목 10에서
        31. // 궁금증을 해결하시기 바랍니다.
        32.  
        33. // 자, 이렇게 만든 SharedMemoryAllocator는
        34. // 다음과 같이 사용할 수 있을 것입니다.
        35.  
        36. // 편의상 만든 typedef 타입
        37. typedef vector<double, SharedMemoryAllocator<double> > SharedDoubleVec;
        38. ...
        39. { // 블록 시작
        40. ...
        41. SharedDoubleVec v; // 내부 요소들이 공유 메모리에 있게 되는
        42. // 벡터를 생성합니다.
        43. ...
        44. } // 블록 끝
        45.  
        46. // v는 SharedMemoryAllocator를
        47. // 사용하고 있기 때문에, 벡터 요소를
        48. // 담기 위해 v에 할당된 메모리는
        49. // 공유 메모리에 있을 것입니다.
        50.  
        51. // 하지만, v 자체는 거의 확실히
        52. // 공유 메모리 안에 위치해 있지
        53. // 않습니다.
        54.  
        55. // 소스에서 알 수 있듯이 v는 보통의
        56. // 스택 기반 객체이므로, v 내부의
        57. // 데이터 멤버는 스택에 위치하게
        58. // 됩니다.
        59.  
        60. // v의 내용물과 v 자체를 진짜로
        61. // 공유 메모리에 두려면 다음과 같이
        62. // 해야 합니다.
        63.  
        64. void * pVectorMemory = // SharedDoubleVec 객체를 담을
        65. mallocShared(sizeof(SharedDoubleVec)); // 수 있는 충분한 공유 메모리를
        66. // 할당(allocate)합니다.
        67.  
        68. SharedDoubleVec * pv = // "전용 new(placement new)"를 써서
        69. new(pVectorMemory)SharedDoubleVec; // SharedDoubleVec 객체를 메모리에
        70. // 생성(construct)합니다.
        71.  
        72. ... // 이 객체를 사용합니다(pv를 통해서).
        73.  
        74. pv->~SharedDoubleVec(); // 공유 메모리 내에 있는 이 객체를
        75. // 소멸(destroy)시킵니다.
        76.  
        77. freeShared(pVectorMemory); // 공유 메모리에 있는 처음 메모리 단위
        78. // 를 해제(deallocate)합니다.
        79.  
        80. // 꼭 공유 메모리 안에다가 컨테이너를
        81. // 넣을 마음이 아니라면,
        82. // 할당/생성/소멸/해제의 4단계
        83. // 수작업을 피함이 낫다는 것이
        84. // 필자의 생각입니다.
        85.  
        86. // 이 예제에는 mallocShared() 함수가
        87. // 널 포인터를 반환할 때의 경우는
        88. // 고려하지 않았습니다.
        89. // 물론 실무에 사용할 코드라면
        90. // 이 부분은 그냥 넘어가선 안 되겠지요.
        91.  
        92. // placement new란 용어가
        93. // 생소하신 분은 More Effective C++의
        94. // 항목 8에서 몇 마디를 찾을
        95. // 수 있을 것입니다.

        
        
        예제 코드 접기
        
        
        

      • 할당자의 사용 예 두 번째는 두 개의 힙에서 메모리를 관리하는 것입니다.

        예제 코드 보기
        
        
        

        1. // 각각 Heap1과 Heap2란 이름을
        2. // 가진 클래스가 있다고 가정합시다.
        3. // 이 두 개의 힙 클래스에 메모리
        4. // 할당과 해제용으로 정적 멤버
        5. // 함수가 들어 있습니다.
        6.  
        7. class Heap1 {
        8. public:
        9. ...
        10. static void* alloc(size_t numBytes, const void *memoryBlockToBeNear);
        11. static void dealloc(void *ptr);
        12. ...
        13. };
        14.  
        15. class Heap2 { ... }; // Heap1과 동일한 alloc/dealloc 인터페이스를 가지고 있습니다.
        16.  
        17. // 이제, STL 컨테이너 몇 개를 종류에
        18. // 맞추어 제각기 다른 힙에 모아 두고
        19. // 싶습니다.
        20.  
        21. // 우선 Heap1과 Heap2 등의 클래스를
        22. // 사용하도록 설계된 할당자를 하나
        23. // 만들어 실제 메모리 관리를 맡게
        24. // 합니다.
        25.  
        26. template <typename T, typename Heap>
        27. class SpecificHeapAllocator {
        28. public:
        29. ...
        30. pointer allocate(size_t numObjects, const void *localityHint = 0)
        31. {
        32. return static_cast<pointer>(Heap::alloc(numObjects * sizeof(T),
        33. localityHint));
        34. }
        36. void deallocate(pointer ptrToMemory, size_type numObjects)
        37. {
        38. Heap::dealloc(ptrToMemory);
        39. }
        40. ...
        41. };
        42.  
        43. // 그 다음에는 SpecificHeapAllocator를
        44. // 사용하여 해당 컨테이너의 요소를
        45. // 한데 모읍니다.
        46.  
        47. vector<int, SpecificHeapAllocator<int, Heap1> > v; // v와 s의 요소는
        48. set<int, SpecificHeapAllocator<int, Heap1> > s; // Heap1에 모두
        49. // 모아 놓습니다.
        50.  
        51. list<Widget, // L과 m의 요소는
        52. SpecificHeapAllocator<Widget, Heap2> > L; // Heap2에 모두
        53. map<int, string, less<int>, // 모아 놓습니다.
        54. SpecificHeapAllocator<pair<const int, string>, Heap2> > m;
        55.  
        56. // 이 예제에서 중요한 것은
        57. // Heap1과 Heap2는
        58. // 객체가 아니라 타입이라는
        59. // 것입니다.
        60.  
        61. // 이는 항목 10에서 자세히
        62. // 설명한 할당자의 동등성
        63. // (equivalence) 제약을
        64. // 지키기 위함입니다.

        
        
        예제 코드 접기
        
        
        

  12. STL 컨테이너가 쓰레드 안전성에 대한 기대는 현실에 맞추어 가지자 / 102

      • STL 컨테이너에 있어서의 다중쓰레딩 지원이라면 SGI(실리콘 그래픽스사)에서 제정한 방식이 가장 권위 있는 표준입니다. SGI사의 STL 웹 사이트에 공개되어 있으므로 참고하면 되는데, 핵심만 설명하면 다음과 같습니다.

        • 여러 쓰레드에서 읽는 것은 안전하다(Multiple readers are safe).
          쓰레드가 하나의 컨테이너의 내용을 동시에 읽어 내는 경우가 있는데, 제대로 동작합니다. 당연한 이야기이지만 읽기 도중에 쓰기 동작이 수행되면 안 됩니다.
        • 여러 쓰레드에서 다른 컨테이너에 쓰는 것은 안전하다(Multiple writers to different containers are safe).
          하나 이상의 쓰레드가 다른 컨테이너에 동시에 쓸 수 있습니다.

      • 컨테이너의 완벽한 쓰레드 안전성을 구현하려면 라이브러리 쪽에서 어떤 것을 해야 할지 정리해 보도록 할까요?

        • 컨테이너의 멤버 함수를 호출하는 시간 동안에 컨테이너에 락(lock)을 걸기.
        • 컨테이너가 만들어 내어 주는 반복자의 유효 기간 동안에 컨테이너에 락을 걸기.
        • 컨테이너에 대해 실행된 알고리즘의 수행 시간 동안에 컨테이너에 락을 걸기(사실 불가능한 이야기입니다. 왜냐하면, 항목 32에서 보시겠지만 알고리즘은 자신이 조작하고 있는 컨테이너를 식별할 수 있는 방법을 가지고 있지 않으니까요).
        
        자 이제 다음의 코드를 보아주세요. 이 코드는 vector<int>에서 5란 값이 처음 등장하는 위치를 찾습니다. 만일 찾았으면 이 값을 0으로 바꿉니다.
        
        예제 코드 보기
        
        
        

        1. vector<int> v;
        2. ...
        3. vector<int>::iterator first5(find(v.begin(), v.end(), 5)); // 첫째 줄
        4. if (first5 != v.end()) { // 둘째 줄
        5. *first5 = 0; // 셋째 줄
        6. }

        
        
        예제 코드 접기
        
        
        다중쓰레드 환경에서는 첫째 줄의 실행이 끝난 직후에 다른 쓰레드 하나가 v의 값을 바꾸는 일이 생길 수 있습니다.
        
        만약, 첫째 줄과 둘째 줄 사이에 다른 쓰레드가 끼어 들어 벡터에 요소를 삽입한다든지 해서 메모리가 재할당되면 first5 반복자가 무효화되어 버리고 맙니다. 이렇게 되면 둘째 줄에서 first5와 v.end()를 비교하는 구문에서 정의되지 않은 실행 결과를 얻을 수 있습니다.
        
        셋째 줄도 둘째 줄과 마찬가지로 비슷하게 위험한 코드입니다.
        
        그렇다면, 앞에서 세 가지로 정리한 "락 걸기" 방법을 썼을 때 이런 문제를 막을 수 있을까요? 천만의 말씀입니다.
        
        락이 걸릴 만한 부분은 첫째 줄인데, begin과 end는 너무도 빨리 복귀하기 때문에 전혀 도움이 안되고, 이 함수로 만들어진 반복자는 첫째 줄이 끝날 때까지만 남아있고, find 역시 첫째 줄의 끝에서 바로 복귀합니다.
        
        이 코드가 쓰레드 안전성을 가지려면 v는 첫째 줄부터 셋째 줄까지 실행될 동안 계속 락이 걸린 채로 남아 있어야 합니다. 그런데 STL 제작자가 이런 경우를 자동으로 예측해서 구현하기란 상상하기도 어렵습니다.
        
        게다가 쓰레드 동기화에 사용하는 기본 장치(세마포어, 뮤텍스 등)의 비용이 그리 적잖은 것을 감안하면, 반드시 오직 하나의 쓰레드만이 첫째 줄부터 셋째 줄까지 실행할 수 있도록 작성하는 프로그램을 어떻게 "심각한 수행성능의 저하 없이" 구현할 수 있을지는 더욱 짐작하기 힘듭니다.
        

      • 이런 생각까지 하고 나면, 왜 STL 컨테이너에게 쓰레딩 문제 해결을 전적으로 믿고 맡길 수 없는지 알 수 있을 것입니다. 오히려 여러분이 직접 쓰레드 동기화를 제어해 주는 것이 낫습니다.

        앞의 예제라면 다음과 같이 할 수 있습니다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. vector<int> v;
        3. ...
        4. getMutexFor(v);
        5. vector<int>::iterator first5(find(v.begin(), v.end(), 5));
        6. if (first5 != v.end()) { // 이제 이 코드는 안전합니다.
        7. *first5 = 0; // 마찬가지입니다.
        8. }
        9. releaseMutexFor(v);
        10.  
        11.  
        12. //-----------------------------------------------------------------------------
        13. // 조금 더 객체 지향적으로 해결한다면,
        14. // 생성자에서 뮤텍스를 잡고 소멸자에서
        15. // 이 뮤텍스를 해제하는 Lock 클래스
        16. // 같은 것을 만들 수 있을 것입니다.
        17.  
        18. template <typename Container> // 컨테이너에 대한 쓰레드 동기화를 위해
        19. class Lock { // 뮤텍스를 얻고 해제해 주는 클래스의
        20. public: // 골격 템플릿. 자세한 동작 원리는 모두
        21. // 생략되었습니다.
        22. Lock(const Container& container)
        23. : c(container) {
        24. getMutexFor(c); // 생성자에서 뮤텍스를 얻어냅니다.
        25. }
        26. ~Lock(void) {
        27. releaseMutexFor(c); // 소멸자에서 이 뮤텍스를 해제합니다.
        28. }
        29.  
        30. private:
        31. const Container& c;
        32. };
        33.  
        34. // 이제 이 클래스는 다음과 같이
        35. // 사용할 수 있습니다.
        36.  
        37. vector<int> v;
        38. ...
        39. { // 새 블록을 형성합니다.
        40. Lock<vector<int> > lock(v); // 뮤텍스를 얻어 냅니다.
        41. vector<int>::iterator first5(find(v.begin(), v.end(), 5));
        42. if (first5 != v.end()) {
        43. *first5 = 0;
        44. }
        45. } // 블록을 끝냅니다. 잡고 있던 뮤텍스도
        46. // 자동으로 해제됩니다.
        47.  
        48. // Lock 객체가 컨테이너의 뮤텍스를
        49. // 해제하는 부분은 Lock의 소멸자이기
        50. // 때문에, 뮤텍스가 해제되어야 할 때
        51. // Lock 객체도 메모리에서 없어진다는
        52. // 것이 포인트입니다.
        53.  
        54. // 이렇게 동작시키려면 Lock 객체를
        55. // 정의하는 블록을 하나 만들되, 뮤텍스가
        56. // 더 이상 필요 없는 위치에서 블록을
        57. // 닫아야 합니다.
        58.  
        59. // 깜빡 잊고 새로 블록을 만들지 않았다고
        60. // 해도 뮤텍스는 언젠가는 해제됩니다.
        61.  
        62. // 게다가, Lock 클래스를 활용한 방법은
        63. // 예외에도 견고하게 동작합니다.
        64.  
        65. // C++ 스펙에 의하면 예외가 발생했을 때
        66. // 지역 객체는 모두 소멸되도록 되어 있기
        67. // 때문에, Lock 객체를 사용하는 도중에
        68. // 예외가 발생했다고 해도 Lock 클래스의
        69. // 소멸자가 안전하게 호출될 수 있습니다.

        
        
        예제 코드 접기
        
        
        

• Chapter 2   vector와 string

  13. 동적으로 할당한 배열보다는 vector와 string이 낫다 / 110

      • 지금 이 순간에도 new 연산자를 써서 동적 할당문을 작성하고 계신 분들이 많을 것입니다. 그런 분들은 어떤 생각을 하고 있을까요?

        1. "언젠가는 이 메모리를 해제해야 하겠지": 여러분이든 다른 분이든 이렇게 할당한 메모리는 이후에 꼭 해제해야 합니다. delete 없는 new는 메모리 누수란 재앙을 불러 올 뿐입니다.
        2. "delete도 메모리 타입에 따라 제대로 써야 해": 하나의 객체를 동적 할당한 경우에는 "delete" 형태를 사용하고, 배열을 할당한 경우에는 "delete[]" 형태를 사용해야 합니다. 잘못된 형태를 썼을 때의 결과는 알 수 없습니다.
        3. "delete는 new 한 번에 꼭 한 번만 호출해야 해": 두 번 이상 호출되었을 때의 결과 역시 알 수 없습니다.

      • 언제든 배열을 동적으로 할당할 자세를 잡고 코딩에 들어가기 전에(이를테면 "new T[...]"라고 쓰려고 생각했다든지), 그 대신 vector나, string을 고려해 보세요(대개 T가 문자 타입이면 string을, T가 이외의 타입이면 vector를 사용합니다).

        vector와 string은 자체적으로 메모리 관리를 하기 때문에 프로그래머가 져야 할 앞의 세 가지 부담을 없애줍니다.
        
        각 메모리는 요소가 추가되어 필요할 때마다 자라나며, vector나 string이 메모리에서 소멸될 때 각 객체의 소멸자를 통해 해당 컨테이너 안의 요소를 모두 없애줌과 동시에 각 요소들이 점유하고 있던 메모리도 해제시킵니다.
        
        또한, vector와 string은 STL 시퀸스 컨테이너의 필수사양을 완벽히 가지고 있는 컨테이너이기 때문에, STL에서 지원되는 모든 알고리즘을 그대로 적용할 수 있습니다.

      • 어쩔 수 없이 계속 지원해야 하는 기존의 '구식' 코드 때문에 배열을 쉽게 버릴 수 없는 분도 긴장할 필요가 없습니다. vector와 string은 여전히 사용할 수 있습니다. vector와 string의 데이터를 배열을 사용하는 C API에 넘기는 방법을 항목 16에 설명해 두었지요.

      • 많은 제품들이 string을 참조 카운팅이 동작되도록 구현함으로써(이 부분은 항목 15를 참고하시고요), 불필요한 메모리 할당과 문자 복사를 없앰으로써 많은 어플리케이션에서 높은 수행성능을 낼 수 있도록 하고 있습니다. 이 또한 동적으로 할당한 문자 배열 대신에 string을 사용해야할 이유가 됩니다.

        여러분이 사용하고 있는 STL 제품에서 구현된 string이 참조 카운팅이 되는 것인지 확인하는 가장 쉬운 방법은 해당 라이브러리 문서를 찾아보는 것입니다.
        
        다른 방법은(추천하는 방법은 아니지만, 꼭 필요하다면 어쩔 수 없이 봐야 하는 경우가 있습니다) string이 구현된 라이브러리 소스를 직접 살펴보는 것입니다.
        
        string은 basic_string<char>의 typedef 타입이라는 것만 잊지 마시고(wstring은 basic_string<w_char>의 typedef 타입입니다), 소스를 볼 때는 basic_string의 템플릿 소스를 찾으십시오.
        
        소스를 볼 때 참조 카운팅 여부를 체크할 수 있는 포인트는 클래스의 복사 생성자입니다. 이 부분에서 참조 카운트 값을 증가시키는 코드 비슷한 것이 있나 찾으면 됩니다.

      • 사용하고 계신 string이 참조 카운팅이 되는데 이것을 다중 쓰레드 환경에서 사용하기에는 수행 성능의 저하가 만만치 않다고 생각하셔도, STL을 버리지 않고 선택할 수 있는 길이 세 가지나 있습니다.

        1. 라이브러리에서 참조 카운팅 기능을 끌 수 있는 방법이 있는지 조사하는 것입니다. 대개 전처리자의 변수 값을 바꿈으로 이것이 가능하게 되어 있습니다. 물론 이렇게 만든 코드는 이식이 되지 않습니다만, 필요한 수작업의 양을 고려한다면 충분히 가치는 있습니다.
        2. 참조 카운팅을 사용하지 않는 다른 string을 구현(아니면 부분만 구현)하는 것입니다.
        3. string 대신에 vector<char>를 고려해 보는 것입니다. vector는 원래부터 참조 카운팅을 하지 않도록 구현되어 있어서 다중 쓰레드 환경에서의 수행 성능 문제가 발생할 틈이 없습니다. 물론, string만 가지고 있는 깔끔한 멤버 함수들(substr이나 find_if 등등)은 쓸 수 없는 아픔이 있지만 대부분의 기능은 STL 표준 알고리즘으로 어떻게든 구현되기 때문에, string스럽지 않은 모양을 제외하면 잃은 것이 별로 없습니다.

  14. ★ reserve는 필요 없이 메모리가 재할당되는 것을 막아 준다 / 113

      • STL 컨테이너에 대한 가장 신통한 특징 중 하나는 프로그래머가 신경 쓰지 않아도 추가되는 요소를 담을 수 있다는 점입니다. 새로 넣어 주는 데이터의 개수만큼 자동으로 메모리가 늘어나기 때문이지요(물론 max_size를 호출하여 알 수 있는, 최대 크기를 넘도록 늘어나지는 않습니다).

        메모리가 늘어날 때 다음 네 단계의 동작이 진행됩니다.
        1. 컨테이너의 현재 용량의 몇 배가 되는 메모리 블록을 새로 할당합니다. 대부분의 제품에서는 '2'의 증가율 만큼 용량을 늘리도록 구현하고 있습니다. 즉, 컨테이너의 메모리가 증가되어야 할 필요가 있을 때 용량이 두 배씩 늘어난다는 뜻입니다.
        2. 컨테이너가 원래 가지고 있었던 메모리에 저장된 모든 요소 데이터(객체)를 새 메모리에 복사합니다.
        3. 원래의 메모리에 저장된 모든 객체를 소멸시킵니다.
        4. 원래의 메모리를 해제(dealloc)합니다.
        
        
        할당-복사-소멸-해제. 여기서 상당한 비용이 들 수 있다는 사실은 그리 황당한 일이 아닐 것입니다. 효율 문제 외에도 이 과정이 이루어질 때마다 반복자, 포인터, 참조자가 무효화되는 문제도 있습니다.

      • reserve 멤버 함수는 사용할 메모리를 미리 할당해 둠으로써 재할당의 회수를 최소화시키고, 아울러 메모리 재할당과 반복자/포인터/참조자의 무효화로 인해 요구되는 비용 부담을 피해갈 수 있도록 해줍니다.

        reserve가 무엇인지 이야기하기 전에 STL 맨들이 간혹 헷갈리는 네 개의 관련 함수를 간단히 정리해 보도록 하겠습니다. STL의 표준 컨테이너 중에 이 네 개의 함수를 모두 지원하는 것은 vector와 string 뿐입니다.
        • size() 함수는 현재 컨테이너에 들어 있는 요소의 개수를 알려 줍니다. 즉, 해당 컨테이너가 요소를 담기 위해 할당된 메모리가 얼마나 되는지 알려주는 것이 아닙니다.
        • capacity() 함수는 해당 컨테이너에 할당된 메모리로 담을 수 있는 요소의 개수를 알려 줍니다. 이 개수는 컨테이너의 메모리에 담을 수 있는 총 요소(total element) 개수이지, 컨테이너가 현재 상태에서 더(more) 담을 수 있는 요소의 개수가 아닙니다.
        • resize(size_t n) 함수는 컨테이너가 담을 수 있는 요소의 개수를 n개로 무조건 만듭니다. 이 함수를 호출하고 나서 size를 호출하면 n이 얻어집니다. n이 현재의 요소 수(size) 보다 작으면 컨테이너의 끝 쪽에 있는 요소는 모두 소멸됩니다. 그 반대의 경우에는 기본 생성자에 의해 생성된 빈 요소가 컨테이너의 끝에 추가됩니다. n이 현재의 용량보다 크면 재할당이 일어난 후에 기본 생성 요소가 추가됩니다.
        • reserve(size_t n) 함수는 컨테이너의 용량을 최소 n개로 맞춥니다. 대개 재할당이 일어나는데, 용량이 늘어나야 하기 때문이지요(n이 현재의 용량보다 작을 경우, vector는 아무 일도 하지 않으며 string은 size()의 호출 결과의 n중에 큰 값으로 내부 용량을 줄이기도 합니다. 하지만, string의 요소 개수는 바뀌지 않습니다. reserve를 써서 string의 남는 메모리를 잘라 버리는 일은 대개 잘 통하지 않습니다. 이런 작업이 필요하다면 항목 17에서 이야기할 "바꿔치기(swap) 묘수"가 더 확실합니다).
        
        
        메모리 재할당을 피하는 포인트는 컨테이너가 생성된 바로 직후에 reserve를 써서 컨테이너의 용량을 가능한 충분히 큰 값으로 맞추는 것입니다.
        
        예제 코드 보기
        
        
        

        1. // 예를 들어, 1부터 1000까지의 값을 가지는
        2. // vector<int>를 만들고 싶다고 가정합시다.
        3.  
        4. // reserve를 쓰지 않으면 다음과 같은
        5. // 코드가 만들어질 것입니다.
        6.  
        7. vector<int> v;
        8. for (int i = 1; i <= 1000; ++i) v.push_back(i);
        9.  
        10. // 대부분의 라이브러리를 가지고 위의 코드를
        11. // 빌드하면, 루프를 도는 동안 최소 2번에서
        12. // 최대 10번의 재할당이 발생합니다
        13. // (재할당이 일어날 때 용량이 두 배씩
        14. // 불어난다고 계산하면 약 10회가 됩니다.
        15. // 1000은 2의 약 10제곱이니까요).
        16.  
        17. // 앞의 코드를 reserve를 써서 수정해
        18. // 보겠습니다.
        19.  
        20. vector<int> v;
        21. v.reserve(1000);
        22. for (int i = 1; i <= 1000; ++i) v.push_back(i);
        23.  
        24. // 이제 루프를 도는 동안 단 한 번의
        25. // 재할당도 일어나지 않습니다.
        26.  
        27. // size와 capacity의 관계를 잘 생각해
        28. // 보면, 요소 삽입시 vector나 string에서
        29. // 재할당이 일어나는 시기가 언제인지 충분히
        30. // 예측할 수 있습니다.
        31.  
        32. // 다음의 코드를 한 번 살펴보죠.
        33.  
        34. string s;
        35. ...
        36. if (s.size() < s.capacity()) {
        37. s.push_back('x');
        38. }
        39.  
        40. // 위의 push_back으로는 문자열 s의
        41. // 반복자/포인터/참조자 중에 무효화시키는
        42. // 것이 전혀 없습니다.
        43.  
        44. // 왜냐하면 문자열의 용량이 실제 요소 개수
        45. // (size)보다 많도록 되어있으니까요.
        46.  
        47. // 그런데, push_back 대신에 insert를
        48. // 써서 문자열의 아무 위치에 문자 하나를
        49. // 넣으려고 할 때가 문제입니다.
        50.  
        51. // 여전히 재할당은 일어나지 않지만 string
        52. // 에 대한 반복자 무효화 규칙 때문에
        53. // 문자가 삽입된 위치부터 끝까지의 모든
        54. // 반복자/포인터/참조자는 무효화됩니다.

        
        
        예제 코드 접기
        
        
        

      • reserve를 써서 불필요한 메모리 재할당을 피하는 방법은 흔히 두 가지로 정리할 수 있습니다. 첫째는 컨테이너에 저장되는 요소의 개수를 정확하게 혹은 대강 파악하고 있을 때 가능한 방법으로, 앞의 예제 코드에서 본 것처럼 미리 필요한 양을 예약(reserve)해 놓는 것입니다. 둘째 방법은 필요한 최대량을 미리 예약해 놓은 후, 나중에 데이터를 모두 넣고 남은 용량을 잘라 내는 것입니다.

        남은 용량을 잘라 내는 방법에 대한 자세한 내용은 항목 17에서 찾을 수 있습니다.

  15. ★ 잊지 말자! string은 여러 가지 방식으로 구현되어 있다는 사실을... / 116

      • STL을 효과적으로 사용하기로 결정한 분이라면 현재 나와 있는 제품들이 string을 어떻게 구현해 놓았는지를 알 필요가 있습니다. 특히 여러 개의 STL 플랫폼에서 동작하는 코드를 작성하고 있으며 까다로운 수행 성능 조절이 필요한 경우라면 특히 그렇습니다.

      • string의 문자열 값은 참조 카운팅이 될 수도, 되지 않을 수도 있습니다. 기본적으로 많은 라이브러리에서 참조 카운팅을 사용하고 있습니다만, 이 기능의 동작을 막는 방법(대개 전처리자 매크로를 통해)도 제공하고 있습니다.

        참조 카운팅 기능을 막거나 사용해야 하는 경우에 대해서는 항목 13에서 이야기해 두었습니다. 예를 들어, 동일한 문자열이 아주 자주 복사되고 어떤 애플리케이션 자체에서 문자열 복사를 많이 하지 않을 때에만 참조 카운팅이 효과적입니다.

      • string 객체 자체의 크기(sizeof(string))는 포인터 크기의 한 배에서 일곱 배까지 다양합니다.

      • 문자열을 새로 생성할 때 필요한 메모리 할당의 회수는 0번, 1번, 또는 2번이 될 수도 있습니다.

      • 둘 이상의 string 객체가 문자열 크기나 용량 정보를 함께 가지고 있을 수도, 가지고 있지 않을 수도 있습니다.

      • 문자 버퍼를 위해 할당하는 메모리의 최소량에 대한 정책은 구현된 라이브러리마다 천차만별입니다.

  16. 기존의 C API에 vector와 string을 넘기는 방법을 알아두자 / 123

      • vector 객체 v가 있고, v 내의 데이터에 대한 포인터를 얻어내어 배열처럼 보이게 하고 싶으면 &v[0]을 씁니다. string 객체도 쉽습니다. string 객체 s가 있다고 할 때 s.c_str()을 사용하면 문자열 포인터가 손에 들어옵니다.

        한 가지 주의할 점은 빈 벡터일 경우에 예외처리가 필요하다는 것입니다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 다음과 같은 벡터가 있다고 합시다.
        3.  
        4. vector<int> v;
        5.  
        6. // 여기서 v[0]이라는 표현식은
        7. // 벡터 내의 첫째 요소에 대한
        8. // 참조자를 나타내므로 &v[0]은
        9. // 첫째 요소를 가리키는 포인터입니다.
        10.  
        11. // C++ 표준에 의하면 vector 내의
        12. // 데이터 요소들은 연속 메모리에
        13. // 저장되도록 정해져 있습니다.
        14.  
        15. // 따라서 v를 다음과 같은 형태의
        16. // C API에 넘기려면,
        17.  
        18. void doSomething(const int* pInts, size_t numInts);
        19.  
        20. // 이렇게 하면 됩니다.
        21.  
        22. doSomething(&v[0], v.size());
        23.  
        24. // 한 가지 주의해야 할 포인트는
        25. // v가 빈(empty) 벡터일 때입니다.
        26.  
        27. // v.size()가 0인 상황에서
        28. // &v[0]은 있지도 않은 메모리의
        29. // 주소값을 만들려고 용을 쓰게
        30. // 되고, 결국 알 수 없는 동작을
        31. // 일으키게 됩니다.
        32.  
        33. // 따라서 안전하게 코딩하려면
        34. // 이렇게 합니다.
        35.  
        36. if (!v.empty()) {
        37. doSomething(&v[0], v.size());
        38. }
        39.  
        40. // &v[0] 대신에 v.begin()을
        41. // 쓸 수 있다고 생각할 수 있지만,
        42. // v.begin()의 반환 타입은
        43. // 엄연히 반복자이지, 포인터가
        44. // 아닙니다.
        45.  
        46. // 즉, vector 내의 데이터를
        47. // 가리키는 포인터를 얻어낼 때
        48. // begin을 사용하면 안 됩니다.
        49.  
        50. // 굳이 써야 한다면 &*v.begin()
        51. // 처럼 쓰십시오.
        52.  
        53.  
        54. //-----------------------------------------------------------------------------
        55. // vector에서 쓰는 방법은 string에는
        56. // 통하지 않습니다.
        57.  
        58. // 왜냐하면 (1) string의 데이터
        59. // 자체가 연속 메모리에 저장되도록
        60. // 규정되어 있지 않습니다.
        61.  
        62. // 그리고 (2) string의 내부
        63. // 문자열 값이 널 문자로 끝나지
        64. // 않는 것도 있습니다.
        65.  
        66. // 이런 전차로 string 클래스에는
        67. // c_str이란 멤버 함수가 있는 것
        68. // 이지요.
        69.  
        70. // 문자열 s를 다음과 같은 함수에
        71. // 넘기려면
        72.  
        73. void doSomething(const char *pString);
        74.  
        75. // 이렇게 합니다.
        76.  
        77. doSomething(s.c_str());
        78.  
        79. // 이 코드는 문자열의 길이가 0이어도
        80. // 동작합니다. 이런 경우에는, c_str
        81. // 함수가 널 문자에 대한 포인터를
        82. // 반환합니다.

        
        
        예제 코드 접기
        
        
        

      • string의 경우, C API가 할 수 있는 유일한 일은 string의 데이터를 읽는 것 뿐입니다. 왜냐하면 c_str이 문자열 데이터의 내부에 대한 포인터를 반환한다는 보장이 없기 때문입니다. 그냥 C API와 호환되는, 수정할 수 없는 문자열 데이터의 사본의 포인터라는 점만 확실하지요.

      • 그러면 vector는 어떨까요? 약간의 융통성은 있습니다. 어떤 C API에 v를 넘겼는데 그 API는 v의 요소를 변경하는 코드가 있다고 하면, 대개 무난하게 넘어갑니다. 단, 호출된 루틴에서 해당 벡터의 요소 개수(크기)를 바꾸려고 하면 절대로 안 됩니다.

        만일 C API가 벡터 v의 요소 개수를 바꾸게 되면 v는 정확한 크기를 파악할 수 없어서, v의 내부 데이터는 일관성을 잃게 됩니다(v.size()에서잘못된 값이 나온다는 말입니다.).
        
        또한 크기와 용량이 같은 벡터(항목 14를 보세요)에 요소를 추가한다거나 하면 진정한 재앙이 여러분을 찾아옵니다.

      • 앞에서 "대개 무난하게 넘어갑니다"라고 말한 부분의 "대개"가 조금 이상하지 않으셨습니까? 물론 그러셨겠지요. 어떤 벡터의 경우 데이터에 대해 특수한 제약을 가지고 있는 경우가 있습니다. 벡터의 데이터를 변경하는 API에다가 이런 벡터를 넘기려면 그 벡터의 제약 사항도 만족시켜 주어야 합니다.

        예를 들어, 항목 23에서 말했듯이 연관 컨테이너 대신에 정렬된 벡터가 더 괜찮을 수 있지만, 벡터의 정렬 상태를 계속 유지해 주어야 한다는 것입니다.
        
        벡터의 데이터를 변경하는 API에 넘겨진 정렬된 벡터는, API가 복귀할 때 더 이상 정렬된 상태가 아닐 수도 있다는 사실, 중요합니다.

      • vector 객체를 C API를 통해 초기화하고 싶은 경우도 있습니다. vector와 배열은 내부 메모리 정렬 구조(layout)가 같다는 점을 이용하여, 벡터의 요소 메모리를 API에 그냥 넘기는 것이죠.

        예제 코드 보기
        
        
        

        1. // C API: 이 함수는 최대 arraySize 만큼의 double을 가진 배열에 대한 포인터를
        2. // 받아 그 배열에 데이터를 기록합니다. 동작이 끝나고 나면 데이터가 기록된 double의
        3. // 개수를 반환하는데, 이 값은 maxNumDoubles를 넘지 않습니다.
        4.  
        5. size_t fillArray(double *pArray, size_t arraySize);
        6. vector<double> vd(maxNumDoubles); // 크기가 maxNumDoubles인
        7. // 벡터를 생성합니다.
        8.  
        9. vd.resize(fillArray(&vd[0], vd.size())); // fillArray를 써서 vd에 데이터를
        10. // 기록하고, resize를 써서 vd의
        11. // 크기를 fillArray가 반환한 수치
        12. // 로 맞춥니다.
        13.  

        
        
        예제 코드 접기
        
        
        이 방법은 vector에만 통합니다. C/C++ 배열과 동일한 메모리 배열 구조를 가진 컨테이너는 vector가 유일하기 때문입니다.
        
        하지만 C API를 사용해서 string 객체를 초기화하고 싶다 해도 그리 어렵지 않습니다. API 쪽에서 vector<char>에 데이터를 쓰게 하고, 이 벡터에서 문자열 쪽으로 데이터를 복사하면 그냥 됩니다.
        
        예제 코드 보기
        
        
        

        1. // C API: 이 함수는 최대 arraySize 만큼의 char를 가진 배열에 대한 포인터를
        2. // 받아 그 배열에 데이터를 기록합니다. 동작이 끝나고 나면 데이터가 기록된 char의
        3. // 개수를 반환하는데, 이 값은 maxNumChars를 넘지 않습니다.
        4.  
        5. size_t fillString(char *pArray, size_t arraySize);
        6. vector<char> vc(maxNumChars); // maxNumChars 만큼의 크기를 가진
        7. // 벡터를 생성합니다.
        8.  
        9. size_t charsWritten = fillString(&vc[0], vc.size()); // fillString을 써서
        10. // vc에 데이터를 기록합니다.
        11.  
        12. string s(vc.begin(), vc.begin() + charsWritten); // vc에서 s로 데이터를 복사하는데,
        13. // 이때 범위 생성자(항목 5)를 사용
        14. // 합니다.
        15.  

        
        
        예제 코드 접기
        
        
        사실 C API를 사용하여 vector에 데이터를 쓰고 그 데이터를 여러분이 진짜로 사용할 다른 STL 컨테이너에 복사하는 아이디어는 항상 모든 경우에 다 통합니다.
        
        예제 코드 보기
        
        
        

        1. size_t fillArray(double *pArray, size_t arraySize); // 앞과 같습니다.
        2. vector<double> vd(maxNumDoubles); // 역시 앞과 같습니다.
        3. vd.resize(fillArray(&vd[0], vd.size()));
        4.  
        5. deque<double> d(vd.begin(), vd.end()); // 데이터를 데크에 복사합니다.
        6. list<double> l(vd.begin(), vd.end()); // 데이터를 리스트에 복사합니다.
        7. set<double> s(vd.begin(), vd.end()); // 데이터를 셋에 복사합니다.
        8.  

        
        
        예제 코드 접기
        
        
        여기서 힌트를 얻어, vector나 string이 아닌 다른 STL 컨테이너의 데이터를 C API에 넘기는 방법도 만들어 볼 수 있겠습니다. 해당 컨테이너의 데이터를 vector 객체에 복사하고 나서, 그 벡터를 API에 넘기면 되지요.
        
        예제 코드 보기
        
        
        

        1. void doSomething(const int* pInts, size_t numInts); // 앞에서 본 바로 그 C API
        2.  
        3. set<int> intSet; // API에 넘길 데이터를
        4. ... // 가진 셋
        5.  
        6. vector<int> v(intSet.begin(), intSet.end()); // 셋의 데이터를 벡터에
        7. // 복사한다.
        8.  
        9. if (!v.empty()) doSomething(&v[0], v.size()); // 이 데이터를 API에
        10. // 넘긴다.
        11.  
        12. // 물론 데이터를 배열에 복사한 다음에
        13. // 그 배열을 C API에 넘길 수 있습니다.
        14. // 하지만 왜 이렇게 하고 싶으신가요?
        15.  
        16. // 컴파일될 때 배열 크기가 어떻게 될지
        17. // 모르는 이상, 어쩔 수 없이 직접
        18. // 배열 버퍼를 동적으로 할당해야 하고,
        19. // 항목 13에서 이야기한 "vector나
        20. // string을 쓰지 않았을 때 여러분을
        21. // 귀찮게 하는 것들"이 저절로 따라오게
        22. // 되는 것입니다.

        
        
        예제 코드 접기
        
        
        

  17. 쓸데없이 남은 용량은 "바꿔치기(swap) 묘수"를 써서 없애 버리자 / 128

      • 요소가 100,000개인 벡터가 있다고 가정해 봅시다. 프로그램이 수행되면서 벡터에서 쓸모 없는 요소들을 계속해서 지우다 보니 이 벡터의 크기가 10으로 줄었습니다. 하지만 여전히 벡터의 용량은 그대로 최소 100,000개인 채로 남게 됩니다. 이럴 때 바꿔치기 묘수를 써서 낭비되는 메모리를 줄일 수 있습니다.

        다음의 코드를 사용하면 벡터 v에서 필요 없는 용량을 잘라낼 수 있습니다.
        
        vector<int> v;
        ...
        vector<int>(v).swap(v);
        
        우선 vector<int>(v)까지 보죠. 이 표현식은 v의 사본인 임시 벡터 객체를 만듭니다.
        
        이 과정에서 복사 생성자가 불리는데, 이 복사 생성자는 요소가 복사되는데 필요한 만큼의 메모리만을 할당하기 때문에, 이렇게 만들어지는 객체는 v와 달리 딱 맞는 용량이 잡혀 있습니다.
        
        그 다음 swap 문이 이어지고 있는데요, 이 함수에 의해서 임시 벡터 안의 데이터와 v 안의 데이터가 완전히 싹 바뀝니다.
        
        여기까지 오면 v는 필요 없는 용량이 제거된 상태가 되고, 임시 객체는 v가 사용하고 있던 불필요한 메모리를 가지고 있게 됩니다.
        
        이제 앞의 코드가 끝나면 임시 객체가 소멸되면서 그 객체가 떠맡고 있던 메모리도 동시에 해제됩니다.

      • 이 "바꿔치기 묘수"는 string에도 쓸 수 있습니다.

        string s;
        // 일단 문자열을 크게
        // 키운 후에, 문자를
        // 거의 없애 봅시다.
        ...
        
        string(s).swap(s);
        // s를 "수축시켜 맞춥니다."
        

      • 사실 이 묘수를 썼을 때 완벽하게 불필요한 메모리가 없어진다는 보장은 없습니다. 왜냐하면 vector나 string을 구현한 개발자가 마음먹기에 따라 용량 설정이 다르기 때문이지요.

        예를 들면, 몇 바이트 이하로는 절대로 줄어들지 않게 하는 하한선을 만들어 두거나 vector나 string의 용량을 2의 제곱수로 제한해 놓기도 합니다(이러한 경우는 vector보다는 string에서 더 자주 보입니다).
        
        따라서, "수축시켜 맞추기(shrink to fit)" 방법은 엄밀히 말해 "용량을 최대한 작게 만드는 것"이 아니라, "컨테이너의 현재 크기(size)에 대해 구현 코드에 따라 다르게 만들어지는 용량만큼 작게 만드는 것"이라고 알아두셔야 정확합니다.
        
        하지만 vector와 string의 불필요한 메모리를 줄이는 방법으로는 이 방법이 가장 괜찮은 방법입니다.

      • 좀 더 응용해서 컨테이너를 완전히 비우고 용량을 라이브러리 구현 코드가 허용하는 최소치로 줄이는 데에도 쓸 수 있습니다. 복사 생성자 대신 기본 생성자를 호출하는 방법으로 말이죠.

        vector<int> v;
        string s;
        // v와 s를 잘
        // 사용합니다.
        ...
        
        // v를 완전히 비우고
        // 용량을 최소화합니다.
        vector<int>().swap(v);
        
        // s를 완전히 비우고
        // 용량을 최소화합니다.
        string().swap(s);

      • 마지막으로 이야기할 중요한 사실이 있습니다. 두 컨테이너를 [바꿔치면], 내부의 요소 데이터뿐만 아니라 반복자, 포인터, 참조자도 모두 [바뀝니다]. 이때, swap이 일어난 후에도 원래의 컨테이너의 요소를 가리키는데 사용되던 모든 반복자나 포인터, 참조자는 - 다른 컨테이너로 옮겨간 후에도 - 그대로 유지된다는 것입니다.

  18. vector<bool> 보기를 돌같이 하자 / 131

      • 언뜻 멀쩡해 보이는 vector<bool>은 사실 STL 컨테이너로서 두 가지가 잘못되어 있습니다. 첫째는 STL 컨테이너가 아니라는 점이고, 둘째는 bool을 담고 있지도 않다는 점입니다. 여기에 반기를 들 만한 것이 별로 없습니다.

      • 어떤 객체가 STL 컨테이너의 자격을 갖추려면 C++ 표준안 23.1절에 수록된 요구사항을 만족해야만 합니다. 이 요구사항 중 하나가 "c가 타입 T의 객체를 담는 컨테이너라면 c에서 operator[]가 지원되어야 한다"라는 것입니다.

        즉 다음의 코드가 컴파일 되어야 한다는 말이죠.
        
        T *p = &c[0];
        // operator[]가 반환해
        // 주는 주소값으로 T*를
        // 초기화합니다.
        
        다시 말해서, operator[]를 써서 Container<T>에서 T 객체 하나를 얻어낸다면 이 객체의 주소값을 가지고 객체의 포인터를 얻어낼 수 있다는 것입니다.
        
        그런데 vector<bool>가 컨테이너라면, 다음의 코드가 컴파일 되어야 합니다.
        
        vector<bool> v;
        bool *pb = &v[0];
        // vector<bool>::operator[]가
        // 반환해 주는 주소값으로
        // bool*를 초기화합니다.
        
        하지만 절대로 안 됩니다. vector<bool>은 실제로 bool이 들어 있지 않은 가짜 컨테이너입니다. 공간을 줄이기 위해 bool을 압축시킨 데이터 표현 방식을 쓰기 때문에 컴파일에 실패합니다.

      • 대개 "vector"에 저장되는 "bool"을 하나의 비트로 나타내어 한 바이트로 여덟 개의 bool을 담을 수 있게 구현하더군요. 즉, vector<bool>은 비트 필드(bitfield)를 써서 bool을 저장하고 있는 것처럼 흉내내는 것일 뿐입니다.

        물론 비트 필드도 bool처럼 두 개의 값만 가질 수 있지요. 그러나, 진짜 bool에는 이것에 대한 포인터를 만들 수 있지만, 비트 필드의 각 비트에 대한 포인터를 만들 수는 없지 않습니까?
        
        또한 비트 필드의 각 비트에 대한 참조자도 만들 수 없습니다.
        
        이런 상황에서 operator[]를 구현하기 위해, operator[]에서 비트에 대한 참조자처럼 동작하는 객체를 반환하는 방법을 생각해 볼 수 있습니다. 프록시 객체(proxy object)라고 불리는 패턴을 쓰는 거죠(프록시 객체는 알아두면 굉장히 편리한 C++ 테크닉입니다. More Effective C++의 항목 30을 참고하세요).
        
        예제 코드 보기
        
        
        

        1. // 군더더기를 모두 발라내고 필요한
        2. // 것만 써 보았을 때 vector<bool>의
        3. // 모습은 다음과 같습니다.
        4.  
        5. template <typename Allocator>
        6. vector<bool, Allocator> {
        7. public:
        8. class reference {...}; // 각 비트에 대한 참조자 대신 쓰일
        9. // 프록시를 만드는 클래스
        10.  
        11. reference operator[](size_type n); // operator[]는 프록시를 반환합니다.
        12. ...
        13. };
        14.  
        15. // 자 이제 앞의 예제 코드가 컴파일
        16. // 되지 않는 이유가 더 확실해질
        17. // 것입니다.
        18.  
        19. vector<bool> v;
        20. bool *pb = &v[0]; // 에러입니다! 우변에 있는 표현식은
        21. // vector<bool>::reference* 타입이지,
        22. // bool*이 아니잖습니까?
        23.  
        24. // vector<bool>은 아무리 애를 써도
        25. // 위의 코드를 컴파일할 수 없기
        26. // 때문에 STL 컨테이너의 요구사항을
        27. // 만족시키지 못합니다.

        
        
        예제 코드 접기
        
        
        장담하건데, 잡아낸 컨테이너 요소의 주소가 내부 객체 타입의 포인터이어야 제대로 동작하는 템플릿을 만들 때가 여러분에게 옵니다. "컨테이너인 것"과 "거의 컨테이너인 것(여기서는 vector<bool>)"의 엄청난 차이를 순식간에 이해할 때는 아마도 그 때일 테지요.

      • 그럼 정말로 vector<bool>같은 객체가 필요할 때 어떻게 해야 할까요? 거의 모든 상황에서 통하는 방법은 두 가지 입니다. 첫째는 deque<bool>인데요, deque는 vector가 할 수 있는 거의 모든 것을 할 수 있고(못 하는 것을 꼽자면 reserve와 capacity가 먼저 떠오르는군요) 진짜 bool을 저장할 수 있는 STL 컨테이너입니다.

        물론 deque가 사용하는 내부 메모리는 연속 메모리가 아니기 때문에 bool 배열을 받아들이는 C API(아마도 C99 API일 것입니다. bool이 추가된 것은 C99부터니까요) 등에 넘기고자 할 때에는 손가락만 빨 수밖에 없습니다.
        
        하지만 이것은 vector<bool>로도 불가능합니다. bool 데이터를 뽑아내는 일 조차 안되니까요(덧붙이자면, 항목 16에서 이야기한 방법은 vector<bool>에 쓸 수 없습니다. 항목 16의 방법은 vector에 저장된 요소의 포인터를 제대로 얻어낼 수 있는 조건을 가정하고 설명한 것입니다).

      • 둘째는 bitset(비트셋)입니다. bitset은 STL 컨테이너는 아니지만, 표준 C++ 라이브러리에 속해 있습니다. STL 컨테이너와 달리, 비트셋의 크기(요소의 개수)는 컴파일 타임에 고정되기 때문에 요소를 새로 삽입한다든지 제거하는 작업은 할 수 없습니다. 더욱이 STL 컨테이너가 아니기 때문에 반복자도 지원하지 않습니다.

        비트셋이라는 이름이 모든 것을 말해 주듯, 비트 하나 하나를 모아 보여주는 클래스답게 비트 조작에 관련된 편리한 멤버 함수를 지원하며, vector<bool>에만 있는 flip 함수도 제공합니다.
        
        굳이 반복자를 사용한다든지 요소 개수를 변경하는 일에 신경 쓰지 않는다면 bitset이 아주 괜찮은 일을 해줄 것으로 보입니다.

      • C++ 표준화 위원회에서 STL에서 내부 요소를 프록시를 통해 액세스할 수 있는 방법을 보여주는 본보기로서 이 vector<bool>을 만들기로 결정했다고 합니다.

        한데, 애석하게도 최종적으로 내린 결론은 프록시 기반의 컨테이너로는 STL 컨테이너의 요구사항을 모두 만족시킬 수 없다는 이야기였다나요.

• Chapter 3   STL 연관 컨테이너(Associative Containers)

  19. 상등 관계(equality)와 동등 관계(equivalence)의 차이를 파악하자 / 136

      • 두 객체가 "같으냐?"를 알아볼 때 상등 관계는 operator==를 사용하지만 동등 관계는 operator<를 사용합니다.

        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 상등성의 개념은 operator==에
        3. // 뿌리를 두고 있습니다.
        4.  
        5. class Widget { ... };
        6. Widget x, y;
        7. ...
        8. if (x == y) {
        9. x와 y는 같(상등)습니다;
        10. }
        11. else {
        12. x와 y는 다릅니다;
        13. }
        14.  
        15. // 이때 Widget의 모든 데이터 멤버가
        16. // 같다는 의미는 아닙니다.
        17.  
        18. // operator==가 일부 데이터 멤버를
        19. // 무시하도록 구현되었을 수도 있기
        20. // 때문입니다.
        21.  
        22.  
        23. //-----------------------------------------------------------------------------
        24. // 반면, STL에서 동등성은 정렬된
        25. // 범위 안에 있는 객체 값들의
        26. // 상대적인 순서에 준하고 있습니다.
        27.  
        28. // 컨테이너 c에 저장되어 있는
        29. // 어떤 객체 x, y가 있다고
        30. // 할 때, x와 y 모두가 c의
        31. // 정렬 순서에 대해 서로의 앞에
        32. // 오지 않으면 x와 y는 동등하다고
        33. // 합니다.
        34.  
        35. if (!(x < y) && !(y < x)) {
        36. x와 y는 같(동등)습니다;
        37. }
        38. else {
        39. x와 y는 다릅니다;
        40. }
        41.  
        42. // 일반적으로 연관 컨테이너에 사용되는
        43. // 비교 함수는 operator<가 아니라
        44. // less입니다.
        45.  
        46. // less는 사용자 정의가 가능한
        47. // 술어 구조입니다.
        48.  
        49. // STL의 모든 표준 연관 컨테이너는
        50. // 멤버 함수를 통해 자신(인스턴스)의
        51. // 정렬용 술어 구조를 내어주므로,
        52. // 앞의 표현식은 다음과 같이
        53. // 작성되는 것이 좀 더 정확한
        54. // 표기가 됩니다.
        55.  
        56. // 여기에서 c는 연관 컨테이너
        57. // 객체의 이름입니다.
        58.  
        59. if (!c.key_comp()(x, y) && !c.key_comp()(y, x)) {
        60. x와 y는 같(동등)습니다;
        61. }
        62. else {
        63. x와 y는 다릅니다;
        64. }

        
        
        예제 코드 접기
        
        
        

      • 모든 연관 컨테이너(set, multiset, map, multimap)는 내부 데이터 요소를 관리할 때 동등 비교를 사용합니다.

        예제 코드 보기
        
        
        

        1. // 예를 들어 대소문자를 구분하지 않는
        2. // set<string>를 만들려 한다고 합시다.
        3.  
        4. // 즉, 이 셋의 비교용 함수 객체는
        5. // 문자열을 비교할 때 대소문자를
        6. // 구분하지 않아야 합니다.
        7.  
        8. // 이제 operator()에 의해
        9. // ciStringCompare(대소문자를
        10. // 구분하지 않고 문자열을 비교하는
        11. // 함수)를 호출하는 함수자 클래스를
        12. // 하나 만들면 되겠지요.
        13.  
        14. struct CIStringCompare: // 대소문자를 구분하지 않는(case-
        15. public // insensitive) 문자열 비교용 함수자.
        16. binary_function<string, string, bool> { // 이 클래스의 기본 클래스에 대해
        17. // 서는 항목 40을 참고하세요.
        18. bool operator()(const string& lhs,
        19. const string& rhs) const
        20. {
        21. return ciStringCompare(lhs, rhs); // ciStringCompare가 어떻게 구현
        22. } // 되어 있는지에 대해서는 항목 35
        23. }; // 를 보면 됩니다.
        24.  
        25. // 이제 대소문자를 구분하지 않는
        26. // 셋 컨테이너인 set<string>을
        27. // 쉽게 만들 수 있습니다.
        28.  
        29. set<string, CIStringCompare> ciss; // ciss = "case-insensitive
        30. // string set"
        31.  
        32. // 이 셋에다가 "Persephone"과
        33. // "persephone"를 넣어 보면,
        34. // 첫째 문자열만 셋에 추가되고
        35. // 둘째 것은 들어가지 않습니다.
        36.  
        37. // 왜냐하면 이 둘은 동등하기
        38. // 때문입니다.
        39.  
        40. ciss.insert("Persephone"); // 새 요소입니다. 셋에 추가됩니다.
        41. ciss.insert("persephone"); // 동등한 것이 있으므로 추가되지 않습니다.
        42.  
        43. // 이제 set의 find 멤버 함수를
        44. // 써서 "persephone"를 찾으면
        45. // 당연히 탐색은 성공할 것입니다.
        46.  
        47. if (ciss.find("persephone") != ciss.end()) ... // 이 if문의 조건절은 참이 됩니다.
        48.  
        49. // 하지만 애석하게도 멤버 함수가
        50. // 아닌 find 알고리즘을 사용하면
        51. // 탐색이 실패합니다.
        52.  
        53. if (find(ciss.begin(), ciss.end(),
        54. "persephone") != ciss.end()) ... // 이 if문의 조건절은 거짓입니다.
        55.  
        56. // 왜냐하면 find 알고리즘은
        57. // 상등 비교를 해서 요소를
        58. // 찾기 때문입니다.

        
        
        예제 코드 접기
        
        
        

      • 왜 STL 연관 컨테이너들은 동등 비교를 사용하는 걸까요?

        상등 비교를 하는 연관 컨테이너 set2CF가 있다고 가정해 봅시다. "set width 2 Comparison Functions"라는 뜻입니다.
        
        첫째 비교 함수는 이 컨테이너의 정렬 순서를 결정하는 데 사용하고, 둘째 것은 두 객체가 같은 값을 가지고 있는지를 알아보는데 사용하고요.
        
        이 컨테이너 템플릿의 인스턴스를 이렇게 만듭니다.
        
        set2CF<string,
        CIStringCompare,
        equal_to<string> > s;
        
        여기서 s는 문자열을 정렬할 때에는 대소문자를 구분하지 않습니다. 반면, 같은 문자열인지 알아 볼 때에는 대소문자를 구분합니다(대다수의 분들께 직관적이죠).
        
        자, 이제 다시 저희집 귀염둥이의 이름을 s에 넣어 보도록 합시다(persephone은 저자가 기르는 개 이름이라고 한다).
        
        s.insert("Persephone");
        s.insert("persephone");
        
        어떻게 해야 좋을까요? 우리는 "persephone" != "Persephone"이라는 사실을 알고 있고, 두 문자열을 s에 우겨 넣으려고 했습니다. 어떤 순서를 이룰까요? 정렬에 쓰이는 비교 함수는 이 둘을 따로 간주하지 않는다는 점을 잊으면 안됩니다.
        
        이 두 문자열을 그냥 정해진 순서에 관계없이 접어넣고 나중에 어떤 순서가 되든 상관하지 않으시렵니까?
        
        연관 컨테이너의 데이터 요소를 단 하나의 일정한 순서로 탐색할 수 없게 된다는 점은 multiset과 multimap에도 이미 골치 아픈 문제가 됩니다. 표준안에서는 동등 관계에 있는 값(multiset의 경우)과 키(multimap의 경우)의 상대적인 순서에 대해 구체적인 제한을 두지 않았기 때문입니다.
        
        아니면, s의 내용물은 반드시 일정한 순서를 유지하도록 하기 위해 두 번째로 넣으려고 하는 문자열("persephone")을 무시하렵니까?
        
        다음과 같이 하면 어떤 일이 일어날까요?(find는 "같은" 값을 찾는 것이라고 생각하고 보십시오)
        
        if (s.find("persephone") != s.end()) ...
        
        추측하건데 find는 상등성 검사를 할 것입니다. 하지만 s에 저장된 요소들의 일정한 순서를 보존할 목적으로 두 번째의 insert문을 무시했다면(즉, 삽입이 되지 않았다면) 탐색은 실패합니다. "persephone"은 중복된 값으로 판단되어서 s에 들어가지 않았다고 하는데도요. 웃기지 않습니까?
        
        비교 함수를 하나만 사용하고 두 값이 같은지를 검사하는 데에 동등성(equivalence)란 개념을 사용하게 되면, 앞서 본 문제를 살짝 비켜갈 수 있습니다.
        
        결국 연관 컨테이너에서 동등성이란 개념을 사용하는 것은, 상등성과 동등성을 구분하지 않고 마구잡이로 썼을 때 생기는 헷갈림을 막아주는 방패막인 셈입니다.

      • 하지만, 표준 연관 컨테이너가 "정렬된" 요소를 가지고 있다는 개념만 버린다면 상황은 또 달라집니다. 요소를 정렬하여 관리하지 않는 연관 컨테이너도 있기 때문이죠. 그 중에서 해쉬 테이블을 이용하여 설계한 비표준 컨테이너 두 개는 이미 폭넓게 사용되고 있습니다. 하나는 상등성에 기반을 두고 있고, 또 하나는 동등성에 기반을 두고 있는데요, 이에 대한 자세한 내용은 항목 25에서 찾을 수 있을 것입니다.

  20. 포인터를 저장하는 연관 컨테이너에 대해서는 적합한 비교(비교 함수자) 타입을 정해주자 / 142

      • 포인터를 저장하는 연관 컨테이너에 별도의 적합한 비교 함수자를 정해주지 않으면 포인터의 값(주소값)을 기준으로 요소들이 정렬됩니다. 즉, 실제 요소의 데이터와는 상관없이 요소의 주소값을 기준으로 정렬되게 되죠.

        예제 코드 보기
        
        
        

        1. // string* 포인터로 이루어진 set을
        2. // 하나 만들고, 여기에 동물 이름을
        3. // 몇 개 넣기로 합시다.
        4.  
        5. set<string*> ssp; // ssp = "set of string ptrs"
        6. ssp.insert(new string("Anteater"));
        7. ssp.insert(new string("Wombat"));
        8. ssp.insert(new string("Lemur"));
        9. ssp.insert(new string("Penguin"));
        10.  
        11. // 이제 이 set에 들어 있는 내용을
        12. // 출력할 생각으로 다음의 코드를 써
        13. // 보았습니다.
        14.  
        15. // 어쨌든 set은 데이터를 정렬하여
        16. // 관리한다고 알고 있으니, 알파벳
        17. // 순서대로 출력될 것으로 기대합니다.
        18.  
        19. for (set<string*>::const_iterator i = ssp.begin();
        20. i != ssp.end();
        21. ++i)
        22. cout << **i << endl; // *i는 string* 이므로 **i를 썼습니다.
        23.  
        24. // 출력 결과 동물 이름은 출력되었지만
        25. // 알파벳 순서대로 나올 확률은 고작
        26. // 24분의 1입니다.
        27.  
        28. // ssp에 들어 있는 요소는 분명히
        29. // 정렬되어 있습니다만, ssp에는
        30. // 포인터가 들어 있기 때문에 문자열
        31. // 값이 아닌 포인터 값에 의해 정렬된
        32. // 것입니다.

        
        
        예제 코드 접기
        
        
        

      • 이러한 이유로 포인터를 저장하는 연관 컨테이너에 대해서는 적합한 비교(비교 함수자) 타입을 정해 줘야 합니다.

        예제 코드 보기
        
        
        

        1. // 차근차근 짚어 봅시다.
        2.  
        3. set<string*> ssp;
        4.  
        5. // 는 아래 선언문에서 둘째 매개 변수를
        6. // 생략하고 쓴 것입니다.
        7.  
        8. set<string*, less<string*> > ssp;
        9.  
        10. // 사실 할당자가 더 생략되어 있지만,
        11. // 할당자는 이번 항목의 관심사가
        12. // 아니므로 무시해도 상관없습니다.
        13.  
        14. // 문자열 값들이 알파벳 순서로
        15. // 늘어서도록 string* 포인터를
        16. // 정렬하기 위해서는 기본적으로
        17. // 주어지는 less<string*>이라는
        18. // 비교 함수자 클래스를 쓸 수
        19. // 없습니다.
        20.  
        21. // 즉 용도에 맞게 직접 만들어야
        22. // 합니다. 이 경우 다음과 같이
        23. // 만들 수 있을 것입니다.
        24.  
        25. struct StringPtrLess:
        26. public binary_function<const string*, // 기본 클래스를 쓴 것에
        27. const string*, // 대해서는 항목 40을 참고
        28. bool> { // 하세요.
        29. bool operator()(const string *ps1, const string *ps2) const
        30. {
        31. return *ps1 < *ps2;
        32. }
        33. };
        34.  
        35. // 이제 이 타입을 ssp의 비교
        36. // 함수자 타입으로 넣어줍니다.
        37.  
        38. typedef set<string*, StringPtrLess> StringPtrSet;
        39. StringPtrSet ssp; // 문자열 포인터의 셋을 만드는데, 이때
        40. // StringPtrLess를 써서 정렬합니다.
        41.  
        42. ... // 문자열 포인터의 삽입은 이전과
        43. // 똑같이 합니다.
        44.  
        45. // 이제 루프 코드는 원하는 대로
        46. // 동작할 것입니다.
        47.  
        48. for (StringPtrSet::const_iterator i = ssp.begin();
        49. i != ssp.end();
        50. ++i)
        51. cout << **i << endl; // 알파벳 순으로 나옵니다.
        52.  

        
        
        예제 코드 접기
        
        
        

      • 코드 작성시 이런 경우가 잦을 때에는 비교 함수자의 템플릿을 하나 준비해 두는 것이 좋습니다.

        예제 코드 보기
        
        
        

        1. struct DereferenceLess {
        2. template <typename PtrType>
        3. bool operator()(PtrType pT1, // 매개 변수는 값으로 전달됩니다.
        4. PtrType pT2) const // 들어온 값 자체를 포인터(혹은 그
        5. { // 처럼 동작하는 것)로 간주하니까요
        6. return *pT1 < *pT2;
        7. }
        8. };
        9.  
        10. // 이렇게 준비해 두면 StringPtrLess 같은
        11. // 클래스를 만들 필요가 없습니다.
        12.  
        13. set<string*, DereferenceLess> ssp; // set<string*, StringPtrLess>와
        14. // 똑같이 동작하는 set 객체
        15.  

        
        
        예제 코드 접기
        
        
        

      • 이번 항목은 포인터를 담는 연관 컨테이너에 관한 이야기이지만, 연관 컨테이너에 담는 객체가 포인터처럼 동작하는 객체인 경우에도 마찬가지입니다. 이를테면 스마트 포인터나 반복자를 가리키는 것이죠. 즉, 스마트 포인터나 반복자를 담는 연관 컨테이너는 그것에 대한 비교 타입을 지정해 주세요.

        운 좋게 이번 항목에서 이야기한 해결책은 모두 그대로 적용할 수 있습니다. DereferenceLess(이번 항목의 마지막 예제 코드에서 나옵니다)도 그렇지요.
        
        T*의 연관 컨테이너에 대한 비교 타입으로 만들어 본 이 템플릿은 T 객체에 대한 반복자나 스마트 포인터를 담는 연관 컨테이너의 비교 타입으로도 적합합니다.

  21. 연관 컨테이너용 비교 함수는 같은 값에 대해 false를 반환해야 한다 / 148

      • set이나 map과 같은 연관 컨테이너의 비교 함수가 true를 반환하는 경우에는 동등한 값일지라도 중복되어 삽입되는 일이 생길 수 있습니다. 이로 인해 문제가 발생하는 것은 불을 보듯 뻔하죠.

        예를 들어 봅시다. 비교 타입이 less_equal인 set을 하나 만들고 여기에 10을 삽입하겠습니다.
        
        set<int, less_equal<int> > s;
        s.insert(10);
        
        그 다음 10을 한 번 더 넣어 봅시다.
        
        s.insert(10);
        
        두 번째로 호출된 insert는 s에 10이 이미 들어 있는지를 파악해야 합니다. 편의상 이미 들어 있는 10을 10A라고 하고, 넣으려는 10은 10B라고 부르기로 하지요.
        
        셋 객체는 내부 데이터 구조를 뒤지면서 10B를 삽입할 위치를 찾습니다. 실제로 하는 일은 10B가 10A와 동등한지를 체크해 가는 것입니다(항목 19 참조).
        
        이 예제 코드에서는 less_equal을 비교 함수로 지정했으므로 operator<=가 비교 함수로 쓰입니다. 따라서 셋 객체는 다음의 표현식이 참인지를 검사합니다.
        
        !(10A <= 10B) && !(10B <= 10A)
        // 10A와 10B가 동등한지 봅니다.
        
        물론 표기만 다를 뿐 10A와 10B의 값은 모두 10이므로 10A <= 10B는 명백히 참입니다. 그 반대도 참이고요. 즉, 앞의 표현식은 다음과 같이 간단히 할 수 있습니다.
        
        !(true) && !(true)
        
        false && false
        
        결과는 false이지요. 즉 이 셋 객체는 10A와 10B를 동등하지 "않다"는 결론을 내립니다. 쉽게 말해 같지 않은 것이고요. 그 결과 10이 두 번 삽입되어 버리는 문제가 발생합니다.

      • 이제 연관 컨테이너에 사용하는 비교 함수는 같은 값에 대해 꼭 false를 반환하게 해야겠다는 생각은 하셨을 것입니다. 하지만 주의해야 할 점은 있습니다. 이 주의사항을 자주 만나게 된다는 사실이 놀랍기도 합니다.

        예를 하나 들겠습니다. 항목 20에서는 string* 포인터를 연관 컨테이너에 저장해서 쓸 때 내부 포인터를 포인터 값이 아닌, 포인터가 가리키는 문자열에 따라 정렬할 수 있는 비교 함수를 만드는 방법을 보여 주고 있습니다.
        
        이 비교 함수는 포인터가 가리키는 문자열을 오름차순으로 정렬했는데요, 이것을 내림차순으로 정렬한다고 가정해 보죠. 가장 쉬운 방법은 미리 만든 코드를 따다가 고치는 것입니다.
        
        아래 예제 코드는 항목 20에 있는 코드를 고친 결과입니다.
        
        예제 코드 보기
        
        
        

        1. struct StringPtrGreater:
        2. public binary_function<const string*
        3. const string*,
        4. bool> {
        5. bool operator()(const string *ps1, const string *ps2) const
        6. {
        7. return !(*ps1 < *ps2); // 원래 문장에 !를 붙였습니다.
        8. } // 맞지 않아서 문제죠.
        9. };

        
        
        예제 코드 접기
        
        
        아이디어의 핵심은 비교 함수에 들어 있는 검사 문장에 부정(negating) 연산을 취해서 정렬 순서를 뒤집어 보자는 것인데요, 애석하게도 "<"의 반대는 ">"(여러분이 원했던)이 아니라, ">="입니다. 물로 ">="은 같은 값에 대해 true를 반환하는, 종전과 같은 나쁜 결과를 만든단 말입니다.
        
        여러분이 진짜로 원했던 비교 함수자의 타입은 이것입니다.
        
        예제 코드 보기
        
        
        

        1. struct StringPtrGreater: // 이제야 제대로 된 연관
        2. public binary_function<const string* // 컨테이너용 비교 타입
        3. const string*, // 입니다.
        4. bool> {
        5. bool operator()(const string *ps1, const string *ps2) const
        6. {
        7. return *ps2 < *ps1; // *ps2가 *ps1의 앞에
        8. } // 오는지 점검합니다(즉,
        9. }; // 피연산자의 위치를 뒤
        10. // 바꾸었습니다).
        11.  

        
        
        예제 코드 접기
        
        
        

      • 혹시나 multiset이나 multimap을 위한 비교 함수자에서는 같은 값에 대해 true를 반환해도 된다고 생각하지는 않으셨나요? 만일 그렇게 생각하셨다면 아쉽게도 틀렸습니다. multiset이나 multimap에도 다른 연관 컨테이너처럼 같은 값에 대해 false를 반환하는 비교 함수자를 사용해야 합니다.

        앞서 봤던 예제를 multiset으로 바꿔서 설명하겠습니다.
        
        multiset<int, less_equal<int> > s;
        s.insert(10);
        s.insert(10);
        
        s가 10의 사본을 두 개 가지고 있는 것은 맞습니다. 이제 여기에 equal_range 알고리즘을 쓰면 두 개의 사본에 대한 범위를 지정해 주는 반복자 쌍을 얻을 수 있을 것 같습니다.
        
        그런데 정말 그럴까요? 슬프지만 절.대.로. 안됩니다. equal_range는 같은(equal) 값의 범위를 식별하지 않습니다. 동등한(equivalent) 값의 범위를 식별하지요.
        
        따라서, s의 비교 함수에 의해 10A와 10B는 동등하지 않기 때문에, 이 둘이 equal_range에 의해 나오는 범위 안에 들어갈 일은 전혀 없습니다.

  22. set와 multiset에 저장된 데이터 요소에 대해 키(key)를 바꾸는 일은 피하자 / 152

      • 모든 표준 연관 컨테이너가 그렇듯 set과 multiset은 내부에 저장되는 데이터 요소를 정렬해서 관리하며, 컨테이너의 정상적인 동작은 요소들이 정렬된 상태에서만 가능합니다. 어떤 연관 컨테이너에 들어 있는 어떤 요소의 값을 바꾼다고 합시다. 바뀐 값이 제대로 된 위치에 들어가 있을 리가 만무하므로, 컨테이너의 정렬 상태는 무너지게 됩니다.

      • 이 법칙은 map과 multimap에서 특히 간단히 통합니다. 왜냐하면, 이 컨테이너들의 키 값을 바꾸는 일은 그 자체가 불가능하기 때문입니다.

        이유는, map<K, V> 혹은 multimap<K, V> 타입의 객체에 저장되는 요소는 pair<const K, V>이기 때문입니다.
        
        const_cast를 써서 const 부분을 날려 버리면 가능하기도 합니다. 하지만, 이론적으로 이런 값은 읽기 전용의 메모리 위치에 기록하도록 STL이 구현될 수 있어서(일단 한번 기록된 후에는 시스템 콜에 의해 기록 방지 메커니즘이 걸리는 가상 메모리 페이지가 그 예입니다), 상수 성질을 캐스팅으로 제거했을 때 무반응인 것이 그나마 다행이라고 합니다.
        
        현재까지 그렇게 구현된 예를 찾지 못했지만, 표준안에 민감한 프로그래머라면 map/multimap 키의 상수 성질은 함부로 캐스팅을 통해 없애지 않는 것이 좋습니다.

      • 일단 set이나 multiset 내의 데이터 요소의 타입이 const가 아닌 이유부터 이해하자고요.

        회사 직원 데이터를 관리하는 클래스가 하나 있다고 가정합시다. 직원 관리에 필요한 데이터는 각양 각색입니다.
        
        여기서 그럴듯한 가정을 하나 하는 것입니다. 무엇인고 하니, 직원들은 모두 유일한 식별(ID) 번호를 가지고 있도록 하며, 이 번호는 idNumber 멤버 변수로 알아낸다고 정하는 거죠. 직원 데이터의 set을 만들 때에는 이 식별 번호만으로 직원 데이터를 정렬하면 됩니다.
        
        프로그래밍적인 시각에서 볼 때, 직원의 식별 번호는 set에 저장되는 요소의 키(key) 역할을 합니다. 이외의 데이터들(이름이나 직위 등)은 그냥 들러리에 불과하죠. 이러한 경우라면 특정한 직원의 데이터를 꺼내어 직위(title)를 바꾸는 것은 전혀 불가능할 이유가 없습니다.
        
        즉 정렬에 관련된 데이터 멤버가 아니라면, 값을 바꿔도 set 객체를 훼손시키지 않습니다. 이러한 이유로 인해 set/multiset의 요소를 const 타입으로 둘 수가 없습니다.
        
        예제 코드 보기
        
        
        

        1. class Employee {
        2. public:
        3. ...
        4. const string& name(void) const; // 직원 이름을 얻어냅니다.
        5. void setName(const string& name); // 직원 이름을 넣습니다.
        6. const string& title(void) const; // 직원 직위를 얻어냅니다.
        7. void setTitle(const string& title); // 직원 직위를 넣습니다.
        8. int idNumber(void) const; // 직원의 식별 번호를 얻어냅니다.
        9. };
        10.  
        11. struct IDNumberLess:
        12. public binary_function<Employee, Employee, bool> { // 항목 40을 참고하세요.
        13. bool operator()(const Employee& lhs,
        14. const Employee& rhs,) const
        15. {
        16. return lhs.idNumber() < rhs.idNumber();
        17. }
        18. };
        19.  
        20. typedef set<Employee, IDNumberLess> EmpIDSet;
        21. EmpIDSet se; // se는 식별 번호로 정렬되는
        22. // 직원 데이터의 셋입니다.
        23.  
        24. Employee selectedID; // 원하는 식별 번호가 들어 있는
        25. ... // 직원 데이터를 담은 변수
        26. EmpIDSet::iterator i = se.find(selectedID);
        27. if (i != se.end()) {
        28. i->setTitle("Corporate Deity"); // 다른 직위를 줍니다.
        29. }
        30.  
        31. // 이와 같은 코드가 불가능할 이유가
        32. // 전혀 없으며, 이런 코드를 가능하게
        33. // 하기 위해 set/multiset의 요소를
        34. // const 타입으로 둘 수가 없습니다.
        35.  

        
        
        예제 코드 접기
        
        
        map과 multimap의 키에는 왜 동일한 법칙이 적용될 수 없을까? 라고 생각하신 분이 있을 것도 같습니다.
        
        사실 그렇지 말란 법은 없으나, 중요한 것은 표준화 위원회의 생각이죠. 그리고 표준화 위원회의 생각은 map/multimap의 키는 const이어야 하고 set/multiset의 값은 const이면 안 된다는 것입니다.

      • set이나 multiset에 들어가는 값은 const 타입이 아니기 때문에, 이 값을 바꾸어도 컴파일러에 걸리지 않습니다. 따라서 이번 항목을 통해 알리고자 하는 바는 이것입니다. set이나 multiset에 저장된 값을 변경하고자 한다면, 변경할 부분은 절대로 키 부분(key part)이 아니어야 한다는 것입니다.

        만에 하나 키 부분을 건드리면 컨테이너는 엉망이 되고, 이 컨테이너는 예기치 못한 동작을 수행하며, 모든 책임은 여러분이 뒤집어쓰게 됩니다.
        
        한편 키 부분이 아닌 데이터들은 이런 제약을 전혀 받지 않습니다.

      • set과 multiset의 요소가 const 타입이 아니라고 해도, 여기에 저장된 데이터 요소의 변경을 막도록 STL 라이브러리가 구현되었을 수도 있습니다.

        set<T>::iterator에 대한 operator* 연산자 함수를 const T&(상수 데이터 참조자)를 반환하도록 구현하는 것이 한 예입니다.
        
        이렇게 하면 set이나 multiset의 요소는 전혀 변경할 수 없게 됩니다. 왜냐하면 set의 요소를 액세스하기 전에 const가 붙게 되거든요.
        
        이렇게 구현해도 맞는 것일까요? 아마 틀림없이 그럴 수도 있고, 아닐 수도 있습니다. 이 부분에 대해 모호한 설명을 하고 있는 표준안 때문입니다. 따라서 앞에서 본 예제 코드가 어떤 STL 플랫폼에서는 컴파일되지 않는 경우도 드물지 않습니다.
        
        모호한 표준안과 그것에 대한 다른 해석 때문에, set이나 multiset의 요소를 수정하는 코드는 결국 이식성에 지장을 주게 됩니다.
        
        그렇다면 과연 어떻게 해야 한단 말일까요? 다행스럽게도 문제는 그리 복잡하지 않습니다.
        
        
        • 이식성에 별 생각이 없다면 값을 바꾸세요. 여러분의 STL 플랫폼에서 지원된다면 그냥 하는 것입니다. 단 앞에서 말했듯이 컨테이너의 정렬에 영향을 주는 부분, 즉 키 부분 데이터는 변경하지 않도록 각별히 주의해야 합니다.
        • 코드 이식을 고려하고 있다면, set과 multiset의 요소를 변경하는 것은 불가능하다고 못박는 것이 좋습니다. 최소한 캐스팅을 하지 않는다면 그렇습니다.
        
        
        set/multiset 요소 변경을 정확하고 이식성 있게 할 수 있는 방법은 캐스팅 뿐입니다. 어렵진 않지만 많은 프로그래머들이 자칫 실수하기 쉬운 세심함이 필요합니다. 답은 참조자(reference)로의 캐스팅입니다.
        
        예제 코드 보기
        
        
        

        1. EmpIDSet::iterator i = se.find(selectedID);
        2. if (i != se.end()) {
        3. i->setTitle("Corporate Deity"); // 어떤 STL 플랫폼에서는 이 코드
        4. } // 를 거부합니다. *i가 const 이니까요
        5.  
        6. // 이 코드의 컴파일과 실행 모두가
        7. // 제대로 되게 하려면 *i의 상수
        8. // 성질을 날려 버려야 합니다.
        9.  
        10. // 아래가 그 정답입니다.
        11.  
        12. if (i != se.end()) { // *i의 상수 성질을
        13. const_cast<Employee&>(*i).setTitle("Corporate Deity"); // 캐스팅을 통해
        14. } // 없앱니다.
        15.  
        16. // 이 코드가 맞는 이유 대신에
        17. // 많은 사람들이 시도해 보지만
        18. // 자주 실패하는 다른 방법을
        19. // 우선 보여줄까 합니다.
        20.  
        21. if (i != se.end()) { // *i를
        22. const_cast<Employee>(*i).setTitle("Corporate Deity"); // Employee로
        23. } // 캐스팅합니다.
        24.  
        25. // 사실 이 코드는 다음과 똑같습니다.
        26.  
        27. if (i != se.end()) { // 앞과 똑같으나,
        28. ((Employee)(*i)).setTitle("Corporate Deity"); // C 문법의 캐스팅
        29. } // 방법을 썼습니다.
        30.  
        31. // 이 두 코드는 컴파일되지만,
        32. // 이 둘은 결국 동일한 기계어
        33. // 코드를 만들고, 역시 동일한
        34. // 이유로 오작동을 일으킵니다.
        35.  
        36. // 런타임에서 *i가 전혀 수정되지
        37. // 않거든요.
        38.  
        39. // 캐스팅을 수행한 결과는 *i의
        40. // 사본인 임시 객체이며, setTitle은
        41. // 이 객체에서 호출됩니다.
        42.  
        43. // 이 두 코드를 문법적으로
        44. // 풀어 보면 다음과 같습니다.
        45.  
        46. if (i != se.end()) {
        47. Employee tempCopy(*i); // *i를 tempCopy에 복사합니다.
        48. tempCopy.setTitle("Corporate Deity"); // tempCopy를 수정합니다.
        49. }

        
        
        예제 코드 접기
        
        
        

      • 어쨌든 캐스팅을 남발하는 것은 확실히 좋지 않다는 사실을 모르는 분은 없을 것입니다. 하지만, 캐스팅을 피한다면 어떤 대안이 필요할 것입니다. set, multiset, map, multimap에 저장된 요소를 바꾸고 싶은데, 어떤 플랫폼에서든 동작하고 안전하게 하는 방법은 물론 있습니다. 다섯 단계만 간단히 거치면 됩니다.

        1. 변경하고자 하는 컨테이너 요소의 위치를 찾습니다. 좋은 방법을 확신할 수 없다면 항목 45에 나온 가이드라인을 참조해서 적당한 탐색 방법을 사용하세요.
        2. 변경하고자 하는 요소의 복사본을 만듭니다. map이나 multimap의 경우에는 사본의 첫째 요소를 const 타입으로 선언하지 않도록 주의하세요. 어쨌든 바꿀 것이니까요.
        3. 컨테이너에서 그 요소를 없앱니다. 대개 erase를 호출하면 됩니다(항목 9를 참조).
        4. 만들어둔 복사본의 정보를 바꿉니다. 여러분이 원하던 값으로 바꾸면 됩니다.
        5. 복사본을 컨테이너에 새로 삽입합니다. 새로 삽입되는 복사본의 위치가 3단계에서 제거된 요소와 같거나 그 옆이면, insert에 단계 1에서 얻어낸(제거된 요소의) 반복자를 넘겨 호출함으로써 삽입 시간을 로그 시간에서 상수 시간으로 단축시킬 수 있습니다.
        
        
        예제 코드 보기
        
        
        

        1. EmpIDSet se; // 앞의 경우와 같습니다. se는
        2. // 식별 번호로 정렬되는 set입니다.
        3.  
        4. Employee selectedID; // 앞의 경우와 같습니다. selectedID는 원하는
        5. // 식별 번호를 가진 더미 직원 데이터입니다.
        6. ...
        7. EmpIDSet::iterator i =
        8. se.find(selectedID); // 단계 1: 바꾸고자 하는 요소를 찾습니다.
        9. if (i != se.end()) {
        10. Employee e(*i); // 단계 2: 요소를 복사합니다.
        12. se.erase(i++); // 단계 3: 컨테이너에서는 그 요소를 지웁니다.
        13. // erase 호출시 반복자를 후위 증가시켜
        14. // 반복자가 유효성을 잃지 않게 합니다.
        16. e.setTitle("Corporate Deity"); // 단계 4: 복사본을 수정합니다.
        18. se.insert(i, e); // 단계 5: 새 값(복사본)을 삽입합니다.
        19. // 삽입 위치는 원래의 요소의 위치와
        20. } // 같다는 정보를 사용합니다.
        21.  

        
        
        예제 코드 접기
        
        
        

      • 꼭 기억해 둘 중요한 사항은 "set/multiset에 저장된 요소의 정보를 바꿀 때에는 바꾼 후에도 반드시 모든 요소가 정렬되어 있도록 유지해야 한다"는 것 입니다.

  23. ★ 연관 컨테이너 대신에 정렬된 vector를 쓰는 것이 좋을 때가 있다 / 160

      • "빠른 데이터 검색을 지원하는 자료구조가 필요하다"는 생각을 하는 STL 프로그래머 중 열의 아홉이 떠올리는 것이 연관 컨테이너입니다. 뭐, 별 문제 없습니다. 잘 아시는 바, 연관 컨테이너는 '웬만큼' 합니다. 하지만, 그 이상을 말하라면 조금 무리입니다. 탐색 속도가 정말로 중요한 경우라면 비표준의 해쉬 컨테이너를 사용하는 것이 거의 훨씬 낫습니다(항목 25를 참조).

        해쉬 함수만 엉터리로 만들지 않는 이상, 해쉬 컨테이너는 상수 시간의 빠른 탐색 속도를 내줍니다. 반면, set, map 및 이들의 multi 버전은 로그 시간의 탐색 속도를 갖습니다.

      • 다시 표준으로 돌아와서, 여러분이 원했던 것이 로그 시간의 속도를 가진 탐색이었다고 칩시다. 그렇다고 해도 연관 컨테이너가 여전히 그리 좋지 않은 선택일 수가 있답니다.

        표준 연관 컨테이너는 전형적으로 균형 이진 탐색 트리(balanced binary search tree)로 구현되어 있습니다. 이 트리는 데이터 노드의 삽입, 삭제, 탐색이 임의대로 아무 때나 이루어지는 상황에 적합하도록 구현된 자료 구조입니다.
        
        하지만, 많은 어플리케이션이 이렇게 극단적으로 혼란스럽게 자료구조를 사용하지는 않습니다. 대개 다음의 3단계로 압축되는 순서를 따르는 것이 보통이지요.
        
        
        1. 데이터 셋업(Setup). 자료 구조를 하나 만들고, 많은 데이터 요소를 여기에 넣습니다. 이때 이루어지는 동작은 데이터 삽입 및 삭제가 대부분이며, 탐색은 거의 일어나지 않습니다.
        2. 데이터 탐색(Lookup). 셋업이 끝난 자료 구조를 사용하여 원하는 정보가 들어 있는지 찾습니다. 이 단계에서 이루어지는 대부분의 동작은 탐색입니다. 삽입 및 삭제는 드물고요.
        3. 데이터 재구성(Reorganize). 자료 구조에 들어 있는 내용물을 바꿉니다. 대개 이때 기존의 데이터를 모두 지우고 새 데이터를 집어넣게 됩니다. 동작상으로 볼 때 단계 1과 흡사합니다. 일단 이 단계가 끝나면, 애플리케이션은 다시 단계 2로 진입합니다.
        
        
        이러한 방식으로 자료 구조를 사용하는 애플리케이션이라면 정렬된 벡터가 연관 컨테이너보다 훨씬 나은 수행성능을 제공할 가능성이 높습니다(수행 시간과 메모리 공간 모두).
        
        단 이 벡터는 반드시 정렬(sort)되어 있어야 한다는 제약이 따르죠. 왜냐하면 벡터의 요소가 정렬된 상태에 있을 때 binary_search, lower_bound, equal_range 등의 탐색 알고리즘을 제대로 적용할 수 있기 때문입니다(항목 34 참조).

      • 하지만, 어째서 벡터가 이진 탐색 트리에 이진 탐색을 수행하는 것보다 더 나은 것일까요? 이유는 크게 두 부분으로 나눌 수 있습니다. 첫째 이유는 진부하지만 어쩔 수 없는 메모리 크기 문제입니다.

        Widget 객체를 담을 컨테이너를 사용하려고 하는데 연관 컨테이너를 쓸 것인지, 정렬된 벡터를 쓸 것인지 갈팡질팡하고 있는 중이라고 합시다.
        
        여기서 연관 컨테이너를 선택하면 결국 균형 이진 탐색 트리를 쓰게 되는 셈인데요, 이런 트리는 트리 노드가 포인터로 연결된 구조를 띱니다. 각 노드에는 Widget 뿐만 아니라 해당 노드의 왼쪽 자식과 오른쪽 자식 노드의 포인터와 (대개) 부모 노드에 대한 포인터가 기본적으로 딸려 있게 됩니다. 즉, 연관 컨테이너에 Widget 하나 저장하는데 최소한 세 개의 포인터를 담을 메모리가 오버헤드로 걸린다는 말이죠.
        
        반대로, Widget을 vector에 저장하는 데에는 이런 오버헤드가 없습니다. 그냥 Widget 하나가 저장될 뿐입니다.
        
        물론 벡터에 오버헤드가 없는 것은 아닙니다. 메모리의 여유분이 예약되어 있으니까요(항목 14 참조). 하지만, 벡터 자체에 걸리는 메모리 오버헤드는 그렇게 크지 않습니다. 그리고 필요 없는 메모리 여유분은 바꿔치기 묘수를 써서 잘라낼 수도 있습니다(항목 17을 참조).
        
        그냥 둔다고 해도 이것이 수행성능에 중대한 영향을 미치지도 않습니다. 이 부분은 탐색 시 건드리지 않기 때문입니다.
        
        Widget의 메모리 크기가 12바이트이고, 작업하는 시스템에서는 포인터의 크기가 4바이트이며, 메모리 페이지 하나의 크기가 4096(4K) 바이트라고 가정합시다.
        
        컨테이너 자체의 오버헤드를 무시하고 계산할 때, vector에 저장하는 경우에는 한 페이지에 341개의 Widget이 들어갑니다. 하지만 연관 컨테이너에 저장하게 되면 한 페이지에 들어가는 Widget의 개수는 170개 정도(Widget 하나에 포인터 3개)입니다. 약 두 배의 차이가 나는 거죠.
        
        사용 메모리가 많아지면 페이지 오류(page fault)도 그만큼 많아지게 되며, 데이터 크기가 더 커짐에 따라 결국 시스템의 속도는 진흙에 발빠진 상황이 되는 것은 불 보듯 뻔합니다.

      • 두 번째 이유는 덜 진부하지만 역시 사실인데, 1장에서 잠깐 언급한 메모리 참조 위치의 근접성(locality of reference)의 문제 때문입니다.

        대부분의 STL 제품은 커스텀 메모리 관리자(컨테이너 자체의 할당자를 기반으로 구현됩니다. 항목 10과 11을 참고하세요)를 통해 이진 트리에 들어 있는 노드는 상대적으로 적은 개수의 메모리 페이지에 한데 모여 있도록 구현되어 있습니다.
        
        하지만 아무리 훌륭한 커스텀 메모리 관리자가 뒤를 봐주고 있다고 해도, 연관 컨테이너는 페이지 오류 때문에 생기는 문제를 벡터보다 더 많이 겪습니다.
        
        왜 그럴까요? 벡터처럼 연속 메모리 구조를 취하지 않는 노드 기반의 컨테이너에서는, 이동 경로가 가까운 노드 사이(이를테면 부모 노드와 지식 노드)라 할 지라도 반드시 물리 메모리 위치도 가까울 거라는 보장을 할 수 없기 때문입니다.
        
        하지만, 이진 탐색 시의 페이지 오류를 최소화하려면 가까운 노드들은 인접한 물리 메모리에 저장되도록 구조를 만드는 것이 정석입니다.
        

      • set 대신에 정렬된 벡터를 사용하는 예제 코드도 한번 봐주세요.

        set/multiset 대신 vector를 사용한 예제 코드 보기
        
        
        

        1. vector<Widget> vw; // set<Widget> 대신에 쓰인 벡터
        2.  
        3. ... // 데이터 셋업 단계: 지겹게 삽입하고,
        4. // 탐색은 거의 안 합니다.
        5. sort(vw.begin(), vw.end()); // 셋업 단계의 끝마무리입니다.
        6. // (multiset 대신에 사용하는 벡터라면
        7. // sort 대신에 stable_sort를 사용하세요.
        8. // 항목 31을 참고하시고요.
        9.  
        10. Widget w; // 탐색하고자 하는 값을 가진 객체
        11.  
        12. ... // 탐색 단계를 시작합니다.
        13. if (binary_search(vw.begin(), vw.end(), w)) ... // binary_search로 탐색합니다.
        14. vector<Widget>::iterator i =
        15. lower_bound(vw.begin(), vw.end(), w); // lower_bound로 탐색합니다.
        16. if (i != vw.end() && !(w < *i)) ... // "!(w < *i)"를 사용해서 검사하는
        17. // 것에 대해서는 항목 45를 보세요.
        18.  
        19. pair<vector<Widget>::iterator,
        20. vector<Widget>::iterator> range =
        21. equal_range(vw.begin(), vw.end(), w); // equal_range로 탐색합니다.
        22. if (range.fisrt != range.second) ...
        23. ... // 탐색 단계가 끝났습니다. 이제
        24. // 재구성 단계를 시작합니다.
        25.  
        26. sort(vw.begin(), vw.end()); // 탐색 단계를 다시 시작합니다.
        27.  

        
        
        set/multiset 대신 vector를 사용한 예제 코드 접기
        
        
        vector를 써서 map이나 multimap을 대신하려면 어떻게 할까요? 이 벡터에는 키와 값을 묶은 pair 객체를 넣어야 합니다.
        
        map<K, V>타입의 객체를(multimap도 마찬가지이죠) 선언한다고 할 때 이 맵에 저장되는 요소의 타입은 pair<const K, V>입니다. 하지만, vector로 map이나 multimap을 흉내낼 때에는 이 const 부분을 빼어야 합니다.
        
        왜냐하면 벡터를 정렬할 때 각 요소의 값이 대입 연산을 통해 이동하기 때문입니다. 결론적으로, 벡터에 저장되는 pair 객체는 pair<K, V>로 선언되어야 합니다.
        
        map과 multimap은 내부 요소를 정렬해서 관리하지만, 사실 정렬하는데 고려하는 것은 페어 객체의 키 부분뿐이니까 벡터를 정렬할 때에도 똑같이 하면 됩니다. 단 pair에 기본적으로 주어지는 operator<는 pair의 두 멤버 데이터를 모두 고려하기 때문에, 정렬에 사용할 비교 함수를 만들어 두어야 합니다.
        
        참, 여기서 주의! vector를 써서 map/multimap을 대신할 때에는 정렬용 비교 함수 외에 탐색용 비교 함수를 따로 두어야 합니다.
        
        정렬에 사용되는 비교 함수는 두 개의 pair 객체를 매개 변수로 받지만, 탐색은 키 값만 가지고 이루어지기 때문입니다.
        
        따라서, 탐색용 비교 함수는 키 타입의 객체와 페어 객체를 매개 변수로 받는 꼴을 취하는 것이죠.
        
        또 하나 웃기는 점은 이 함수의 첫째 매개 변수로 들어가는 데이터가 키 값인지, 페어 객체인지 알 수가 없다는 점입니다. 따라서 양쪽의 경우를 모두 고려하여 함수를 만들어야 합니다.
        
        다음 예제는 map<string, int>를 벡터로 흉내낸다고 가정하고 만들었습니다.
        
        map/multimap 대신 vector를 사용한 예제 코드 보기
        
        
        

        1. typedef pair<string, int> Data; // 이번 예제에서 "맵"에
        2. // 저장되는 데이터 타입
        3.  
        4. class DataCompare { // 비교용 함수가 되는
        5. public: // 클래스
        6. bool operator()(const Data& lhs, // 정렬용
        7. const Data& rhs) const // 비교 함수
        8. {
        9. return keyLess(lhs.first, rhs.first); // keyLess는 아래에 있습니다.
        10. }
        11. bool operator()(const Data& lhs, // 탐색용
        12. const Data::first_type& k) const // 비교 함수
        13. { // (형태 1)
        14. return keyLess(lhs.first, k);
        15. }
        16. bool operator()(const Data::first_type& k, // 탐색용
        17. const Data& rhs) const // 비교 함수
        18. { // (형태 2)
        19. return keyLess(k, rhs.first);
        20. }
        21. private:
        22. bool keyLess(const Data::first_type& k1, // "실제"로
        23. const Data::first_type& k2) const // 비교하는
        24. { // 함수
        25. return k1 < k2;
        26. }
        27. };
        28.  
        29. // keyLess 함수는 operator() 함수에서
        30. // 사용하게 될 정렬 기준의 일관성을
        31. // 유지하기 위해 마련한 것입니다.
        32.  
        33. // 매번 똑같은 로직을 반복해서
        34. // 타이핑할 필요는 없으니까요.
        35.  
        36. // 이런 방식으로 만들면 DataCompare의
        37. // 유지 보수성을 높이는데 큰
        38. // 도움이 되지만, 사소한 약점도
        39. // 존재합니다.
        40.  
        41. // 다른 타입의 매개 변수를 넘기기
        42. // 때문에 함수 객체의 응용도가
        43. // 떨어진다는 것인데(항목 40을
        44. // 참조), 신경 쓰실 분만 쓰세요.
        45.  
        46. // 정렬된 벡터를 맵처럼 사용하는
        47. // 방법은 벡터를 셋처럼 사용하는
        48. // 경우와 거의 똑같습니다.
        49.  
        50. vector<Data> vd; // map<string, int> 대신에
        51. // 쓰인 벡터
        52.  
        53. ... // 데이터 셋업 단계: 삽입만 많고,
        54. // 탐색은 거의 안 합니다.
        55. sort(vd.begin(), vd.end(), DataCompare()); // 셋업 단계의 끝 마무리입니다
        56. // (multiset 대신에 사용하는 벡터라면
        57. // sort 대신에 stable_sort를 사용하세
        58. // 요. 항목 31을 참고하시고요).
        59.  
        60. string s; // 탐색하고자 하는 값을 가진 객체
        61. ... // 탐색 단계를 시작합니다.
        62. if (binary_search(vd.begin(), vd.end(), s,
        63. DataCompare())) ... // binary_search로 탐색합니다.
        64. vector<Data>::iterator i =
        65. lower_bound(vd.begin(), vd.end(), s,
        66. DataCompare()); // lower_bound로 탐색합니다.
        67. if (i != vd.end() && !(s < i->first)) ... // "!(s < i->first)"를 사용한 검사에
        68. // 대해서는 역시 항목 45를 보세요.
        69. pair<vector<Data>::iterator,
        70. vector<Data>::iterator> range =
        71. equal_range(vd.begin(), vd.end(), s,
        72. DataCompare()); // equal_range로 탐색합니다.
        73. if (range.first != range.second) ...
        74. ... // 탐색 단계가 끝났습니다. 이제
        75. // 재구성 단계를 시작합니다.
        76.  
        77. sort(vd.begin(), vd.end(), DataCompare()); // 탐색 단계를 다시 시작합니다.
        78.  

        
        
        map/multimap 대신 vector를 사용한 예제 코드 접기
        
        
        

      • 여러분의 프로그램이 앞에서 이야기한 3단계의 순서를 따라 자료구조를 조작하는 타입이어야 한다는 조건을 만족한다면, 연관 컨테이너보다 정렬된 벡터가 실행 속도도 빠르고 메모리 사용량도 엄청나게 줄어듭니다. 그렇지 않은 경우라면 표준 연관 컨테이너가 더 낫습니다.

  24. ★ map::operator[]나 map::insert는 효율 문제에 주의하여 선택하자 / 167

      • 맵에 새로운 요소를 "추가"할 경우에는 operator[]보다 insert가 효율적으로 낫습니다.

        map의 operator[] 연산자 함수는 vector, deque, string에 정의된 그것과 달리 유별난 특징을 가지고 있습니다. map::operator[]는 "추가 아니면 갱신(add or update)" 기능을 수행하도록 설계되었습니다. 즉,
        
        map<K, V> m;
        
        이 있다고 할 때, 다음의 표현식
        
        m[k] = v;
        
        은 우선 해당 맵에 키 k가 들어 있는지 점검합니다. 그렇지 않다면 k와 v가 페어로 묶여서 맵에 새로 '추가'됩니다. k가 맵에 들어 있는 경우에는 k와 매핑(연관)된 값(value)이 v로 갱신됩니다.
        
        상당히 간편하다는 생각이 듭니다. 하지만 '간편함'은 원하는 키가 맵에 미리 들어 있고 그 키와 매핑된 값을 갱신할 때에만 의미가 있습니다. 만약 k가 map에 들어 있지 않으면 operator[]가 참조하는 값 객체 역시 없는 것입니다.
        
        이때, operator[]는 해당 map에 지정된 값 타입(value_type)의 기본 생성자를 사용하여 pair 객체를 새로 만들고, 이 객체의 참조자를 반환합니다. 결과적으로, 반환된 Widget 객체의 참조자를 통해 operator=연산자 함수가 호출되어 Widget 객체에 값이 대입됩니다.
        
        반면에, insert는 불필요한 기본 생성자와 대입 연산자의 호출 없이도 똑같은 작업을 수행할 수 있습니다.
        
        예제 코드 보기
        
        
        

        1. // 어떤 Widget 클래스가 있는데,
        2. // 이 클래스는 기본 생성자 외에 double을
        3. // 매개 변수로 줄 수 있는 생성자와
        4. // 대입 연산자를 가지고 있다고 가정해
        5. // 봅시다.
        6.  
        7. class Widget {
        8. public:
        9. Widget(void);
        10. Widget(double weight);
        11. Widget& operator=(double weight);
        12. ...
        13. };
        14.  
        15. // 이제 이 Widget을 가지고 map을 만들고,
        16. // 이 맵에 값을 넣어 초기화시킬 것입니다.
        17.  
        18. map<int, Widget> m;
        19. m[1] = 1.50;
        20.  
        21. // 이 시점에서 키 1에 대한 맵 엔트리가
        22. // 없으므로 operator[]는 Widget의 기본
        23. // 생성자를 사용하여 Widget 객체를 하나
        24. // 만들고, 이것과 키 1을 함께 묶은
        25. // 페어(pair) 객체를 만든 후에,
        26. // Widget 객체에 대한 참조자를
        27. // 반환합니다.
        28.  
        29. // 마지막으로 표현식에 있는 대입(=)
        30. // 연산자의 대상은 Widget 객체입니다.
        31.  
        32. // 결국 이 Widget 객체는 operator=를
        33. // 통해서 1.50을 받아들입니다.
        34.  
        35. // 말하자면, 이 문장
        36.  
        37. m[1] = 1.50;
        38.  
        39. // 은 기능적으로 풀어 볼 때 다음의 코드와
        40. // 동일합니다.
        41.  
        42. typedef map<int, Widget> IntWidgetMap; // typedef는 이 때
        43. // 참 편리합니다.
        44.  
        45. pair<IntWidgetMap::iterator, bool> result = // 키 1과 기본 생성자로
        46. m.insert((IntWidgetMap::value_type(1, Widget())); // 만들어진 값(Widget)
        47. // 객체를 묶어 맵 엔트리를
        48. // 새로 만듭니다.
        49. // value_type에 대해서는
        50. // 아래에 나온 설명을
        51. // 참고하세요.
        52.  
        53. result.first->second = 1.50; // 새로 만들어진 값 객체에
        54. // 대입합니다.
        55.  
        56. // 이제 operator[]를 사용하는 것이
        57. // 수행 성능을 떨어뜨릴 수 있는지
        58. // 확실히 아시겠죠?
        59.  
        60. // 이렇게 하지 말고 아예 Widget 객체를
        61. // 원하는 값을 생성자 매개 변수에 넣어
        62. // 바로 만들어 버리는 것이 효율적이라면
        63. // operator[]와 대입 연산자 대신에 다음과
        64. // 같은 insert 호출 한 번으로
        65. // 끝낼 수도 있을 것입니다.
        66.  
        67. m.insert(IntWidgetMap::value_type(1, 1.50));
        68.  
        69. // 이 한 줄은 이전의 긴 코드와 정확히 똑같은
        70. // 결과를 가져옵니다.
        71.  
        72. // 게다가 무려 세 개나 되는 함수 호출을
        73. // 줄였죠. Widget 객체를 임시로 만드는데
        74. // 필요한 기본 생성자 함수, 이것을 없애는데
        75. // 필요한 소멸자 함수, 그리고 Widget의
        76. // 대입 연산자 함수가 호출되지 않습니다.
        77.  
        78. // map과 multimap(항목 25에서 보게 될
        79. // 비표준 컨테이너인 hash_map과 hash_multimap도
        80. // 해당됩니다)에 저장되는 요소의 타입(value_type)은
        81. // 어찌 되었든 pair라는 점을 주의하세요.

        
        
        예제 코드 접기
        
        
        

      • 반면에, 맵에 저장된 요소에 대한 "갱신"을 할 경우에는 insert보다 operator[]가 효율적으로나 미(美)적으로나 낫습니다.

        insert에는 IntWidgetMap::value_type 타입의 매개 변수(즉 pair<int, Widget>)를 넘겨야 합니다.
        
        따라서 insert를 호출할 때 해당 타입의 객체를 생성했다가 소멸시키는 과정이 필연적으로 따릅니다. 즉, pair의 생성자와 소멸자가 호출되죠. 그 뿐이 아닙니다. pair<int, Widget> 자체에 Widget 객체가 들어 있기 때문에 Widget의 생성자와 소멸자도 덩달아 호출됩니다.
        
        반면 operator[]는 pair 객체를 사용하지 않기 때문에 페어와 Widget 모두에 대해 생성자와 소멸자를 호출할 일이 없습니다.
        
        예제 코드 보기
        
        
        

        1. // 동등한(equivalent) 키(항목 19 참조)가
        2. // 이미 map에 들어 있는 경우에는
        3. // 상황이 바뀝니다.
        4.  
        5. m[k] = v; // operator[]를 통해
        6. // k에 매핑된 값을
        7. // v로 갱신합니다.
        8.  
        9. m.insert(IntWidgetMap::value_type(k, v)).first->second = v; // insert를 통해
        10. // k에 매핑된 값을
        11. // v로 갱신합니다.
        12.  
        13. // 첫 인상부터 operator[]가 훨씬
        14. // 마음에 들 것입니다.
        15.  
        16. // insert에는 IntWidgetMap::value_type의
        17. // 매개 변수를 넘겨야 합니다. 이 과정에서
        18. // 불필요한 임시 객체의 생성과 소멸이
        19. // 일어납니다.
        20.  
        21. // 하지만 operator[]의 경우에는
        22. // 불필요한 임시 객체의 생성과 소멸이
        23. // 일어나지 않습니다.

        
        
        예제 코드 접기
        
        
        

      • 추가와 갱신, 이 두 마리의 토끼를 확실히 잡을 수 있는, 문법적으로도 깔끔한 함수를 STL에서 미리 만들어 두었으면 얼마나 멋졌을까요. 실제로 이런 함수는 STL에 없지만, 여러분이 직접 만들지 못할 정도로 무지하게 까다로운 것도 아닙니다.

        예제 코드 보기
        
        
        

        1. template <typename MapType, // 맵의 타입
        2. typename KeyArgType, // KeyArgType과
        3. typename ValueArgType> // ValueArgType가 타입 매개 변수인
        4. // 이유는 아래 설명을 읽으세요.
        5. typename MapType::iterator
        6. efficientAddOrUpdate(MapType& m,
        7. const KeyArgType& k,
        8. const ValueArgType& v)
        9. {
        10. typename MapType::iterator lb = // k의 위치 혹은 삽입 위치를
        11. m.lower_bound(k); // 찾습니다. "typename"이 필요한
        12. // 이유는 "Effective C++"의
        13. // 항목 42를 참고하세요.
        15. if (lb != m.end() && // lb는 k와 동등한 키를 가진 페어
        16. !(m.key_comp()(k, lb->first))) { // 를 가리킵니다...
        17. lb->second = v; // 해당 페어의 값을 갱신하고
        18. return lb; // 그것에 대한 반복자를
        19. } // 반환합니다.
        20. else {
        21. typedef typename MapType::value_type MVT;
        22. return m.insert(lb, MVT(k, v)); // 맵 엔트리인 pair(k, v)를 m에
        23. } // 추가하고, 새로 추가된 엔트리에
        24. } // 대한 반복자를 반환합니다.
        25.  
        26. // 우선 키 k의 값이 맵에 들어 있는지를
        27. // 점검해야 합니다.
        28.  
        29. // 이때, k가 들어 있는 경우에는 그
        30. // 키의 위치를 찾고, 아닌 경우에는
        31. // 삽입될 위치를 정합니다.
        32.  
        33. // 바로 lower_bound(항목 45 참조)의
        34. // 동작에 딱 맞지요.
        35.  
        36. // lower_bound는 두가지 목적을 가지고
        37. // 호출한 알고리즘이기 때문에, 실제로
        38. // 우리가 원하는 키 값을 가진 요소를
        39. // 찾았는지를 체크하는 과정이 한 번
        40. // 더 필요합니다.
        41.  
        42. // 따라서 둘째 줄에서 동등성 검사
        43. // (항목 19 참조)를 하게 됩니다.
        44.  
        45. // "갱신"인 경우의 처리 순서는 지극히
        46. // 간단합니다. 주석만 봐도 알수 있지요.
        47.  
        48. // "추가" 부분에서는 항목 22에서
        49. // 본 바 있는 insert의 "단축"
        50. // 형태를 사용하고 있습니다.
        51.  
        52. // m.insert(lb, MVT(k, v))는
        53. // lb가 k와 동등한 키를 가진 새
        54. // 요소의 위치를 정확히 가리키고
        55. // 있다는 사실을 이용하여 만든
        56. // 코드입니다.
        57.  
        58. // 표준안에 의하면 이런 단축 정보(lb)
        59. // 가 제대로 세팅되어 있으면 insert의
        60. // 수행 시간은 로그 시간이 아니라
        61. // 상수 시간으로 되어 있습니다.
        62.  
        63. // 재미있는 부분은 하나 더 있습니다.
        64.  
        65. // KeyArgType과 ValueArgType은
        66. // 맵에 저장된 타입일 필요가 없답니다.
        67.  
        68. // 맵에 저장될 타입으로 변환될 수만
        69. // 있으면(convertible) 됩니다.
        70.  
        71. // 만약 MapType::key_type과
        72. // MapType::mapped_type을
        73. // 사용하기로 정했다면, KeyArgType과
        74. // ValueArgType은 그냥 없앨 수
        75. // 있습니다.
        76.  
        77. // 하지만 이렇게 하면, efficientAddOrUpdate를
        78. // 호출하는 시점에서 불필요한 타입
        79. // 변환이 일어나기도 하기 때문에
        80. // 번거롭습니다.
        81.  
        82. // 예를 하나 봅시다.
        83.  
        84. class Widget {
        85. public:
        86. ...
        87. Widget& operator=(double weight);
        88. ...
        89. };
        90.  
        91. map<int, Widget> m;
        92.  
        93. // 이때, efficientAddOrUpdate를 다음과 같이
        94. // 호출했습니다.
        95.  
        96. efficientAddOrUpdate(m, 10, 1.5);
        97.  
        98. // 맵 m에 이미 키 10을 가지고 있는
        99. // 요소가 들어 있어서 "갱신" 동작이
        100. // 일어난다고 가정합시다.
        101.  
        102. // 이 경우 efficientAddOrUpdate 템플릿은
        103. // ValueArgType이 double이라고
        104. // 판정하고, 함수의 몸체 부분은
        105. // 키 10에 매핑된 Widget에 double 값
        106. // 1.5를 대입하는 형태로 꾸며집니다.
        107.  
        108. // 만일 efficientAddOrUpdate의 셋째
        109. // 매개 변수 타입으로 MapType::mapped_type을
        110. // 사용했다면, 함수 호출 시점에서 1.5가
        111. // Widget 객체로 변환되는 일이 벌어집니다.
        112.  
        113. // 결국 Widget 객체의 생성자와 소멸자가
        114. // 호출되는 비용을 떠안아야 합니다.

        
        
        예제 코드 접기
        
        
        

  25. ★ 현재는 표준이 아니지만, 해쉬 컨테이너에 대해 충분히 대비해 두자 / 174

      • 표준 C++ 라이브러리의 다음 버전에는 해쉬 테이블이 들어간다고 하고 있지만, 어쨌든 지금 현재의 STL은 해슁을 하지 않습니다. 하지만, STL에 완벽하게 호환되는 해쉬 테이블 기반의 연관 컨테이너를 여러 군데에서 쉽게 구할 수 있습니다.

        이 해쉬 컨테이너는 업계에서 이미 굳어진(do facto) 표준 이름까지 가지고 있습니다. hash_set, hash_multiset, hash_map, hash_multimap. 표준 컨테이너의 이름 앞에 hash_를 붙인 꼴이죠.
        
        이름은 같게 쓰이지만, 아직 표준이 안되었으므로 제품마다 구현은 조금씩 다르게 되어 있습니다. 인터페이스, 기능, 내부 자료 구조, 지원되는 함수의 상대적인 효율 모두가 차이가 납니다.
        
        해쉬 테이블을 사용한 코드를 이식성 있게 만드는 것이 불가능한 것은 아니지만, 아무래도 표준화된 것을 쓰는 것보단 못하겠지요(왜 표준이 중요한지 아시겠습니까?).

      • 시중에서 구할 수 있는 해쉬 컨테이너 중에 가장 대표적이며 흔히 쓰이고 있는 양대 산맥은 SGI의 버전(항목 50 참조)과 딩컴웨어(Dinkumware)의 버전입니다. STLPort(항목 50 참조)도 해쉬 컨테이너를 제공하고 있지만, 이 컨테이너는 SGI의 것을 모태로 하고 있습니다(즉 SGI 해쉬 컨테이너에 대한 이야기는 STLPort의 것도 마찬가지로 적용됩니다).

      • 해쉬 컨테이너는 말씀 드렸듯이 연관 컨테이너입니다. 따라서 다른 연관 컨테이너와 마찬가지로 컨테이너에 저장되는 객체와 그 객체에 대한 비교함수, 할당자의 타입을 알아야 합니다. 새로운 특징이라면 해쉬 컨테이너는 해쉬 함수(hashing function)를 지정해야 한다는 점이겠습니다.

        예제 코드 보기
        
        
        

        1. // SGI 버전의 해쉬 컨테이너인
        2. // hash_set의 타입은 다음과
        3. // 같이 나타낼 수 있습니다
        4. // (보기 좋은 형태로 조금 바꾸었습니다).
        5.  
        6. template <typename T,
        7. typename HashFunction = hash<T>,
        8. typename CompareFunction = equal_to<T>,
        9. typename Allocator = allocator<T> >
        10. class hash_set;
        11.  
        12. // 눈여겨 볼 점은 비교 함수에 대한
        13. // 기본 타입으로 equal_to를 사용하고
        14. // 있다는 것입니다.
        15.  
        16. // 즉, 두 객체가 같은지 알아볼 때
        17. // 동등성이 아닌 상등성 검사(항목 19
        18. // 참조)를 한다는 말입니다.
        19.  
        20. // 해쉬 테이블을 생각해 보면,
        21. // 표준 컨테이너가 목숨 걸고
        22. // 지키는 정렬 순서가 해쉬
        23. // 컨테이너에겐 무의미하기 때문에
        24. // 이런 구현이 어이없는 구현은
        25. // 아닙니다.
        26.  
        27. // 딩컴웨어에서 설계한 해쉬 컨테이너는
        28. // 조금 다른 전략을 취하고 있습니다
        29. // (역시 보기 좋은 형태로 조금 바꾸었습니다).
        30.  
        31. template <typename T, typename CompareFunction>
        32. class hash_compare;
        33. template <typename T,
        34. typename HashingInfo = hash_compare<T, less<T> >,
        35. typename Allocator = allocate<T> >
        36. class hash_set;
        37.  
        38. // 이 인터페이스 설계에서 찾을 수 있는
        39. // 재미있는 부분은 바로 HashingInfo
        40. // 입니다.
        41.  
        42. // 컨테이너에서 사용할 해쉬 함수와
        43. // 비교 함수가 여기에 들어가지요.
        44.  
        45. // 또한 여기에는 해쉬 테이블의 최소
        46. // 버킷 개수가 들어 있으며, 버킷
        47. // 개수에 대한 컨테이너 요소 개수의
        48. // 최대 허용 비율이 나열 타입으로
        49. // 들어 있습니다.
        50.  
        51. // SGI 버전의 경우 이 수치를
        52. // 조정하는 멤버 함수를 제공하고
        53. // 있습니다.
        54.  
        55. // 보기 쉽게 정리하고 나면, hash_compare는
        56. // 대강 다음과 같은 형태를 취하고 있습니다.
        57.  
        58. template <typename T, typename CompareFunction = less<T> >
        59. class hash_compare {
        60. public:
        61. enum {
        62. bucket_size = 4, // 버킷에 대한 요소 개수의 최대 비율
        63. min_buckets = 8 // 버킷의 최소 개수
        64. };
        65. size_t operator()(const T&) const; // 해쉬 함수
        66. bool operator()(const T&, // 비교 함수
        67. const T&) const;
        68. ... // CompareFunction을 사용하는 방법 등이
        69. }; // 더 있는데, 생략하였습니다.
        70.  
        71. // 딩컴웨어 버전의 해쉬 컨테이너는
        72. // hash_compare와 비슷한 클래스를
        73. // 직접 만들어 사용할 수 있도록
        74. // (hash_compare에서 파생시키면
        75. // 가능하겠죠?) 만들어져 있습니다.
        76.  
        77. // 위의 코드에 나온 것들과, 생략한
        78. // 몇 가지만 제대로 갖추어져 있으면
        79. // 딩컴웨어에서 제공하는 hash_set과
        80. // hash_multiset의 동작을
        81. // 완벽하게 조정할 수 있습니다.
        82.  
        83. // hash_map과 hash_multimap에
        84. // 대해서도 비슷합니다.

        
        
        예제 코드 접기
        
        
        SGI나 딩컴웨어에서 제공하는 해쉬 컨테이너에 대해 꼬치꼬치 알지 않고, 아무 생각 없이 이렇게 써도 양쪽에서 모두 통합니다.
        
        hash_set<int> intTable;
        // int를 담는 해쉬 셋을 만든다.
        
        이 문장이 컴파일되려면 해쉬 테이블에는 숫자 타입(int)의 데이터가 들어가야 합니다. 왜냐하면 기본 해쉬 함수는 대개 숫자 타입에 대해 동작하도록 한정되어 있기 때문입니다.
        
        하지만 각각을 한 꺼풀 벗겨 보면, 구현된 내부 동작은 서로 다른 길을 가고 있습니다. 간단히 설명하자면, SGI는 해쉬 테이블 요소를 단일 연결 리스트로 저장하고, 딩컴웨어는 이중 연결 리스트로 저장한다는 것입니다.
        
        물론 양쪽의 차이는 있습니다. SGI의 해쉬 컨테이너는 순방향 반복자만 지원하므로 역방향으로 도는 일은 꿈에서나 바라야 할 것입니다. 물론 rbegin이나 rend 같은 함수도 찾아볼 수 없습니다.
        
        딩컴웨어의 해쉬 컨테이너는 양방향 동작이 모두 가능한 대신에, 메모리를 조금 더 많이 사용합니다.

• Chapter 4   반복자(Iterators)

  26. const_iterator나 reverse_iterator, const_reverse_iterator도 좋지만 역시 쓸만한 것은 iterator이다 / 182

      • 모든 STL 표준 컨테이너는 네 가지 타입의 반복자를 모두 제공합니다. container<T>라고 정의된 컨테이너가 있다고 하면 iterator는 T*와 같은 개념이고 const_iterator는 const T*와 똑같은 구실을 합니다. iterator나 const_iterator를 증가시키면, 해당 반복자는 현재 가리키고 있는 요소의 그 다음 요소를 가리키며, 위치는 컨테이너의 처음과 멀어지고 끝과 가까워집니다.

        iterator는 const_iterator로 암시적(implicit) 변환이 가능하며, iterator와 const_iterator는 각각 reverse_iterator와 const_reverse_iterator로 암시적 변환이 가능합니다.

      • reverse_iterator와 const_reverse_iterator는 역시 각각 T*와 const T*와 같은 개념으로 동작하되, 이 반복자를 증가시키면 컨테이너의 끝에서 처음을 향해 이동합니다.

        reverse_iterator는 const_reverse_iterator로 암시적 변환이 가능하며, reverse_iterator와 const_reverse_iterator는 base()를 통해 각각 iterator와 const_iterator로 변환이 가능합니다.

      • 요소 삽입과 삭제를 해주는, insert나 erase와 같은 함수는 모든 STL 표준 컨테이너서 제공됩니다. 컨테이너 타입에 따라 반환 타입이 조금 다르기만 하지요. 이런 insert나 erase와 같은 함수는 매개변수 타입으로, 네 가지의 반복자 타입 중에 iterator만을 요구한다는 점이 중요합니다. 하지만 const_iterator를 iterator로 변환할 방법이 없기 때문에, 요소 삽입 위치나 삭제 위치를 지정하거나 하는데 있어서 상수 반복자(const_iterator)는 대개 쓸모가 없습니다.

        그렇다고 해서 상수 반복자가 일반적으로 쓸모 없다는 것은 아닙니다. 상수 반복자는 알고리즘에서 제 구실을 합니다. 왜냐하면, 알고리즘은 자신이 사용하는 반복자의 종류에 상관없이 동작하기 때문입니다. 물론 적절한 부류에 속해 있어야 하겠지만요.
        
        또한 컨테이너의 많은 멤버 함수에서 상수 반복자를 받아 들입니다. 오직 insert와 erase 류의 함수에서만 const_iterator를 쓸 수 없습니다.

      • 상수 반복자와 역방향 반복자보다 비상수 반복자 타입인 iterator를 쓰는 것이 좋은 이유는 3 가지로 정리할 수 있습니다.

        • 어떤 형태의 insert와 erase 멤버 함수는 무조건 iterator만을 넘겨야 합니다. 혹시 이런 함수를 호출하려면 iterator 외에 대안이 없습니다.
        • const_iterator를 iterator로 암묵적(implicit)으로 변환할 방법은 없으며, 굳이 바꾸려면 항목 27에서 소개하는 방법을 쓰면 되지만 일반성도 떨어지며 효율에 대한 보장도 할 수 없습니다.
        • reverse_iterator를 iterator로 변환할 수 있으나, 변환한 후에 약간의 조정이 필요합니다. 언제, 그리고 왜 이렇게 하는지에 대해서는 항목 28에서 공부하겠습니다.

      • 행여 const_iterator를 사용하고 있고, 컨테이너의 멤버 함수에 iterator를 넘길 필요가 없을 때 조차도, iterator를 써야 하는 이유가 있으니 환장할 노릇이죠? 가장 성가신 것 중 하나가 iterator와 const_iterator를 비교하는 경우입니다.

        예제 코드 보기
        
        
        

        1. typedef deque<int> IntDeque; // STL 컨테이너와
        2. typedef IntDeque::iterator Iter; // 반복자 타입은 typedef를
        3. typedef IntDeque::const_iterator ConstIter; // 써서 줄여 사용할 때
        4. // 훨씬 편합니다.
        5. Iter i;
        6. ConstIter ci;
        7.  
        8. ... // i와 ci가 동일한 컨테이너를
        9. // 가리키도록 합니다.
        10.  
        11. if (i == ci) ... // 반복자와 상수 반복자를
        12. // 서로 비교합니다.
        13.  
        14. // 잘 설계된 STL 제품의 경우
        15. // iterator가 암묵적으로 const_iterator로
        16. // 변환되어, 위의 코드는 문제가
        17. // 생겨서는 안 됩니다.
        18.  
        19. // 일부 엉터리(?) 제품의 경우
        20. // 이 코드가 컴파일 되지 않는 경우가
        21. // 있어서 골치입니다.
        22.  
        23. // 이유는 const_iterator에 대해
        24. // operator==를 멤버 함수로
        25. // 선언해 두었기 때문입니다(비멤버
        26. // 함수로 선언하여 두 개의 매개
        27. // 변수를 받게 하면 해결됩니다).
        28.  
        29. // 해결책은 간단합니다. 다음과 같이
        30. // 피연산자의 순서를 바꿉니다.
        31.  
        32. if (ci == i) ... // 위의 비교문이 컴파일되지 않을 때의
        33. // 대처법
        34.  
        35. // 이러한 류의 문제는 비단 비교문
        36. // 뿐만 아니라 같은 표현식에다가
        37. // iterator와 const_iterator
        38. // (혹은 reverse_iterator와 const_reverse_iterator)
        39. // 를 섞어 섰을 때 언제라도 발생할 수
        40. // 있습니다.
        41.  
        42. if (i - ci >= 3) ... // i가 ci보다 3칸 이상 앞으로 가 있을 때...
        43.  
        44. // 이런 경우에는 단순히
        45. // i-ci를 ci-i로
        46. // 바꾸면 안되겠죠?
        47.  
        48. if (ci + 3 <= i) ... // 위의 코드가 컴파일되지 않을 때의
        49. // 회피 방안
        50.  
        51. // 이런 성가신 문제를 막는 가장 쉬운
        52. // 방법은 이 타입, 저 타입의 반복자를
        53. // 마구잡이로 섞어 쓰지 않는 것입니다.
        54.  
        55. // const_iterator 대신에
        56. // iterator를 쓰는것이 낫다는 말이죠.

        
        
        예제 코드 접기
        
        
        

  27. const_iterator를 iterator로 바꾸는 데에는 distance와 advance를 사용하자 / 186

      • iterator와 const_iterator는 서로 다른 클래스 입니다. 따라서 const_cast를 통해서 const_iterator를 iterator로 변환할 수는 없습니다.

        예제 코드 보기
        
        
        

        1. typedef deque<int> IntDeque; // 언제든지 편리한 typedef
        2. typedef IntDeque::iterator Iter;
        3. typedef IntDeque::const_iterator ConstIter;
        4.  
        5. ConstIter ci; // ci는 const_iterator입니다.
        6. ...
        7. Iter i(ci); // 바로 에러가 납니다! const_iterator에서
        8. // iterator로의 암묵적 캐스팅은 있을 수가 없습니다.
        9.  
        10. Iter I(const_cast<Iter>(ci)); // 그래도 에러입니다! const_iterator에서
        11. // iterator로 캐스팅을 할 수 없습니다.
        12.  
        13. // 이 예제 코드는 deque에 대한 것이지만,
        14. // 나머지 다른 컨테이너에서도 매 한가지로
        15. // 똑같습니다.
        16.  
        17. // 단 vector와 string은 될 수도
        18. // 있습니다.
        19.  
        20. // 왜냐하면 vector와 string의 iterator는
        21. // T* 의 typedef 타입(const_iterator는
        22. // const T* 의 typedef 타입)일 수도
        23. // 있거든요.
        24.  
        25. // 하지만 vector와 string의 반복자가
        26. // 단순 포인터로 정의되어 동작할 때는
        27. // 디버깅 정보가 빠지는 release 모드에서
        28. // 컴파일될 때 뿐입니다.
        29.  
        30. // 결국 모든 정황을 고려할 때 const_iterator를
        31. // iterator로 캐스팅을 하는 것은, vector나
        32. // string일지라도 좋지 못하다는 결론을 내릴 수
        33. // 있습니다. 이식성에 문제가 되니까요.
        34.  
        35. // iterator와 const_iterator는
        36. // 서로 다른 클래스입니다. string과
        37. // complex<double>의 관계보다도
        38. // 멉니다. 전혀 엉뚱한 클래스로 캐스팅하려고
        39. // 하니 말이 될 수가 없지요.
        40.  
        41. // 마찬가지로 static_cast, reinterpret_cast,
        42. // 가 아니면 C 스타일의 캐스팅 역시 무의미할 뿐입니다.

        
        
        예제 코드 접기
        
        
        

      • 그렇다면 정녕 컨테이너의 const_iterator를 iterator로 안전하고 이식성 있게 바꿀 수 있는 길은 없는걸까요? 물론 있습니다. 게다가 타입 시스템에 관한 껄끄러운 문제까지 피해갈 수 있는 방법이죠. 바로 distance와 advance를 사용하는 것입니다.

        예제 코드 보기
        
        
        

        1. typedef deque<int> IntDeque; // 이전과 같습니다.
        2. typedef IntDeque::iterator Iter;
        3. typedef IntDeque::const_iterator ConstIter;
        4.  
        5. IntDeque d;
        6.  
        7. ConstIter ci;
        8. ... // ci가 d의 요소를 가리키도록 합니다.
        9. Iter i(d.begin()); // i를 d.begin()으로 초기화합니다.
        10.  
        11. advance(i, distance(i, ci)); // ci가 있는 곳으로 i를 옮깁니다(하지만
        12. // 이 코드를 컴파일하기 전에 왜 바꾸어야
        13. // 하는지를 우선 읽으세요).
        14.  
        15. // i를 ci와 같은 컨테이너의 첫 요소를
        16. // 가리키도록 만든 다음 i를, i와 ci 사이의
        17. // 거리 만큼 이동시키는 것입니다.
        18.  
        19. // 하지만 위의 코드는 컴파일되지 않습니다.
        20. // 먼저 distance의 선언문을 보도록 합시다.
        21.  
        22. template <typename InputIterator>
        23. typename iterator_traits<InputIterator>::difference_type
        24. distance(InputIterator first, InputIterator last);
        25.  
        26. // 이 함수의 반환 타입은 신경 쓸 필요가
        27. // 없습니다. 지금은 타입 매개 변수인
        28. // InputIterator의 사용에 초점을
        29. // 맞줘서 봐야 합니다.
        30.  
        31. // 컴파일러는 distance가 호출된 부분을
        32. // 만나면 매개 변수를 검사해서 InputIterator에
        33. // 의해 나타나는 타입을 추측해 내야 합니다.
        34.  
        35. // 그렇다면, 앞에서 이용한 코드를 다시 살펴보죠.
        36.  
        37. advance(i, distance(i, ci)); // i를 ci가 있는 곳까지 옮깁니다.
        38.  
        39. // distance에는 두 개의 매개 변수가
        40. // 넘겨 졌습니다. i와 ci가 됩니다.
        41.  
        42. // i의 타입은 Iter(deque<int>::iterator의
        43. // typedef 타입) 입니다.
        44.  
        45. // 컴파일러가 distance 템플릿을 함수로
        46. // 만들 때 InputIterator로 가지고
        47. // 오는 타입은 바로 deque<int>::iterator
        48. // 입니다.
        49.  
        50. // 하지만 ci는 deque<int>::const_iterator
        51. // 입니다.
        52.  
        53. // InputIterator 부분이 동시에 두 개의
        54. // 다른 타입이 될 가능성은 없습니다.
        55.  
        56. // 따라서 distance 호출 부분의 컴파일이
        57. // 실패하는 것이죠.
        58.  
        59. // 이러한 타입에 관련된 모호함을 없애는 가장
        60. // 쉬운 방법은 distance에서 사용될 타입
        61. // 매개 변수를 직접 지정해 주는 것입니다.
        62.  
        63. advance(i, distance<ConstIter>(i, ci)); // i와 ci 사이의
        64. // 거리를 계산(const_iterator로)한
        65. // 후에, 그 거리만큼 i를 옮깁니다.
        66.  
        67. // iterator 타입인 i는 컴파일러에 의해
        68. // const_iterator로 저절로 바뀌기 때문에
        69. // 방금의 코드는 말끔히 컴파일됩니다.

        
        
        예제 코드 접기
        
        
        이 방법은 얼마나 효율적일까요? 반복자의 특성만큼 효율도 다릅니다. 임의 접근 반복자의 경우(vector, string, deque의 그것) 상수 시간에 동작이 완료되며, 양방햔 반복자(앞의 세 컨테이너를 제외한 나머지 표준 컨테이너와 양방향 반복자를 쓰도록 구현된 해쉬 컨테이너의 그것)의 경우 선형 시간에 동작이 완료됩니다.
        
        const_iterator를 iterator로 바꾸는데 선형 시간이 걸린다는 사실과 const_iterator에 대한 컨테이너가 없을 때는 전혀 소용이 없다는 사실 때문에 항목 26의 내용이 더욱 여러분의 가슴을 찌를 것 입니다.

  28. reverse_iterator에 대응되는 기점 반복자(base_iterator)를 사용하는 방법을 정확하게 이해하자 / 191

      • reverse_iterator에서 base 멤버 함수를 호출하면 이에 "대응되는(corresponding)" iterator를 얻어낼 수 있다고 합니다. 하지만 문서에 나와있는 대로 정확히 그러한 것은 아니라는 이야기를 하기 위해 이번 항목을 준비했습니다.

        이해를 돕기 위해 다음의 예제를 준비했습니다. 벡터에 1~5를 넣고, reverse_iterator를 써서 3을 가리키게 한 후에, iterator 하나를 이 reverse_iterator의 기점으로 세팅하는 코드입니다.
        
        예제 코드 보기
        
        
        

        1. vector<int> v;
        2. v.reserve(5); // 항목 14를 보세요.
        3.  
        4. for (int i = 1; i <= 5; ++i) { // 1~5를 벡터에 넣습니다.
        5. v.push_back(i);
        6. }
        7.  
        8. vector<int>::reverse_iterator ri = // ri가 3을 가리키게 합니다.
        9. find(v.rbegin(), v.rend(), 3);
        10.  
        11. vector<int>::iterator i(ri.base()); // i가 ri의 기점과 같게 합니다.
        12.  

        
        
        예제 코드 접기
        
        
        이 코드를 실행시키고 난 후의 상황은 다음의 그림처럼 됩니다. 꼼꼼히 잘 보세요.
        
        
        
        reverse_iterator와 iterator를 서로 변환하면 한칸씩 어긋나는 것을 볼 수 있습니다.

      • 항목 26에서 설명했듯이, 어떤 컨테이너 멤버 함수의 경우 반복자 매개 변수로 iterator만을 고집하기 때문에 ri가 가리키는 위치에 요소를 새로 삽입(insert)하고 싶다든가 할 때 멈칫! 할 수밖에 없습니다. ri가 가리키는 요소를 삭제(erase)할 때도 마찬가지이지요. 이런 경우 어쨌든 이 reverse_iterator를 iterator로 바꾸어야 합니다. 이때 사용하는 것이 base라는 멤버 함수입니다.

      • ri가 가리키는 vector<int>내의 위치에다가 숫자 99를 넣어 보고 싶다고 칩시다. ri는 오른쪽에서 왼쪽으로 이동하는 경로에 있으며, STL 세계에서 요소 삽입은 반복자가 가리키는 위치의 바로 앞에서 이루어진다는 사실을 잊으면 안됩니다.

        이렇게 되면 99는 3의 앞(오른쪽)에 들어가게 되는 것이겠지요. 다음의 그림이 그것을 보여주고 있습니다.
        
        
        
        물론 reverse_iterator를 사용해서 이런 일을 할 수는 없습니다. 그 대신에 우리는 i를 써야 합니다. 앞의 그림에서 본 바, ri는 3을 i는 4를 가리킵니다.
        
        웬지 손발이 맞는 것 같지 않습니까? ri를 사용하여 삽입을 하고자 하는 위치를, 바로 i가 가리키고 있는 것입니다(i의 편에서 보면 i가 기리키는 위치의 앞에 삽입되니까요). 결론 하나가 났지요?
        
        
        • reverse_iterator인 ri로 지정된 위치에 대한 요소 삽입을 흉내내려면 ri.base()를 사용합니다. 요소 삽입이 목적이라면 ri와 ri.base()는 동등하며, ri.base()는 ri에 대해 정확히 대응되는 반복자입니다.

      • 그렇다면, 이제는 요소 삭제를 한 번 생각해 보죠. 99가 들어간 벡터가 아니라 원래의 벡터로 돌아옵시다. ri과 i이 다시 정상 위치(?)로 돌아 왔습니다.

        
        
        ri가 가리키는 요소를 삭제하고 싶지만, 이제는 기점 반복자인 i를 사용할 수는 없습니다. 왜냐하면 i가 가리키는 요소는 ri가 가리키는 녀석과 다르기 때문입니다.
        
        따라서, i의 앞에 있는 요소를 삭제해야 맞습니다.
        
        
        • reverse_iterator인 ri로 지정된 위치에 있는 요소를 삭제하려면 ri.base()의 앞에 있는 위치에서 삭제를 수행해야 합니다. 요소 삭제가 목적이라면 ri와 ri.base()는 동등하지 않으며, ri.base()는 ri에 대응되는 iterator가 아닙니다.
        
        
        실제로 요소 삭제는 다음과 같이 하면 됩니다.
        
        예제 코드 보기
        
        
        

        1. vector<int> v; // 이전과 같이, 1~5를 v에 넣습니다.
        2.  
        3. ...
        4.  
        5. vector<int>::reverse_iterator ri = // 역시 이전과 같이 ri가 3을 가리키게 합니다.
        6. find(v.rbegin(), v.rend(), 3);
        7.  
        8. v.erase(--ri.base()); // ri.base()의 앞에 있는 요소에 대한 삭제를
        9. // 시도합니다. 그러나 vector에 있어서는
        10. // 이 코드가 컴파일되는 경우가 거의 없습니다.
        11.  
        12. // 많은 구현 제품을 살펴볼 때, vector나
        13. // string에 대해서는 대개 이 코드가
        14. // 컴파일되지 않습니다.
        15.  
        16. // 이 경우, iterator (그리고
        17. // const_iterator)는 포인터로
        18. // 구현되어 있기 때문에 ri.base()
        19. // 의 결과도 포인터입니다.
        20.  
        21. // C와 C++의 규정에 의하면, 함수에서
        22. // 반환된 포인터는 수정(modify)할 수
        23. // 없기 때문에, vector나 string의
        24. // iterator가 포인터로 구현된 STL
        25. // 플랫폼에서 --ri.base()이라는
        26. // 표현식은 컴파일이 될 수가 없는
        27. // 것입니다.
        28.  
        29. // 따라서, 이식성 문제까지 고려해서
        30. // 작성하려면 다음과 같이 해야 합니다.
        31.  
        32. ... // 언제나와 같습니다.
        33.  
        34. v.erase((++ri).base()); // ri가 가리키고 있는 요소를 삭제합니다.
        35. // 이 코드는 언제나 컴파일됩니다.
        36.  
        37. // 모든 표준 컨테이너에서 문제없이
        38. // 컴파일되고 동작하기 때문에,
        39. // 역방향 반복자가 가리키는 요소를
        40. // 삭제하는 방법으로 잘 쓰입니다.

        
        
        예제 코드 접기
        
        
        

      • reverse_iterator를 iterator로 바꿀 때(즉, base를 호출할 때)에는, 여러분이 그 반복자로 무엇을 할 것인지를 정확히 계획하고 있어야 합니다. 애써서 바꾼 iterator가 실은 여러분이 원한 것이 아닐 수도 있기 때문이죠.

  29. ★ 문자 단위의 입력에는 istreambuf_iterator의 사용도 적절하다 / 195

      • istream_iterator는 내부적으로 operator<< 함수를 사용합니다. operator<< 함수는 서식화 입력을 사용하는데, 이 말은 여러분이 해야 하는 여러 가지 자질구레한 뒷처리를 알아서 미리 해준다는 뜻입니다.

        operator<<의 호출 시 필요한 전처리와 마무리 동작을 해주는 sentry라는 특수한 iostream 객체를 생성하고 소멸시키는 일, 동작에 영향을 미치는 스트림 플래그를 체크하는 일, 읽는 도중 발생한 에러를 종합적으로 체크하는 일, 문제가 생겼을 때 스트림의 예외 매스크(exception mask)를 체크하여 예외 발생 여부를 결정하는 일 모두를 operator<<가 맡고 있습니다.
        
        이러한 동작들은 여러분이 서식화 입력을 할 때에는 매우 소중하고 값진 것이지만, 그냥 입력 스트림으로부터 다음 문자를 뽑아내는 일만이 목적이라면 엄청난 손실이요 낭비가 아닐 수 없습니다.
        
        istream_iterator 예제 코드 보기
        
        
        

        1. // 어떤 텍스트 파일을 string 객체에
        2. // 복사해야 한다고 가정해 봅시다.
        3.  
        4. // STL적인 생각이라면 다음과 같은
        5. // 코드가 나올 수 있을 것입니다.
        6.  
        7. ifstream inputFile("interestingData.txt");
        8.  
        9. string fileData((istream_iterator<char>(inputFile)), // inputFile 파일을 읽어
        10. istream_iterator<char>()); // fileData에 저장합니다.
        11. // 이것이 정확한 답이 아닌
        12. // 이유에 대해선 아래 설명을
        13. // 읽으시고, 문장 자체에 대한
        14. // 문법사항은 항목 6을 보세요.
        15.  
        16. // 이 방법은 공백(whitespace) 문자를
        17. // string 객체에 복사하지 못합니다.
        18.  
        19. // 왜냐!? istream_iterator는 실제 스트림
        20. // 읽기를 수행할 때에 operator<< 함수를
        21. // 사용하며, 기본적으로 이 연산자 함수는
        22. // 공백 문자를 건너뛰기 때문이죠.
        23.  
        24. // 공백 문자를 건너뛰지 않게 하려면
        25. // 입력 스트림의 skipws 플래그를
        26. // 설정해제(unset)합니다.
        27.  
        28. ifstream inputFile("interestingData.txt");
        29.  
        30. inputFile.unsetf(ios::skipws); // inputFile이 공백 문자를 건너
        31. // 뛰지 못하도록 합니다.
        32.  
        33. string fileData((istream_iterator<char>(inputFile)),
        34. istream_iterator<char>());
        35.  
        36. // 이제 inputFile에서 읽혀지는
        37. // 모든 문자를 fileData에 복사할 수
        38. // 있을 것입니다.
        39.  
        40. // 하지만 앞서 설명드렸듯이 이 코드는
        41. // 비효율적입니다.

        
        
        istream_iterator 예제 코드 접기
        
        
        

      • 여기서 STL의 비장의 무기를 하나 소개하고자 합니다. 바로 istreambuf_iterator 라고 하는 것입니다. 이 반복자는 istream_iterator처럼 쓸 수 있습니다. istreambuf_iterator<char> 객체는 스트림 자체의 버퍼를 직접 건드려서 다음 문자들을 바로 읽어 들입니다.

        이제 앞에 썼던 코드를 istreambuf_iterator를 쓸 수 있도록 고쳐 봐야겠지요? 그냥 istream_iterator를 istreambuf_iterator로 바꾸기만 하면 된답니다.
        
        istreambuf_iterator 예제 코드 보기
        
        
        

        1. ifstream inputFile("interestingData.txt");
        2.  
        3. string fileData((istreambuf_iterator<char>(inputFile)),
        4. istreambuf_iterator<char>());
        5.  
        6. // 여기서는 skipws 플래그를 "설정해제"할
        7. // 필요도 없습니다. istreambuf_iterator는
        8. // 어떤 문자라도 소중히 합니다.
        9.  
        10. // 스트림 버퍼 안에서 다음 위치에 있는
        11. // 문자는 어느 것이든 가지고 오는 것이
        12. // 이 반복자의 특성입니다.

        
        
        istreambuf_iterator 예제 코드 접기
        
        
        istream_iterator와 비교할 때 이 반복자의 속도는 무척 빠릅니다. 간단하게 해본 벤치마크에서 무려 40%나 빨랐습니다. 또한, 더욱 놀라운 사실은 이 속도가 시간이 흐르면 더욱 빨라질 수 있다는 것입니다.
        
        왜냐하면, istreambuf_iterator는 STL 라이브러리 개발자들이 최적화에 거의 신경을 쓰지 않은 컴포넌트이기 때문입니다. 앞으로 최적화가 이루어진다면 더 빨라질 수 있다는 말이죠.

      • istreambuf_iterator의 맛을 한 번 본 분이라면 이에 대응되는 ostreambuf_iterator에도 관심을 주어 보세요. 이 반복자는 문자 단위의 비서식화(unformatted) 출력을 수행하는 스트림 반복자입니다. ostream_iterator의 오버헤드가 없기 때문에 일반적으로 당연히 빠릅니다.

• Chapter 5   알고리즘(Algorithms)

  30. 알고리즘의 데이터 기록 범위(destination range)는 충분히 크게 잡자 / 200

      • 목적지 범위를 지정해야 하는 알고리즘을 사용할 때에는 언제나 이 목적지 범위의 크기를 미리 확보해 두든지, 알고리즘이 실행될 때 자동으로 증가하도록 만들어야 합니다.

      • 알고리즘이 실행될 때 크기를 증가시키려면 삽입 반복자를 사용하십시오. back_inserter, front_inserter, inserter를 호출해서 얻는 반복자 말입니다. ostream_iterator도 여기에 속한다고 볼 수 있습니다.

        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. int transmogrify(int x); // 이 함수는 정수 x를 받아
        3. // 어떤 새로운 값을 만듭니다.
        4. vector<int> values;
        5. ... // values에 데이터를 넣습니다.
        6. vector<int> results; // values 안의 객체에다가
        7. transform(values.begin(), values.end(), // transmogrify를 적용하고,
        8. results.end(), // 그 결과를 results에 추가
        9. transmogrify); // 합니다. 그런데 이 코드에는
        10. // 버그가 있습니다!
        11.  
        12. // 이 예제 코드에서, transform은
        13. // 자신의 함수 처리 결과를 기록할 대상
        14. // 범위의 시작을 results.end()로
        15. // 알고 있습니다.
        16.  
        17. // 따라서 계산 결과를 *results.end()부터
        18. // 차례대로 대입을 하게 됩니다.
        19.  
        20. // 당연히 *results.end()는 물론이고
        21. // 그 뒤에는 객체가 존재하지 않으므로
        22. // 오류가 발생합니다.
        23.  
        24.  
        25. //-----------------------------------------------------------------------------
        26. // 제대로 하려면 다음과 같이 해야
        27. // 합니다.
        28.  
        29. vector<int> results; // values 안의 객체에
        30. transform(values.begin(), values.end(), // 다가 transmogrify를
        31. back_inserter(results), // 적용하고, 그 결과를
        32. transmogrify); // results에 추가
        33. // 합니다.
        34.  
        35. // back_inserter는 내부적으로
        36. // push_back을 사용하여 자동으로
        37. // 컨테이너 내부의 공간을 만들어
        38. // 대입을 수행하도록 합니다.
        39.  
        40. // 즉, back_inserter는
        41. // push_back을 지원하는
        42. // 컨테이너에서만 쓸 수 있습니다.
        43.  
        44. // 즉 표준 시퀸스 컨테이너는 모두
        45. // 다 되지요(vector, string,
        46. // deque, list 등).
        47.  
        48.  
        49. //-----------------------------------------------------------------------------
        50. // 컨테이너의 앞에 처리 결과를 추가하고
        51. // 싶으면 front_inserter를 대신
        52. // 사용합니다.
        53.  
        54. ... // 여느 때와 같습니다.
        55. list<int> results; // results가 이제는 list입니다.
        56. transform(values.begin(), values.end(), // transform의 결과를
        57. front_inserter(results), // results의 앞에 넣습니다.
        58. transmogrify); // 순서가 거꾸로입니다.
        59.  
        60. // front_inserter는 내부적으로
        61. // push_front를 사용하기 때문에
        62. // push_front를 지원하는 컨테이너에서만
        63. // 쓸 수 있습니다(deque나 list).
        64.  
        65.  
        66. //-----------------------------------------------------------------------------
        67. // results의 앞에다가 transform의
        68. // 결과를 추가하고 싶은데 values에
        69. // 원래 들어 있던 객체들과 같은 순서를
        70. // 유지하고 싶을 때에는 values를
        71. // 뒤집으면 됩니다.
        72.  
        73. list<int> results; // 여느 때와 같습니다.
        74. transform(values.rbegin(), values.rend(), // transform의 결과를
        75. front_inserter(results), // results의 앞에 넣
        76. transmogrify); // 되, 원래의 객체 순서
        77. // 를 유지합니다.
        78.  
        79.  
        80. //-----------------------------------------------------------------------------
        81. // 임의의 위치를 지정하여 결과를 넣는
        82. // 방법도 있습니다. 바로 inserter입니다.
        83.  
        84. vector<int> results; // 여느 때와 같으나, 단지
        85. ... // transform을 호출하기 전에
        86. // results에 데이터가 몇 개
        87. // 들어 있다는 점이 다릅니다.
        88.  
        89. transform(values.begin(), values.end(), // transmogrify를
        90. inserter(results, results.begin() + results.size() / 2), // 호출한
        91. transmogrify); // 결과를
        92. // results의
        93. // 중간에
        94. // 삽입합니다.
        95.  

        
        
        예제 코드 접기
        
        
        

      • back_inserter나 front_inserter나 inserter나, 어떤 것을 쓰든지 간에 목적지 범위에 대한 결과 요소 삽입은 한 번에 한 개의 객체에 대해서만 이루어집니다.

        이와 관련된 이야기를 항목 5에서 하고 있으니까 참고하세요. 하지만 항목 5에서 제시한 해결책(범위 단위의 멤버 함수를 호출하는 것)을 이번에는 쓸 수 없습니다.
        
        transform은 어쨌든 한 번에 하나의 값을 목적지 범위에 저장하기 때문에, 이떻게 바꿀 수 있는 방법은 없습니다.

      • 여러분이 삽입하고자 하는 컨테이너가 vector 혹은 string 이라면 항목 14에서 이야기한 방법을 따라 오버헤드를 최소화할 수는 있습니다. reserve를 호출하는 것이죠. 요소 삽입 시 원래 있던 요소들이 한 칸씩 밀려나는 비용은 여전히 감수해야 하겠지만 말입니다.

        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. int transmogrify(int x); // 여느 때와 같습니다.
        3.  
        4. vector<int> values; // 여느 때와 같습니다.
        5. vector<int> results;
        6. ...
        7. results.reserve(results.size() + values.size()); // results의 용량을
        8. // 최소한 values.size()
        9. // 만큼은 담을 수 있게
        10. // 확보합니다.
        11.  
        12. transform(values.begin(), values.end(), // 모두 같으나,
        13. inserter(results, results.begin() + results.size() / 2), // results는
        14. transmogrify); // 메모리 재할당을
        15. // 할 필요가
        16. // 없습니다.
        17.  
        18.  
        19. //-----------------------------------------------------------------------------
        20. // reserve 함수는 컨테이너의 용량(capacity)
        21. // 만을 증가시킨다는 사실을 주의하세요.
        22. // 컨테이너의 요소 크기는 변하지 않습니다.
        23.  
        24. // 즉 reserve를 호출한 뒤에도 vector나
        25. // string 등에 새 요소를 추가하는
        26. // 알고리즘에는 여전히 앞에서 이야기한
        27. // 삽입 반복자를 써야 합니다.
        28.  
        29. // 잘못된 예시를 다시 보여 드리겠습니다.
        30.  
        31. vector<int> values; // 여느 때와 같습니다.
        32. vector<int> results;
        33. ...
        34. results.reserve(results.size() + values.size()); // 여느 때와 같습니다.
        35.  
        36. transform(values.begin(), values.end(), // transmogrify의 호출 결과를
        37. results.end(), // 초기화되지 않은 메모리
        38. transmogrify); // 에다가 저장하려 합니다. 어떤
        39. // 결과가 일어날지 모릅니다!
        40.  
        41. // 대개 이 코드는 런타임에서 실패합니다.
        42. // 아직 초기화되지 않은 객체(생성자가
        43. // 호출되지 않은 메모리 덩어리)에다가
        44. // 대입을 하려고 시도했기 때문이지요.
        45.  
        46. // 설령 제대로 작동했다고 하더라도
        47. // results는 transform이 초기화되지
        48. // 않은 메모리에다가 "생성한" "객체"의
        49. // 개수를 알 수가 없습니다.
        50.  
        51. // 아마 results의 요소 개수는
        52. // transform이 불리기 전과 다를
        53. // 바 없을 것입니다.
        54.  
        55. // 그리고 results.end()가 나타내는
        56. // 반복자 역시 transform이 불린
        57. // 것과 관계없이 여전히 똑같은 곳을
        58. // 가리키고 있을 것입니다.
        59.  
        60. // 즉, 이 예제를 제대로 만드려면
        61. // reserve와 삽입 반복자를 함께
        62. // 사용해야 합니다.
        63.  
        64. vector<int> values; // 여느 때와 같습니다.
        65. vector<int> results;
        66. ...
        67. results.reserve(results.size() + values.size()); // 여느 때와 같습니다.
        68.  
        69. transform(values.begin(), values.end(), // transform의 결과를
        70. back_inserter(results), // results의 뒤에 저장
        71. transmogrify); // 합니다. 이 과정중에
        72. // 메모리를 재할당할
        73. // 필요가 없습니다.
        74.  
        75.  
        76. //-----------------------------------------------------------------------------
        77. // 어쩌다 보면 원래 들어 있던 값에다가
        78. // 덮어 쓰고 싶을 때도 있습니다.
        79.  
        80. // 이런 경우에는 삽입 반복자가 필요
        81. // 없으나 이번 항목에서 배운 내용을
        82. // 준수하여, 목적지 범위를 충분히
        83. // 키워 놓아야 합니다.
        84.  
        85. // 예를 들어, transform을 써서 그 결과를
        86. // results 안에 있는 요소에 덮어쓰고
        87. // 싶다고 가정해 보죠.
        88.  
        89. // results의 요소 개수가 최소한 values의
        90. // 요소 개수 정도는 된다고 가정하면
        91. // 이 작업은 상당히 쉽습니다.
        92.  
        93. // 잘 안될 때에는 resize를 써서 크기를
        94. // 확보해 두면 됩니다.
        95.  
        96. vector<int> values;
        97. vector<int> results;
        98. ...
        99. if (results.size() < values.size()) { // results의 크기를 최소한
        100. results.resize(values.size()); // values의 크기 만큼 맞춥니다.
        101. }
        102. transform(values.begin(), values.end(), // values.size() 만큼의
        103. results.begin(), // results 요소에 덮어
        104. transmogrify); // 씁니다.
        105.  
        106. // 아니면, results를 clear한 후에
        107. // 삽입 반복자를 통한 원래의
        108. // 방법을 쓸 수도 있습니다.
        109.  
        110. ...
        111. results.clear(); // results에 들어 있는
        112. // 요소를 모두 없앱니다.
        113.  
        114. results.reserve(values.size()); // 충분한 공간을 확보합니다.
        115. transform(values.begin(), values.end(), // transform의 처리 결과를
        116. back_inserter(results), // results에 넣습니다.
        117. transmogrify);
        118.  

        
        
        예제 코드 접기
        
        
        

  31. ★ 정렬시의 선택 사항들을 제대로 파악해 놓자 / 206

      • vector, string, deque, 혹은 C++ 배열에 대해 전체 정렬을 수행할 필요가 있을 때에는 sort나 stable_sort를 사용합니다.

        sort는 정렬 전 동등한 값들간 순서가 정렬 후에 유지되지 않지만, stable_sort는 유지됩니다.

      • vector, string, deque, 혹은 C++ 배열에 대해 상위 n개의 요소만 순서에 맞추어 뽑아내고 싶다면 partial_sort를 사용합니다.

        partial_sort를 사용하면 상위 n개의 요소만 정렬을 수행할 수 있습니다. 상위 n개에 들지 못하는 요소들은 정렬되지 않은 채 남아있게 됩니다. 이때 동등한 값들간 순서는 유지되지 않습니다.
        
        partial_sort 예제 코드 보기
        
        
        

        1. bool qualityCompare(const Widget& lhs, const Widget& rhs)
        2. {
        3. // lhs의 품질이 rhs의 품질보다 좋으면 true를 반환합니다.
        4. }
        5. ...
        6. partial_sort(widgets.begin(), // 가장 뛰어난 20개의
        7. widgets.begin() + 20, // 요소를 widgets의 앞부터
        8. widgets.end(), // 순서대로 놓습니다.
        9. qualityCompare);
        10. // Widget 객체를 사용합니다.
        11.  

        
        
        partial_sort 예제 코드 접기
        
        
        

      • vector, string, deque, 혹은 C++ 배열에 대해 상위 n개의 요소를 뽑되 순서는 고려할 필요가 없다면 nth_element가 적합합니다.

        nth_element는 자신이 처리할 범위 내의 객체를 정렬하되, n째 위치(여러분이 지정한)에 있는 요소만 전체 정렬된 상태에 있게만 합니다. 이 알고리즘 역시 동등한 값들간 순서는 유지되지 않습니다.
        
        게다가 이 알고리즘이 복귀하고 나면 위치 n의 앞에 있는 요소들은 n째 위치에 있는 요소보다 정렬 순서에서 뒤에 오지 않고, 위치 n의 뒤에 있는 요소들은 n째 위치에 있는 요소보다 정렬 순서에서 앞에 오지 않습니다.
        
        즉, nth_element는 핵심적으로 partial_sort와 동일합니다. 다른 점이 있다면 partial_sort는 n 번째의 앞부분을 정렬하지만, nth_element는 그러지 않는다는 점입니다.
        
        이런 점을 이용하면 범위 내에서 상위 n개의 요소를 찾아 내는(순서에 상관없이) 것 외에, 주어진 범위 내의 중앙값(median)을 찾아 내거나 특정한 백분위(percentile) 위치에 있는 값을 찾아내는 데에도 이 알고리즘을 쓸 수 있습니다.
        
        nth_element 예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. bool qualityCompare(const Widget& lhs, const Widget& rhs)
        3. {
        4. // lhs의 품질이 rhs의 품질보다 좋으면 true를 반환합니다.
        5. }
        6. ...
        7. nth_element(widgets.begin(), // 상위 20개의 요소를
        8. widgets.begin() + 20, // widgets의 앞에 놓습니다.
        9. widgets.end(), // 20개 요소 각각의 정렬
        10. qualityCompare); // 순서는 신경 쓰지 않고요.
        11.  
        12.  
        13. //-----------------------------------------------------------------------------
        14. vector<Widget>::iterator begin(widgets.begin()); // widgets의 begin과
        15. vector<Widget>::iterator end(widgets.end()); // end 반복자에 대해
        16. // 편의적으로 정의한 변수
        17.  
        18. vector<Widget>::iterator goalPosition; // 원하는 Widget
        19. // 객체의 위치를
        20. // 가리키는 iter
        21.  
        22. // 아래의 코드는 중앙값을 가진
        23. // Widget 객체를 찾습니다
        24. // (정렬된 벡터를 전제 조건으로 합니다).
        25.  
        26. goalPosition = begin + widgets.size() / 2; // 정렬된 벡터에서
        27. // 정 중앙 위치에 있는
        28. // Widget을 가리킵니다.
        29.  
        30. nth_element(begin, goalPosition, end, // widgets에서 중앙값을
        31. qualityCompare); // 찾습니다.
        32.  
        33. ... // goalPosition은 중앙값을
        34. // 가지고 있는 Widget
        35. // 객체를 가리킵니다.
        36.  
        37. // 아래에 있는 코드는 75째 백분위 위치에
        38. // 있는 Widget 객체를 찾습니다.
        39.  
        40. vector<Widget>::size_type goalOffset = // 원하는 Widget 객체가
        41. 0.25 * widgets.size(); // widgets의 처음을 기준으로
        42. // 얼만큼 떨어져 있는지 계산합니다.
        43.  
        44. nth_element(begin, begin + goalOffset, end, // 75째 백분위 위치에 해당하는
        45. qualityCompare); // 값을 가진 요소를 찾습니다.
        46.  
        47. ... // goalPosition는 이제
        48. // 75째 백분위 값을 가진
        49. // 요소를 가리키고 있습니다.
        50.  

        
        
        nth_element 예제 코드 접기
        
        
        

      • 표준 시퀸스 컨테이너가 있고 이 컨테이너의 요소들을 어떤 기준에 만족하는 것들과 그렇지 않은 것들을 모아 구분하고 싶다면 partition 혹은 stable_partition을 찾으십시오.

        partition은 수행 전 동등한 값들간 순서가 정렬 후에 유지되지 않지만, stable_partition은 유지됩니다.
        
        이 알고리즘은 주어진 범위에 있는 요소의 위치를 재배열하는데, 어떤 기준에 맞는 요소는 모두 그 범위의 앞부분에 몰아 놓습니다.
        
        partition 예제 코드 보기
        
        
        

        1. bool hasAcceptableQuality(const Widget& w)
        2. {
        3. // Widget 객체의 등급이 2등급 이상인지의 여부를 반환합니다.
        4. }
        5.  
        6. vector<Widget>::iterator goodEnd = // hasAcceptableQuality를 만족하는
        7. partition(widgets.begin(), // 모든 Widget 객체는 widgets의
        8. widgets.end(), // 앞으로 몰아 놓고, 만족하지 않는
        9. hasAcceptableQuality); // Widget 객체 중 처음 것을 가리키는
        10. // 반복자를 반환합니다.
        11.  
        12. // 이 코드가 실행되고 난 후에는
        13. // widgets.begin()과 goodEnd
        14. // 사이의 범위에는 1등급과 2등급의
        15. // Widget 객체가 모두 들어
        16. // 있는 상태가 되며, goodEnd와
        17. // widgets.end() 사이의
        18. // 범위에는 3등급 이하의 Widget
        19. // 객체가 모두 들어 있게 됩니다.

        
        
        partition 예제 코드 접기
        
        
        

      • 사용하고 있는 컨테이너가 list인 경우에, partition과 stable_partition은 직접 사용할 수 있으며 sort와 stable_sort 알고리즘 대신에 list::sort 멤버 함수를 사용할 수 있습니다. 만일 partial_sort나 nth_element의 기능이 필요하다면 간접적인 방법 밖에는 대안이 없지만 아래에 나온 방법들 중 하나를 경우에 따라 적절히 선택해서 구현하면 됩니다.

        list::sort 멤버 함수는 기능상 stable_sort와 동일합니다.
        
        list에서 partial_sort나 nth_element를 꼭 사용하고자 할때 쓸 수 있는 방법은 무궁무진하지만, 여기서는 3가지 방법을 소개해 드리겠습니다.
        
        
        • list의 요소를 임의 접근 반복자를 지원하는 컨테이너에 복사한 후, 이 컨테이너에 원하는 알고리즘을 적용하는 것입니다.
        • list::iterator의 컨테이너를 하나 만들고, 이 컨테이너에 알고리즘을 적용한 후에 각 반복자를 통해 리스트 요소 데이터를 액세스하는 것입니다.
        • 반복자를 정렬해 놓은 컨테이너의 정보를 써서, 원하는 위치에 리스트의 요소 데이터를 splice하는 것입니다.

      • 작업량이 많은 알고리즘이 시간이 오래 걸리며, 순서를 유지하며 동작하는 알고리즘이 그렇지 않은 것보다 느립니다.

        이번 항목에서 공부해 본 알고리즘을 리소스(시간과 메모리)를 적게 먹는 순서대로 "정렬"해 볼 수 있을 것입니다.
        
        
        1. partition
        2. stable_partition
        3. nth_element
        4. partial_sort
        5. sort
        6. stable_sort
        
        
        정렬 알고리즘을 선택하는 방법의 핵심은 여러분이 하고자 하는 일을 제대로 파악하는 데에 있습니다. 수행 성능이 결코 우선 순위가 되지 못한다는 것입니다.
        
        필요한 일만을 하는 알고리즘을 정확히 골랐다면(sort 대신에 partition을 쓴다든지), 그 코드는 명확성과 효율을 모두 지니게 될 것입니다.

  32. 요소를 정말로 제거하고자 한다면 remove 류의 알고리즘에는 꼭 erase를 붙여 사용하자 / 213

      • remove는 어느것도 "진짜로" 없애지 않습니다. 없앨 수 없기 때문입니다. remove 알고리즘은 단지 "제거되지 않는" 요소를 범위의 앞쪽에 가져다 놓는 일을 할 뿐입니다(원래의 상대적인 위치는 그대로 보존하구요). 그리고 "제거되지 않은" 요소 중 마지막 것의 바로 뒤를 가리키는 반복자를 반환하는 것으로 자신의 동작을 마칩니다.

        remove 알고리즘은 자신이 조작할 데이터 요소의 범위를 나타내는 한 쌍의 반복자를 받아들일 뿐, 컨테이너를 받아들이지 않기 때문에, 어떤 컨테이너가 요소를 가지고 있는지는 알 방법이 없습니다. 또한 컨테이너의 정체를 밝혀 내는 것 자체도 불가능합니다.
        
        어떤 컨테이너에서 특정 요소를 제거하는 방법은 그 컨테이너의 멤버 함수(대개 erase라는 이름을 가지고 있죠. list의 경우는 이름이 다릅니다)를 호출하는 것 뿐입니다.
        
        이렇다 보니, remove 알고리즘만으로 컨테이너에서 요소를 제거 하는 것은 꿈만 같은 일일 수밖에요. 이런 사실은 remove 알고리즘을 호출한 후에도 컨테이너에 들어 있는 요소의 개수가 변하지 않는다는 황당한 현상을 어느 정도 뒷받침해 줍니다.
        
        예제 코드 보기
        
        
        

        1. vector<int> v; // vector<int>를 하나 만들고 여기에
        2. v.reserve(10); // 1~10을 넣습니다(reserve를 호출하는
        3. for (int i = 1; i <= 10; ++i) { // 이유에 대해서는 항목 14를 참고하세요).
        4. v.push_back(i);
        5. }
        6. cout << v.size(); // 10을 출력합니다.
        7. v[3] = v[5] = v[9] = 99; // 3개의 요소를 99로 세팅합니다.
        8. remove(v.begin(), v.end(), 99); // 99란 값을 가진 요소를 모두 remove 합니다.
        9. cout << v.size(); // 앗, 여전히 10입니다!
        10.  
        11. // remove 알고리즘이 호출되기 직전의
        12. // 상황을 시각화 해 보았습니다.
        13.  
        14. 
        15.  
        16. // 그리고 다음과 같이 remove의 반환
        17. // 값을 newEnd라고 불리는 새
        18. // 반복자에 저장하면,
        19.  
        20. vector<int>::iterator newEnd(remove(v.begin(), v.end(), 99));
        21.  
        22. // v는 이런 모습이 됩니다.
        23.  
        24. 

        
        
        예제 코드 접기
        
        
        

      • 큰 오해가 없었다면, "제거되지 않은" 요소는 v.begin()와, remove가 반환한 반복자(newEnd) 사이에 들어 있고, "제거된" 요소는 newEnd와 v.end() 사이에 있을 것이라고 보는 것이 논리적일 테지요. 그런데, 문제는 그렇지가 않다는 것입니다!

        "제거된" 요소는 벡터에 더 이상 남아 있을 필요가 없습니다. 그래서 remove는 제거된 요소를 주어진 범위의 끝 부분에 옮기는 식으로 동작하지 않습니다.
        
        표준안에서는 굳이 요구하고 있지 않으나, 새로운 논리적 끝의 뒷부분에 있던 요소들은 대개 원래의 값을 유지하고 있습니다.
        
        즉 위의 예제 코드 내의 두 번째 이미지의 "?" 부분은 다음과 같은 값으로 채워져 있을 것입니다.
        
        
        
        이러한 양상은 모든 라이브러리에서 동일하더군요.
        
        여러분은 remove에게 값을 제거해 달라고 요청했지, 제거된 값을 특별한 장소에 따로 모아 달라고는 하지 않았습니다. 그렇기 때문에 제거된 값들이 벡터의 뒷쪽 끝에 모여 있으리라는 기대를 하면 안 됩니다.
        
        만약 "제거된" 요소를 뒷쪽에 모으고 싶다면 partition(항목 31 참조)을 사용하세요.
        
        이런 식으로 값이 남아 있는 이유는, remove가 내부적으로 주어진 범위를 처음부터 끝까지 훑어 가면서, "제거될" 요소의 위치에다가 그 뒤에 있는 "그대로 유지될" 요소의 값을 덮어 쓰는(대입) 식으로 동작하기 때문입니다.

      • remove를 수행해서 얻어낸 주어진 범위의 "새로운 논리적 끝"부터 그 범위의 진짜 끝 사이에 있는 요소들은, erase를 써서 "진짜"로 제거하면 됩니다.

        예제 코드 보기
        
        
        

        1. vector<int> v; // 예전과 같습니다.
        2. ...
        3. v.erase(remove(v.begin(), v.end(), 99), v.end()); // 99란 값을 가진
        4. // 요소를 진짜로 없앱니다.
        5.  
        6. cout << v.size(); // 이제 7이 나옵니다.
        7.  
        8. // remove의 반환 값을 erase의 첫 번째
        9. // 매개 변수로 넘기는 식은 거의
        10. // 영어 숙어처럼 쓰이는 방법입니다.

        
        
        예제 코드 접기
        
        
        

      • list에서는 remove와 erase가 하나로 합쳐진 remove라는 멤버 함수가 제공되고 있습니다. STL에서 컨테이너의 요소를 없애는 역할을 하는 함수로 remove라는 이름을 가진 것은 이것 하나 뿐입니다.

        예제 코드 보기
        
        
        

        1. list<int> li; // 리스트를 만듭니다.
        2.  
        3. ... // 값 몇 개를 넣습니다.
        4.  
        5. li.remove(99); // 99란 값을 가진 요소를 모두 없앱니다.
        6. // 이 함수는 진짜로 요소를 없애기 때문에
        7. // 요소 개수가 변합니다.
        8.  

        
        
        예제 코드 접기
        
        
        리스트의 경우에는 erase와 remove를 함께 사용하는 것 보다, list::remove를 사용하는 것이 훨씬 더 효율이 좋습니다.

      • remove와 비슷한 알고리즘 두 가지가 더 있는데, 각각 remove_if와 unique입니다. 이 두 알고리즘 역시 remove와 비슷한 이유로 erase와 함께 사용해야 합니다.

        한면, unique는 list의 경우 list::unique를 제공하고 있다는 점에서도 remove와 흡사합니다.
        
        list::unique는 인접한 중복 요소를 진짜로 없앱니다. 그리고 erase와 unique를 함께 쓰는 것보다 list::unique가 더욱 효율적이라는 점도 똑같지요.

  33. remove와 비슷한 알고리즘을 포인터의 컨테이너에 적용할 때에는 각별히 조심하자 / 219

      • 동적으로 할당된 Widget 객체를 한무더기 만들고 이 객체들을 벡터에 넣어놓았다고 합시다. 이 중에서 품질 보증이 되지 않은 객체들을 제거하려고 합니다. 이 때 remove(혹은 그 비슷한 알고리즘)와 erase를 함께 사용하여 제거하려는 생각이 자연스럽게 들었을 것입니다. 하지만 항목 32에서 보았듯이, remove와 비슷한 알고리즘들은 "제거된" 객체들을 따로 모아놓지 않습니다. 즉, 이 경우에는 "제거된" 포인터들을 잃어버려 메모리 누수로 이어질 수 있습니다.

        자원이 새는 예제 코드 보기
        
        
        

        1. class Widget {
        2. public:
        3. ...
        4. bool isCertified(void) const; // 이 Widget 객체의 품질이 확실한지?
        5. ...
        6. };
        7.  
        8. vector<Widget*> v; // 벡터를 하나 생성하고 이것을
        9. ... // 동적으로 할당된 Widget 객체
        10. v.push_back(new Widget); // 의 포인터로 채웁니다.
        11. ...
        12.  
        13. v.erase(remove_if(v.begin(), v.end(), // 품질 보증이 되지 않은
        14. not1(mem_fun(&Widget::isCertified))), // Widget 객체의 포인터를
        15. v.end()); // 지웁니다. mem_fun
        16. // 을 사용한 것에
        17. // 대해서는 항목 41을
        18. // 참고하세요.
        19.  
        20. // 항목 7에서 나온 것처럼, 컨테이너에
        21. // 들어 있는 포인터를 그냥 없애면
        22. // 그 포인터가 가리키는 것을 삭제할
        23. // 수 없습니다.
        24.  
        25. // 즉, erase가 호출되는 바로 그 시점이
        26. // 리소스가 새어 나갈 완벽 찬스가 됩니다.
        27.  
        28. // 하지만, 그 전에 우선 걱정해야 할 것이
        29. // remove_if 입니다.
        30.  
        31. // remove_if가 호출되기 전의 상황을
        32. // 가정해 봅시다.
        33.  
        34. // v가 아래 그림처럼 되어 있고,
        35. // 여기서 품질 보증이 되지 않은
        36. // Widget을 "uncertified"로
        37. // 표시해 두었습니다.
        38.  
        39. 
        40.  
        41. // remove_if가 호출된 후의 v는
        42. // 대개 이러한 모양이 되겠지요.
        43.  
        44. 
        45.  
        46. // 이렇게 v의 모양이 변하는 이유에
        47. // 대해서는 항목 32를 참고하세요.
        48.  
        49. // 이제 리소스 누수의 원인이 여실히
        50. // 드러났습니다.
        51.  
        52. // Widget 객체 B와 C를 가리키고
        53. // 있었지만 "제거되는" 포인터 자리에,
        54. // 그 뒤에 있는 "제거되지 않는"
        55. // 포인터의 값이 덮어 쓰여진 것입니다.
        56.  
        57. // Widget 객체 B와 C는 자신을
        58. // 가리키던 포인터마저 잃었기 때문에
        59. // delete되지도 않습니다.
        60.  
        61. // remove_if와 erase가 자신의
        62. // 실행을 끝내고 복귀한 후에는
        63. // 다음과 같은 지경에 이르게 됩니다.
        64.  
        65. 
        66.  
        67. // 그 결과, Widget 객체 B와 C가
        68. // 차지하고 있는 메모리가 샙니다.
        69.  

        
        
        자원이 새는 예제 코드 접기
        
        
        많은 경우에 remove와 비슷한 알고리즘(remove_if나 unique) 대신에, partition(항목 31 참조)을 사용할 수 있을 것입니다.

      • 부득이한 사정이 있어서 동적 할당 포인터의 컨테이너에 remove를 사용할 수 밖에 없는 경우라면, erase-remove 합성문을 호출하기 전에 포인터를 delete하고 널로 세팅하고 나서, 컨테이너 내의 모든 널 포인터를 없애는 식으로 만듭니다.

        예제 코드 보기
        
        
        

        1. void delAndNullifyUncertified(Widget*& pWidget) // *pWidget이 가리키는 Widget
        2. { // 객체가 보증이 안된 것이면
        3. if (!pWidget->isCertified()) { // 메모리를 해제하고
        4. delete pWidget; // 이 포인터를 널로 세팅합니다.
        5. pWidget = 0;
        6. }
        7. }
        8.  
        9. for_each(v.begin(), v.end(), // 보증되지 않은 Widget 객체
        10. delAndNullifyUncertified); // 에 대한 모든 포인터를
        11. // delete하고 널로 세팅합니다.
        12.  
        13. v.erase(remove(v.begin(), v.end(), // v에서는 널 포인터를
        14. static_cast<Widget*>(0)), // 제거합니다. 0은 포인터로
        15. v.end()); // 캐스팅되기 때문에,
        16. // C++는 remove의 셋째
        17. // 매개 변수의 타입을
        18. // 정확히 예측합니다.
        19.  
        20. // 물론, 이 코드는 벡터가 불필요한
        21. // 널 포인터는 가지고 있지 않는다는
        22. // 가정 하에 만든 것입니다.
        23.  
        24. // 만에 하나 그렇지 않다면 직접
        25. // 루프를 작성해서 포인터를 지워야
        26. // 할 것입니다.
        27.  
        28. // 컨테이너 내부를 횡단하면서 직접
        29. // 요소를 지우는 일은 몇 가지 미묘한
        30. // 걸림돌을 가지고 있어서, 혹시
        31. // 불안하신 분은 항목 9를 다시
        32. // 잘 읽어 보는 것도 좋겠습니다.

        
        
        예제 코드 접기
        
        
        

      • 포인터의 컨테이너 대신에 참조 카운팅 기능을 가지고 있는 스마트 포인터의 컨테이너를 사용하겠다고 생각하셨다면, 이번 항목에서 이야기한 remove의 동작과 관련된 까다로운 사항이 자연히 사전 봉쇄가 되므로 erase-remove 합성문을 바로 사용할 수 있습니다.

        스마트 포인터를 사용한 예제 코드 보기
        
        
        

        1. template <typename T> // RCSP = "Reference Counting
        2. class RCSP { ... }; // Smart Pointer"의 준말
        3.  
        4. typedef RCSP<Widget> RCSPW; // RCSPW = "RCSP to Widget"의 준말
        5.  
        6. vector<RCSPW> v; // 벡터를 하나 만들고 여기에
        7. ... // 동적으로 할당된 Widget 객체에 대한
        8. v.push_back(RCSPW(new Widget)); // 포인터를 채웁니다.
        9. ...
        10. v.erase(remove_if(v.begin(), v.end(), // 보증이 안된
        11. not1(mem_fun(&Widget::isCertified))), // Widget 객체의
        12. v.end()); // 포인터를 지웁니다.
        13. // 리소스 누수가
        14. // 전혀 없습니다.
        15.  
        16. // 물론 이렇게 만드시려면 여러분이
        17. // 사용하시는 스마트 포인터 타입
        18. // (이를테면 RCSP<Widget>)을
        19. // C++ 내장 포인터 타입(즉,
        20. // Widget*)으로 변환해 주는
        21. // 과정이 자동으로 수행되어야 합니다.
        22.  
        23. // 왜냐하면 컨테이너엔 스마트 포인터가
        24. // 들어 있지만, 호출되는 멤버 함수
        25. // (즉, Widget::isCertified)는
        26. // 내장 포인터를 요구하기 때문입니다.

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

  34. 정렬된 범위에 대해 동작하는 알고리즘이 어떤 것들인지 파악해 두자 / 224

      • 정렬된 범위에 대해 동작하는 알고리즘 리스트를 먼저 한 번 봅시다.

        • binary_search, lower_bound, upper_bound, equal_range
          
          
        • set_union, set_intersection, set_difference, set_symmetric_difference
          
          
        • merge, inplace_merge
          
          
        • includes
          
          
        
        
        추가로, 다음의 알고리즘은 대개 정렬된 범위에 대해 쓰이긴 하지만 꼭 그렇지 않아도 되는 것들입니다.
        
        
        • unique, unique_copy
          
          
        
        
        "정렬된 범위"란 말의 정의에 대해서는 조금 있다가 알아 보겠습니다.

      • binary_search, lower_bound, upper_bound, equal_range(항목 45 참조) 등의 탐색 알고리즘은 반드시 정렬된 범위가 필요합니다. 내부적으로 이진 탐색을 사용해서 값을 찾거든요.

        이 알고리즘들은 범위 내의 데이터들을 미리 정렬해 두어야 한다는 전제조건만 지키면, 로그 시간 안에 값을 찾아 줍니다.
        
        사실 임의 접근 반복자를 지원하지 않는 컨테이너에 대해서는 로그 시간의 탐색 효율을 보장해주지 못합니다.
        
        임의 접근 반복자보다 못한 반복자(이를테면 양방향 반복자)를 쓰게 되면 비교 동작은 로그 시간 안에 일어나지만, 실행은 선형 시간 안에 끝납니다.
        
        왜냐하면 양방향 반복자는 "반복자의 산술연산"이 되지 않아서, 한 곳에서 다른 곳으로 이동할 때 한 번에 한 칸씩밖에 이동할 수 없으니까요.

      • set_union, set_intersection, set_difference, set_symmetric_difference의 알고리즘 4총사는 이름 그대로 집합(set) 조작 알고리즘이며 선형 시간의 효율을 보입니다. 만약 데이터가 정렬되지 않은 경우에는 선형 시간 안에 동작하는 것이 불가능해 집니다(동작이 되기는 합니다).

      • merge와 inplace_merge 알고리즘은 병합 정렬(merge sort) 알고리즘의 첫 단계(pass)와 똑같은 일을 한다고 보면 됩니다. 즉, 두 개의 정렬된 범위를 받아 이것을 합쳐 정렬된 하나의 범위를 만드는 것이죠.

        이 알고리즘들은 선형 시간 안에 완료되며, 원래의 두 범위 중 하나라도 정렬되어 있지 않으면 동작하지 않습니다.

      • 정렬된 범위를 기반으로 동작하는 마지막 알고리즘은 includes입니다. 이 알고리즘은 어떤 범위 안에 우리가 원하는 값이 들어 있는지의 여부를 알아볼 때 사용합니다. 이 알고리즘은 자신이 받아들이는 범위내의 데이터가 정렬되어 있음을 가정하고 동작하기 때문에 선형 시간의 효율을 보입니다. 이렇게 되어 있지 않으면 수행속도가 느려집니다.

      • 지금까지 이야기한 알고리즘과 달리, unique와 unique_copy는 범위가 정렬되지 않은 상태에서도 잘 동작합니다.

        단 여기서 unique의 동작 원리를 설명해 놓은 표준안을 한 번 보시죠(이텔릭체로 된 부분은 제 생각을 끼워넣은 것입니다).
        
        unique는 연속으로 이어진 동일한 요소들(consecutive group of equal elements) 중에서 첫 번째 것만을 남기고 다 없앱니다.
        
        쉽게 말해, 어떤 범위에 unique를 써서 중복된 요소들을 하나만 남기고 모두 없애려면 우선 중복되어 있는 값들을 줄줄이 이어지게 만들어야 합니다. 정렬 이외의 방법은 시간 낭비라고 말씀드릴 수 있습니다.
        
        참고로 unique는 범위 내의 중복된 요소를 지울 때 remove 처럼 동작합니다. 이에 대한 자세한 내용은 항목 32와 33을 참고하세요.

      • STL을 사용할 때에는 반드시 정렬에 관련된 정보를 일관적으로 제시해 줄 것을 금과옥조로 삼아야 합니다. 정렬된 범위를 넘겨 실행하는 알고리즘이 또 비교 함수까지 받아들인다고 하면, 이 비교 함수는 그 범위를 정렬할 때 사용한 기준에 맞게 동작해야 한다는 것이죠.

        자, 이제 "정렬할 범위(range to be sorted)"가 무슨 뜻인지 자세히 알아볼 때가 왔습니다. STL에서는 정렬에 사용할 비교 함수를 지정할 수 있도록 되어 있기 때문에, 여러 가지 범위를 정렬하는 방법이 가지각색입니다.
        
        예를 들어 int값을 가지고 있는 범위는 오름차순으로 정렬되었을 수도 있고 내림차순으로 정렬되었을 수도 있습니다.
        
        이때, 내림차순으로 정렬되어 있는 데이터에서 binary_search 알고리즘을 이용하여 어떤 값을 찾는다고 가정하면, binary_search에게 데이터가 내림차순으로 정렬되어 있다는 사실을 알려줘야 합니다.
        
        예제 코드 보기
        
        
        

        1. // 프로그래머로서 별로 만나고 싶지
        2. // 않은 경우를 하나 들어보겠습니다.
        3.  
        4. vector<int> v; // 벡터를 하나 만들고,
        5.  
        6. ... // 여기에 데이터를 넣고,
        7.  
        8. sort(v.begin(), v.end(), greater<int>()); // 내림차순으로 정렬합니다.
        9.  
        10. ... // 이 벡터로 어떤 일을 합니다
        11. // (바꾸지는 않습니다).
        12.  
        13. bool a5Exists = // 벡터에서 5란 값을 찾습니다.
        14. binary_search(v.begin(), v.end(), 5); // 그런데, 벡터가 오름차순으로
        15. // 정렬되어 있을 것으로 가정했습니다!
        16.  
        17. // binary_search 알고리즘은 기본적으로
        18. // 범위 내의 요소들이 "<"에 맞추어
        19. // 정렬되어 있다고 가정하고 있습니다
        20. // (즉 오름차순으로 정렬되어 있다고
        21. // 가정하고 있습니다).
        22.  
        23. // 하지만 위의 코드에서 벡터는
        24. // 내림차순으로 정렬이 되어 있지요.
        25.  
        26. // 당연히 엉뚱한 결과가 도출됩니다.
        27.  
        28. // 이 코드를 제대로 동작하게 하려면
        29. // binary_search에게 sort가 사용했던
        30. // 동일한 비교함수를 사용하라고
        31. // 알려 줘야 합니다.
        32.  
        33. bool a5Exists = // 비교 함수로서
        34. binary_search(v.begin(), v.end(), 5, greater<int>()); // greater를
        35. // 사용하여 5를
        36. // 찾습니다.
        37.  

        
        
        예제 코드 접기
        
        
        

      • 정렬된 범위에 대해 동작하는 모든 알고리즘(unique와 unique_copy를 제외하고 이번 항목에서 이야기한 모든 알고리즘)은 두 개의 값이 같은지를 판정할 때 동등성(equivalence)을 기준으로 삼습니다.

      • 이와 반대로, unique와 unique_copy 알고리즘의 경우에는 상등성(equality)에 의해 두 객체의 같음을 판정합니다. 물론 술어 구문을 작성해서 "같음"의 기준을 다시 정해줄 수도 있지요. 동등성과 상등성의 차이에 대한 자세한 이야기가 필요하면 항목 19가 도움을 줄 것입니다.

  35. 대소문자를 구분하지 않는 문자열 비교는 mismatch 아니면 lexicographical_compare를 써서 간단히 구현할 수 있다 / 229

      • 대소문자를 구분하지 않는 문자열 비교의 구현은 쉬울 수도 있고 그렇지 않을 수도 있습니다. "구분하지 않는 정도를 얼만큼이나 원하냐"에 따라 달라지죠.

        국제화(internationalization)에 대한 사항은 그냥 무시해 버리고 단지 strcmp류의 동작 정도만 원한다면 이 작업은 무척 쉽습니다.
        
        그런데 strcmp가 넘보기에는 힘든 언어별 문자열(이를테면 한국어나 영어 이외의 다른 언어로 쓰여진 텍스트를 가진 문자열)의 처리까지 가능하게 하거나 기본 로케일 이외의 로케일을 사용하는 경우라면 일은 상상외로 어렵습니다.
        
        이번 항목에서는 "쉽게 할 수 있는 방법" 두 가지를 다룰 것입니다. "어렵게 하는 방법"은 STL의 영역을 넘으며, 로케일을 다루는 방법을 익혀야 합니다(부록 A 참조).

      • 우선은 두 개의 문자가 "대소문자의 여부만 제외하고" 같은지를 알아내는 방법이 필요합니다. 두 개의 문자를 모두 소문자(혹은 대문자)로 만든 뒤에 비교를 하면 간단히 해결됩니다.

        다음 예제 코드에 나온 문자 비교 함수(ciCharCompare)는 국제화를 고려하지 않고 만들었습니다. 인터페이스적인 면에서는 strcmp와 비슷하지요.
        
        예제 코드 보기
        
        
        

        1. int ciCharCompare(char c1, char c2) // 문자 c1과 c2를 대소문자를 구분하지 않고
        2. { // 비교합니다. c1 < c2이면 -1을, c1 == c2이면
        3. // 0을 c1 > c2이면 1을 반환합니다.
        4. int lc1 = tolower(static_cast<unsigned char>(c1)); // 이 문장에 대해서는
        5. int lc2 = tolower(static_cast<unsigned char>(c2)); // 아래의 보충 설명을
        6. // 참고하세요.
        7. if (lc1 < lc2) return -1;
        8. if (lc1 > lc2) return 1;
        9. return 0;
        10. }
        11.  
        12. // ciCharCompare는 strcmp와 달리
        13. // 두 매개 변수를 소문자로 모두 바꾼
        14. // 다음에 비교합니다. 따라서 대소문자를
        15. // 구분하지 않는 문자 비교가 된 것이죠.
        16.  
        17. // <cctype>(그리고<ctype.h>)에 선언된
        18. // 많은 함수들과 마찬가지로, tolower의
        19. // 매개 변수와 반환값은 int 타입이지만,
        20. // int가 EOF가 아니기만 하면 이 값의 타입은
        21. // unsigned char가 되어도 별 지장이
        22. // 없습니다.
        23.  
        24. // C와 C++ 모두에서 char는 부호를 가질
        25. // 수도 있고 그렇지 않을 수도 있습니다.
        26.  
        27. // char가 부호 있는 값이라 해도
        28. // tolower를 호출하기 전에
        29. // unsigned char로 캐스팅하면
        30. // 됩니다.

        
        
        예제 코드 접기
        
        
        

      • "쉽게 할 수 있는" 대소문자 비구분 문자열 비교법 중 첫 번째는 strcmp와 유사한 인터페이스를 제공하는 녀석입니다. 이 함수의 이름은 ciStringCompare라고 지었고, 비교되는 두 문자열의 관계에 따라 음수, 0, 양수를 반환합니다. 내부에서는 mismatch 알고리즘을 사용하는데, 이 알고리즘은 두 개의 범위를 받아 서로 대응되는 값이 달라지기 시작하는 첫 위치를 찾아 줍니다.

        mismatch를 호출하기 전에 지켜야 할 전제 조건이 있습니다. 두 문자열 중 하나가 다른 것보다 더 짧을 때, 짧은 문자열을 첫째 매개 변수로 넘기도록 만들어야 하는 것이죠.
        
        mismatch를 활용한 대소문자 비구분 문자열 비교 예제 코드 보기
        
        
        

        1. int ciStringCompareImpl(const string& s1,
        2. const string& s2);
        3.  
        4. int ciStringCompare(const string& s1, const string& s2)
        5. {
        6. if (s1.size() <= s2.size()) return ciStringCompareImpl(s1, s2);
        7. else return -ciStringCompareImpl(s2, s1);
        8. }
        9.  
        10. // 더 짧은 문자열이 첫 번째 매개 변수가
        11. // 되도록 매개 변수의 순서를 조정합니다.
        12.  
        13. int ciStringCompareImpl(const string& s1, const string& s2)
        14. {
        15. typedef pair<string::const_iterator, // PSCI = "pair of
        16. string::const_iterator> PSCI; // string::const_iterator"의 약자
        18. PSCI p = mismatch( // not2를 사용한 이유에 대해서
        19. s1.begin(), s1.end(), // 는 아래의 보충 설명을
        20. s2.begin(), // 읽어보세요. ptr_fun이 왜
        21. not2(ptr_fun(ciCharCompare))); // 필요한지가 궁금하시면
        22. // 항목 41을 보시고요.
        24. if (p.first == s1.end()) { // true이면, s1과 s2이 같든지,
        25. if (p.second == s2.end()) return 0; // s1이 s2보다 길이가 짧든지
        26. else return -1; // 둘 중 하나입니다.
        27. }
        29. return ciCharCompare(*p.first, *p.second); // 두 문자열의 관계는
        30. } // 맞지 않는 두 문자
        31. // 의 대소 관계를
        32. // 그대로 반영합니다.
        33.  
        34. // mismatch 알고리즘은 두 범위 안의
        35. // 문자가 처음으로 맞지 않기 시작하는
        36. // 위치를 가리키는 반복자 두 개(범위
        37. // 마다 하나씩)를 반환해 줍니다.
        38.  
        39. // 이상하게 보일 수 있는 부분이
        40. // mismatch로 넘겨지는 술어 구문으로,
        41. // not2(ptr_fun(ciCharCompare))
        42. // 으로 되어 있습니다.
        43.  
        44. // 이 술어 구문은 두 개의 문자가
        45. // 일치하면 true를 반환해 주어야
        46. // 합니다.
        47.  
        48. // 왜냐하면 mismatch는 자기가 사용하는
        49. // 술어 구문이 false를 반환하면 즉시
        50. // 중단하기 때문이죠.
        51.  
        52. // 하지만 ciCharCompare는 문자가
        53. // 같으면 "0"(false)을, 다르면 "1
        54. // 또는 -1"(true)을 반환합니다.
        55.  
        56. // 따라서 not2와 ptr_fun을
        57. // ciCharCompare의 앞에 붙였고,
        58. // 이로서 인류는 오래오래 행복해지는
        59. // 것입니다.

        
        
        mismatch를 활용한 대소문자 비구분 문자열 비교 예제 코드 접기
        
        
        

      • 쉽게 할 수 있는 "대소문자 비구분 문자열 비교법" 두 번째 방법은 STL의 규정에 맞춘 술어 구문을 만들어, 이것을 연관 컨테이너의 비교 함수처럼 사용하는 것입니다.구현 코드는 상당히 간단하고 이해하기 쉽습니다. 이전의 ciCharCompare 인터페이스를 술어 구문에 맞게 고치고, 문자열 비교 부분을 lexicographical_compare로 대체하기만 하면 됩니다.

        여담이지만 lexicographical_compare 알고리즘은 STL에서 두 번째로 긴 이름을 갖고 있습니다. 가장 이름이 긴 알고리즘은 set_symmetric_difference 랍니다.
        
        lexicographical_compare는 쉽게 말해 strcmp를 일반화한 알고리즘입니다. 즉, strcmp는 문자 배열에 대해서만 동작하는 반면 lexicographical_compare에 들어가는 범위 안의 데이터는 어떤 타입도 될 수 있습니다.
        
        또한 strcmp는 두 개의 문자를 코드 값으로 비교해서 같은지, 작은지, 큰지를 점검하는 반면, lexicographical_compare에는 비교되는 두 요소의 대소 관계를 정할 수 있는 기준을 만들어 넣어줄 수 있습니다.
        
        lexicographical_compare를 활용한 대소문자 비구분 문자열 비교 예제 코드 보기
        
        
        

        1. bool ciCharLess(char c1, char c2) // 대소문자를 고려하지
        2. { // 않았을 때 c1이 c2보다
        3. return // 앞서는지를 알려줍니다.
        4. tolower(static_cast<unsigned char>(c1)) < // 지금은 함수인데, 항목 46을
        5. tolower(static_cast<unsigned char>(c2)); // 보면 함수 객체가 함수
        6. } // 보다 더 나은 이유를 알 수
        7. // 있습니다.
        8.  
        9. bool ciStringCompare(const string& s1, const string& s2)
        10. {
        11. return lexicographical_compare(s1.begin(), s1.end(), // 이 알고리즘에 대한
        12. s2.begin(), s2.end(), // 보충 설명은 이 코드
        13. ciCharLess); // 뒤에 이어지게 되니
        14. } // 참고하세요.
        15.  
        16. // lexicographical_compare는 s1과 s2가
        17. // 어긋나는 첫 번째  위치를 찾아주기
        18. // 위해 동작합니다.
        19.  
        20. // 이때 ciCharLess의 호출 결과를 계속
        21. // 점검하지요.
        22.  
        23. // ciCharLess가 true를 반환하면
        24. // lexicographical_compare도 true를
        25. // 반환하는 것입니다.
        26.  
        27. // strcmp와 마찬가지로 lexicographical_compare도
        28. // 두 범위가 동일한 값을 가지면 같다고
        29. // 판단하기 때문에, 두 문자열이 동일한
        30. // 값을 가지면 false를 반환합니다
        31. // (첫째 범위가 둘째 범위보다 앞서지
        32. // 않는다는 뜻입니다).
        33.  
        34. // 그리고 비교되는 값이 달라지는 부분을
        35. // 찾기 전에 첫째 범위가 끝나 버려도
        36. // true를 반환합니다.
        37.  
        38. // 접두어(prefix)가 되는 문자열은 무조건
        39. // 앞에 온다고 보는 것입니다(이 역시
        40. // strcmp와 똑같습니다).

        
        
        lexicographical_compare를 활용한 대소문자 비구분 문자열 비교 예제 코드 접기
        
        
        

      • 사실 이번 항목에서 구현해 본 대소문자 비구분 문자열 비교 함수와 비슷한 것들이 이미 표준 C 라이브러리 등의 비표준 확장 함수로 만들어져 있고, 폭넓게 사용되고 있습니다. 이름은 stricmp 혹은 strcmpi 등이며, 이번 항목에서 함께 구현해 본 함수들보다도 국제화 지원이 빈약합니다.

        여러분이 이식성에 별 신경을 쓰지 않고, 여러분이 사용하는 문자열에는 NULL 문자가 겹쳐서 들어가지 않으며, 국제화와 친구할 생각이 별로 없다면 STL을 전혀 사용하지 않고 대소문자 비구분 문자열 비교를 구현할 수 있습니다.
        
        string 객체를 const char* 포인터로 변환한 다음 strcmpi나 stricmp에 넘기면 되니까요.
        
        예제 코드 보기
        
        
        

        1. int ciStringCompare(const string& s1, const string& s2)
        2. {
        3. return stricmp(s1.c_str(), s2.c_str()); // 개발 플랫폼에 따라
        4. } // stricmp란 이름이
        5. // 아닐 수 있습니다.
        6.  

        
        
        예제 코드 접기
        
        
        많은 것을 희생했지만, stricmp/strcmpi는 오직 문자열 비교만을 하도록 최적화된 함수이기 때문에 mismatch나 lexicographical_compare 등의 범용 알고리즘보다 긴 문자열 처리에서 월등히 빠릅니다.
        
        수행 효율에 민감한 프로그래머라면 STL이냐 비표준 C 함수이냐를 두고 저울질할 필요가 없습니다. 경우에 따라 다른 방법이 더 낫다는 사실을 깨닫는 것이 STL을 가장 효과적으로 사용하는 방법임이 간혹 증명되니까요.

  36. copy_if를 적절히 구현해 사용하자 / 234

      • STL을 처음 배우는 프로그래머들은 당연히 copy_if가 있을 것으로 기대하고 있지만, STL에는 눈을 씻고 찾아봐도 copy_if를 찾을 수 없습니다.

      • 결국은 만들어 써야 합니다. 헌데, copy_if 만들기는 대수롭지 않지만 제대로 만들기가 껌처럼 쉬운 것은 아닙니다.

        많은 프로그래머들에게 copy_if를 한 번 만들어 보라고 하면 다음과 같은 코드가 나올 수 있을 것입니다.
        
        정확히 맞지는 않은 예제 코드 보기
        
        
        

        1. template <typename InputIterator, // 정확히 맞지는
        2. typename OutputIterator, // 않은 copy_if의
        3. typename Predicate> // 구현 결과
        4. OutputIterator copy_if(InputIterator begin,
        5. InputIterator end,
        6. OutputIterator destBegin,
        7. Predicate p)
        8. {
        9. return remove_copy_if(begin, end, destBegin, not1(p));
        10. }

        
        
        정확히 맞지는 않은 예제 코드 접기
        
        
        이렇게 작성된 코드의 밑바닥에는 STL에서 "술어 구문이 참인 데이터는 모두 복사한다"라고 지정하지는 않았지만(알고리즘이 없다는 뜻) "술어 구문이 참이 아닌 데이터를 제외하고 모두 복사해라"라고 할 수 있다는 사실을 바탕으로 한 것입니다.
        
        즉, copy_if를 구현하려면 copy_if에 넘겼을 술어 구문의 앞에다가 not1을 붙이고, 이 결과를 remove_copy_if에 넘기면 될 것으로 생각했다는 것이죠.
        
        하지만 위 예제 코드를 사용한 다음 예제 코드는 컴파일되지 않습니다.
        
        컴파일되지 않는 예제 코드 보기
        
        
        

        1. // 어떤 Widget 객체에 문제가 있는지(defective)를
        2. // 알려 주는 함수를 하나 만들었습니다.
        3.  
        4. bool isDefective(const Widget& w);
        5.  
        6. // 그리고 어떤 벡터 안에 들어 있는 Widget
        7. // 객체 중에 문제가 있는 Widget 객체를
        8. // cerr를 통해 출력하고 싶습니다.
        9.  
        10. // 앞의 예제 코드에서 만든 copy_if를
        11. // 써 봅니다.
        12.  
        13. vector<Widget> widgets;
        14. ...
        15. copy_if(widgets.begin(), widgets.end(), // 의도는 좋았으나
        16. ostream_iterator<Widget>(cerr, "\n"), // 컴파일되지 않는 코드
        17. isDefective);
        18.  

        
        
        컴파일되지 않는 예제 코드 접기
        
        
        컴파일되지 않는 이유는 not1을 isDefective(함수 포인터)에 적용하려고 했기 때문입니다. 항목 41에서 밝히고 있듯, not1은 함수 포인터에 바로 적용할 수가 없습니다. 우선 ptr_fun에다가 이 함수 포인터를 넘겨야 합니다.
        
        결국 copy_if를 호출하기 위해서는 그냥 함수 객체가 아니라 변환이 가능한(not1 같은 어댑터에 넣을 수 있는) 함수 객체를 넘겨 주어야 한다는 이야기죠.
        
        물론 이 문제는 충분히 쉽게 해결할 수 있긴 하지만, 표준 STL 알고리즘은 절대로 이런 특이 체질의 함수자를 요구하도록 설계되지 않았습니다. copy_if도 마찬가지이고요. 따라서 앞의 구현 코드는 썩 훌륭하지만, 충분히 훌륭하지는 않습니다.
        
        다음은 copy_if를 대수롭지 않게 구현한 결과입니다.
        
        맞게 작성된 예제 코드 보기
        
        
        

        1. template <typename InputIterator, // 맞게 구현된
        2. typename OutputIterator, // copy_if의
        3. typename Predicate> // 구현 결과
        4. OutputIterator copy_if(InputIterator begin,
        5. InputIterator end,
        6. OutputIterator destBegin,
        7. Predicate p)
        8. {
        9. while (begin != end) {
        10. if (p(*begin)) *destBegin++ = *begin;
        11. ++begin;
        12. }
        13. return destBegin;
        14. }

        
        
        맞게 작성된 예제 코드 접기
        
        
        

  37. 범위 내의 데이터 값을 요약하거나 더하는 데에는 accumulate나 for_each를 사용하자 / 237

      • 예를 들어 컨테이너 안의 string의 길이의 합을 구한다든지, 주어진 범위의 숫자들의 곱을 구한다든지 하거나, 1차원적인 정보가 아니라 좌표 같은 2차원 이상의 값들의 평균을 구하고 싶을 때도 있습니다. 이런 각각의 경우를 통칭하여 "범위를 요약한다(summarize)"라고 합니다.

      • 범위의 요약에는 어떤 요약을 할 것인지를 정해줄 수 있어야 합니다. STL에는 이런 작업을 하기 위한 accumulate라는 알고리즘이 제공되고 있습니다. 이 알고리즘은 <algorithm> 헤더가 아닌 <numeric> 헤더에 있는 수치 알고리즘입니다.

        수치 알고리즘에는 이것 외에 세 개가 더 있는데, inner_product, adjacent_difference, partial_sum입니다.

      • 많은 다른 알고리즘도 그렇듯이 accumulate는 두 가지 형태가 있습니다. 우선 두 개의 반복자와 초기 값을 받아들이는 첫째 형태는 범위 내의 값의 합을 초기 값에 더한 결과를 반환합니다.

        accumulate는 입력 반복자이기만 하면 동작하기 때문에 istream_iterator와 istreambuf_iterator(항목 29 참조)에 대해서도 적용할 수 있습니다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 리스트 안의 값들을 모두 더해 봅시다.
        3.  
        4. list<double> ld; // 리스트를 하나 만들고 여기에
        5. ... // double 값을 몇 개 넣습니다.
        6.  
        7. double sum = accumulate(ld.begin(), ld.end(), 0.0); // 0.0부터 시작하여 각 값들의
        8. // 합을 계산합니다.
        9.  
        10. // 초기값이 단순히 0이 아니라 0.0으로
        11. // 되어 있는 부분에 주의해서 보십시오.
        12.  
        13. // 0.0의 타입은 double 입니다.
        14.  
        15. // 따라서 accumulate는 내부적으로
        16. // double 타입의 변수를 사용해서
        17. // 자신이 계산하는 값의 합을
        18. // 저장하게 됩니다.
        19.  
        20. // 만약 다음과 같이 호출된다고
        21. // 가정해 볼까요?
        22.  
        23. double sum = accumulate(ld.begin(), ld.end(), 0); // 합을 계산하되
        24. // 0부터 합니다. 원하는
        25. // 값이 나오지 않습니다!
        26.  
        27. // 0의 타입은 int 입니다.
        28.  
        29. // 따라서 accumulate는 내부적으로
        30. // 자신이 계산하는 값의 합을 int에
        31. // 저장합니다.
        32.  
        33. // 결국 accumulate의 반환값의
        34. // 타입이 int인 것이고, 변수
        35. // sum에 대입되는 값도 int인
        36. // 것입니다.
        37.  
        38. // 원하는 값이 나오지 않는것은
        39. // 당연한 결과이지요.
        40.  
        41.  
        42. //-----------------------------------------------------------------------------
        43. // istream_iterator나 istreambuf_iterator도
        44. // accumulate에 사용할 수 있습니다.
        45.  
        46. cout << "The sum of the ints on the standard input is " // int 값의 합을
        47. << accumulate(istream_iterator<int>(cin), // cin에 출력합니다.
        48. istream_iterator<int>(),
        49. 0);
        50.  

        
        
        예제 코드 접기
        
        
        

      • accumulate의 두 번째 형태는 초기값과 요약용 함수를 받아 동작하는 훨씬 더 일반적인 버전입니다.

        예를 들어, 컨테이너 안에 들어 있는 string 객체의 문자열 길이의 합을 계산하는데 accumulate를 어떻게 사용할지 생각해 보자구요.
        
        이 값을 계산하려면 accumulate에는 두 개의 값이 필요합니다. 첫 번째는 합이 시작되는 값입니다. 당연히 0이겠지요.
        
        두 번째는 string 객체를 하나씩 처리할 때마다 이 합을 업데이트하는 방법입니다. 이렇게 하려면 지금까지의 합과 새 string을 받아 새로 계산된 합을 반환하는 함수를 만들어야 하겠지요.
        
        범위 내의 수를 곱하는 일은 더 쉽습니다. 이런 함수조차 필요가 없기 때문입니다. STL에는 multiplies라는 표준 함수자 클래스가 준비되어 있습니다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 컨테이너 안에 들어있는 문자열들의
        3. // 길이를 모두 더해 봅시다.
        4.  
        5. // 우선 accumulate에 넘길
        6. // 함수부터 만듭니다.
        7.  
        8. string::size_type // string::size_type이 무엇인지
        9. stringLengthSum(string::size_type sumSoFar, // 에 대해서는 아래를 참고하세요.
        10. const string& s)
        11. {
        12. return sumSoFar + s.size();
        13. }
        14.  
        15. // 표준 STL 컨테이너는 size_type이라는
        16. // typedef 타입을 모두 가지고 있는데,
        17. // 이 타입은 어떤 것을 셀 때(카운팅)
        18. // 사용하는 타입입니다.
        19.  
        20. // 예를 들어, 어느 컨테이너이든지 size를
        21. // 호출했을 때 반환되는 값의 타입이
        22. // 이것입니다.
        23.  
        24. // 현재 모든 표준 컨테이너의 size_type은
        25. // size_t로 되어 있습니다.
        26.  
        27. // stringLengthSum은 accumulate의
        28. // 두 번째 형태가 받아들이는 요약용
        29. // 함수의 전형입니다.
        30.  
        31. // 이 함수는 바로 전까지 요약된
        32. // 값과 현재 요소를 받아 들여서
        33. // 새 요약값을 반환합니다.
        34.  
        35. // 전형적인 경우에는 이 함수의
        36. // 첫째 매개 변수의 타입이
        37. // 반환 타입과 같습니다.
        38.  
        39. // 그러면, stringLengthSum을 accumulate에
        40. // 직접 사용해 보도록 하죠.
        41.  
        42. set<string> ss; // string의 컨테이너를 만들고
        43. ... // 데이터를 채웁니다.
        44.  
        45. string::size_type lengthSum = // lengthSum 변수를 stringLengthSum
        46. accumulate(ss.begin(), ss.end(), // 의 호출 결과로 세팅합니다. 이때
        47. 0, stringLengthSum); // 이 함수는 ss 내의 요소에 적용되며,
        48. // 초기 값은 0입니다.
        49.  
        50.  
        51. //-----------------------------------------------------------------------------
        52. // 컨테이너 안의 값을 모두 곱할때는
        53. // 별도의 함수를 만들 필요도 없습니다.
        54.  
        55. vector<float> vf; // float의 컨테이너를 만들고
        56. ... // 데이터를 채웁니다.
        57.  
        58. float product = // product 변수를 vf내의 요소에
        59. accumulate(vf.begin(), vf.end(), // multiplies<float>를 호출한 결과로
        60. 1.0, multiplies<float>()); // 세팅합니다. 이때 초기값은
        61. // 1.0입니다.
        62.  
        63. // 자주 실수하는 한 가지 사항은
        64. // 초기값이 1.0(부동 소수점 실수)
        65. // 이라는 것입니다.
        66.  
        67. // 0이 시작 값이면 얼마를 곱해도
        68. // 결과는 0이 나오게 되잖아요. 맞죠?

        
        
        예제 코드 접기
        
        
        

      • 표준안의 26.4.1절의 둘째 단락에 의하면 accumulate에 넘겨지는 함수의 부가적 효과(side effect)는 없어야 합니다.

        표준에 위배되는 예제 코드 보기
        
        
        

        1. // 범위 안에 있는 점들의 평균 좌표를
        2. // 찾는다고 해 봅시다.
        3.  
        4. // 점은 다음과 같이 정의됩니다.
        5.  
        6. struct Point {
        7. Point(double intX, double intY): x(intX), y(intY) {}
        8. double x, y;
        9. };
        10.  
        11. // 요약용 함수는 PointAverage라고 불리는
        12. // 함수자 클래스의 객체가 될 것입니다.
        13.  
        14. class PointAverage:
        15. public binary_function<Point, Point, Point> { // 항목 40을 보세요.
        16. public:
        17. PointAverage(void): xSum(0), ySum(0), numPoints(0) {}
        18. const Point operator()(const Point& avgSoFar, const Point& p)
        19. {
        20. ++numPoints;
        21. xSum += p.x;
        22. ySum += p.y;
        23. return Point(xSum / numPoints, ySum / numPoints);
        24. }
        25. private:
        26. size_t numPoints;
        27. double xSum;
        28. double ySum;
        29. };
        30.  
        31. // 이제 accumulate를 호출하면 됩니다.
        32.  
        33. list<Point> lp;
        34. ...
        35. Point avg = // lp 내의 점들의 좌표
        36. accumulate(lp.begin(), lp.end(),
        37. Point(0, 0), PointAverage());
        38.  
        39. // 이 코드는 아주 잘 작동할 가능성이
        40. // 크지만, "accumulate에 넘겨지는
        41. // 함수의 부가적 효과는 없어야 한다"는
        42. // 표준에 위배됩니다.
        43.  
        44. // PointAverage의 멤버 변수
        45. // numPoints, xSum, 그리고 ySum를
        46. // 수정하게 되면, 그 자체로 부가적
        47. // 효과가 발생하기 때문이죠(값이
        48. // 수정된 채로 유지되니까요).
        49.  
        50. // 표준에 위배되기 때문에, STL
        51. // 라이브러리에 따라서는 잘못 동작
        52. // (정의되지 않은 동작)할 수
        53. // 있습니다.

        
        
        표준에 위배되는 예제 코드 접기
        
        
        

      • 방금 전 표준에 위배되는 예제 코드와 같은 상황에서는 accumulate 대신 for_each를 사용해야 합니다. for_each 알고리즘은 범위 내의 데이터를 요약할 수 있는 또 하나의 알고리즘이면서 accumulate가 가진 이상한 제한도 받지 않습니다.

        for_each는 범위와 그 범위 내의 요소에 대해 호출할 함수(대개 함수 객체)를 받아들이는데, 이 알고리즘에 넘겨지는 함수는 자신이 처리할 단 하나의 요소만을 받아들이며, for_each는 자신의 수행을 마칠 때 이 함수를 반환합니다(엄밀히 말하면 그 함수의 사본입니다. 자세한 내용은 항목 38에서 찾아보세요).
        
        가장 중요한 포인트는 for_each에 넘겨지는 함수는 부가적 효과를 가져도 된다는 겁니다.
        
        이 외에도 for_each는 accumulate와 두 가지의 차이점이 있습니다. 우선 accumulate라는 이름 자체에서 "범위를 요약한다"는 느낌이 강하게 풍기지만, for_each는 "범위 내의 모든 요소에 어떤 일을 한다"라는 냄새가 나죠. 즉, for_each를 써서도 범위를 요약할 수 있지만 accumulate처럼 확실하지는 않습니다.
        
        두 번째, accumulate는 우리가 원하는 요약 결과를 바로 반환하지만, for_each는 자신이 매개 변수로 받은 함수 객체를 반환하기 때문에 이 객체에서 요약 정보를 뽑아내야 합니다.
        
        C++ 업계 용어로 말하면, for_each에 넘기는 함수자 객체에다가 요약 정보를 얻어낼 수 있는 멤버 함수를 추가해야 한다는 의미이지요.
        
        앞서 본 accumulate를 사용한 표준에 위배되는 예제 코드를 for_each를 쓰도록 고쳐 봅시다.
        
        for_each 예제 코드 보기
        
        
        

        1. struct Point { ... }; // 이전과 같습니다.
        2. class PointAverage:
        3. public unary_function<Point, void> { // 항목 40을 보세요.
        4. public:
        5. PointAverage(void): xSum(0), ySum(0), numPoints(0) {}
        6. void operator()(const Point& p)
        7. {
        8. ++numPoints;
        9. xSum += p.x;
        10. ySum += p.y;
        11. }
        12. Point result(void) const
        13. {
        14. return Point(xSum / numPoints, ySum / numPoints);
        15. }
        16. private:
        17. size_t numPoints;
        18. double xSum;
        19. double ySum;
        20. };
        21.  
        22. list<Point> lp;
        23. ...
        24. Point avg = for_each(lp.begin(), lp.end(), PointAverage()).result();

        
        
        for_each 예제 코드 접기
        
        
        

• Chapter 6   함수자, 함수 객체, 함수, 기타 등등

  38. 함수자 클래스는 값으로 전달되도록(pass-by-value) 설계하자 / 246

      • 함수자 클래스는 반드시 값으로 전달되도록 만듭시다.

        함수 포인터는 값으로 전달됩니다. 이것은 C와 C++ 모두의 표준 라이브러리에서 지켜져 오는 대표적인 규칙입니다.
        
        STL의 함수 객체는 바로 이 함수 포인터를 본뜬 것이고, 그래서 STL에서도 함수 객체는 함수 사이를 오갈 때 값으로 전달(즉, 복사)됩니다.
        
        이 사실은 표준 알고리즘인 for_each의 선언형식을 보면 똑똑히 확인할 수 있습니다. 이 알고리즘은 함수 객체를 값으로 받아들이고 값으로 반환합니다.
        
        template<class InputIterator,
        class Function>
        Function
        for_each(InputIterator first,
        InputIterator last,
        Function f);
        
        솔직히 말해, "값에 의한 전달"은 꼭 철칙이라고 보긴 힘듭니다. 왜냐하면, for_each를 호출하는 쪽에서 매개 변수의 타입을 명시적으로 정해주는 경우도 있기 때문이죠.
        
        그렇지만, STL 사용자들이 반사회적인 근성을 가지고 있지 않은 이상 이렇게 할 리는 거의 없으며, 제품에 따라서는 함수 객체가 참조로 전달될 때 아예 컴파일이 되지 않도록 구현해 놓은 경우도 있습니다.
        
        그러므로 딴 생각 말고 함수 객체는 값으로 전달되도록 만듭시다.

      • 함수 객체를 값으로 전달하기 때문에 함수 객체의 크기는 가능한 한 작아야 합니다. 함수 객체가 값으로 전달된다는 것은 전달 시 복사가 일어난다는 의미이고, 함수 객체의 덩치가 크면 복사 비용도 늘어날 것이 뻔하거든요.

      • 주의해야 할 또 다른 점은, 함수 객체를 단형성(monomorphic)으로 만들어야 한다는 것입니다. 즉 다형성과 반대로 가상 함수를 가지지 못하도록 해야 합니다. 왜냐하면, 파생 클래스의 객체가 기본 클래스 타입의 매개 변수로서 값으로 전달되면 슬라이스 문제(slicing problem)가 발생하거든요(슬라이스 문제의 다른 예는 항목 3에서 찾을 수 있습니다).

      • 하지만, 함수 객체가 기존의 함수를 능가하는 장점 중 하나가 필요한 상태를 유지할 수 있다는(호출 후에도) 것인데, 이 장점이 없는 함수 객체는 무의미할 수 있습니다. 또한, 다형성을 가진 함수자를 만들지 말라는 것도 비현실적입니다. 다행히 STL에서 바라는 "값에 의한 함수자 전달" 규칙을 어기지 않고 잘 동작하는 함수자를 만들 수 있는 방법이 분명히 있습니다.

        그 방법은 이렇습니다. 여러분의 함수자 클래스에 넣고 싶은 데이터나 가상 함수를 뽑아, 이 것을 다른 클래스로 옮깁니다. 그리고 여러분의 함수자 클래스에다가 그 다른 클래스의 포인터를 넣습니다.
        
        예제 코드 보기
        
        
        

        1. // 예를 들어, 데이터를 많이 가지고 있으며
        2. // 다형성을 지닌 함수자 클래스를 만들고
        3. // 싶다고 하면,
        4.  
        5. template <typename T>
        6. class BPFC: // BPFC = "Big Polymorphic
        7. public // 　　　　Function Class"
        8. unary_function<T, void> { // 이 기본 클래스에 대한 설명은
        9. // 항목 40에 되어 있습니다.
        10. private:
        11. Widget w; // 이 클래스는 매우 많은 데이터를
        12. int x; // 가지고 있어서, 값에 의한 전달을
        13. ... // 하기에는 비효율적입니다.
        14. public:
        15. virtual void operator()(const T& val) const; // 가상 함수입니다. 따라서
        16. ... // 슬라이스 문제가 일어날 수 있습니다.
        17. };
        18.  
        19. // 작고, 가상함수를 가지지 않은 클래스를
        20. // 하나 만들고, 데이터와 가상 함수를
        21. // 가진 구현부 클래스를 또 하나 만든
        22. // 후에, 구현부 클래스에 대한 포인터를
        23. // 작은 클래스(실제 함수자 클래스로
        24. // 쓰입니다)에 넣습니다.
        25.  
        26. template <typename T> // 바뀐 BPFC를 위한
        27. class BPFCImpl { // 새로운 구현부 클래스
        28. private:
        29. Widget w; // BPFC에 있었던 모든 데이터는
        30. int x; // 이제 여기에 들어 있게 됩니다.
        31. ...
        32. virtual ~BPFCImpl(void); // 다형성을 가진 클래스는
        33. // 가상 소멸자도 필요합니다.
        34. virtual void operator()(const T& val) const;
        35.  
        36. friend class BPFC<T>; // BPFC가 이 클래스의 데이터를
        37. }; // 쓸 수 있게 합니다.
        38.  
        39. template <typename T>
        40. class BPFC: // 작고 단형성을 가진
        41. public unary_function<T, void> { // BPFC 클래스
        42. private:
        43. BPFCImpl<T> *pImpl; // BPFC가 가진 데이터는 이것 뿐
        44. public:
        45. void operator()(const T& val) const // 이 함수는 이제 가상 함수가 아닙니다;
        46. { // BPFCImpl에게 호출을 전달할 뿐이죠.
        47. pImpl->operator()(val);
        48. }
        49. ...
        50. };

        
        
        예제 코드 접기
        
        
        이 방법은 C++ 계에서는 꽤 잘 알려진 것인데, Effective C++의 항목 31에서 좀 더 자세한 예제를 찾아보실 수 있습니다.
        
        STL의 측면에서 볼 때, 이 방법을 사용하여 만든 함수자 클래스는 객체 복사 시에도 적절히 동작해야 한다는 점을 잊지 마세요. BPFC를 예로 들면 복사 생성자 쪽에서 BPFCImpl 객체에 대해 무엇인가 사려 깊은 일을 해주도록 해야 한다는 것입니다.
        
        가장 쉬운 방법이라면 참조 카운팅이겠지요. 항목 50에서 보게 될 Boost 라이브러리의 shared_ptr과 같은 것을 쓰면 되겠습니다.

  39. 술어 구문은 순수 함수로 만들자 / 250

      • 용어 정리를 먼저 해 보도록 합시다.

        • 술어 구문(predicate)이란 bool 값(아니면 내부적으로 bool로 변환될 수 있는 어떤 값)을 반환하는 함수를 일컫습니다. STL에서 폭넓게 사용되는 함수이지요. 표준 연관 컨테이너의 비교 함수가 우선 술어 구문이고요, 술어 구문은 공통적으로 find_if 같은 알고리즘과 여러 정렬 알고리즘의 매개 변수로 넘겨집니다(정렬 알고리즘에 대해서는 항목 31을 참고하세요).
        • 순수 함수(pure function)란 이 함수가 반환하는 값이 그 함수의 매개 변수에 종속되는 함수를 일컫습니다. 예를 들어, f가 순수 함수이고 x와 y가 객체이면 f(x, y)의 반환 값은 x나 y의 값이 바뀔 때에만 변할 수 있습니다. C++ 에서는, 순수 함수가 사용하는 모든 데이터는 매개 변수로 넘겨지든가 함수가 동작할 동안에 변하지 않은 상태로 있게 됩니다(쉽게 말해 상수 데이터를 말합니다). 어떤 순수 함수가 있는데, 그 함수가 사용하는 데이터는 함수가 호출될 때마다 변한다고 하면, 이 함수에 똑같은 매개 변수를 넘겨서 여러 번 호출했을 때 매번 다른 결과를 가지게 되므로 "순수 함수"라는 정의에 맞지 않습니다.
        • 술어 구문 클래스(predicate class)란 operator()가 술어 구문인 함수자 클래스를 말합니다. 즉, 이 클래스의 operator()가 true나 false를 반환하는 것입니다. 예상하셨겠지만, STL에서 술어 구문을 요구하는 모든 경우에 대하여 술어 구문이나 술어 구문 클래스의 객체를 사용해야 합니다.

      • 항목 38에 따르면 함수 객체는 값으로 전달되기 때문에, 여러분은 함수 객체를 설계할 때 복사에 신경 써야 합니다. 술어 구문인 함수 객체를 설계할 때에는 이점에 더욱 각별히 주의해야 합니다.

        한 가지 이유가 더 있기 때문이죠. 알고리즘은 내부적으로 함수자의 사본을 만들어 가지고 있을 수가 있는데, 몇몇 알고리즘이 이런 자유도를 이용하여 구현되어 있습니다.
        
        이 사실이 알려주는 가장 큰 교훈은 "술어 구문 함수는 반드시 순수 함수이어야 한다"라는 것입니다.
        
        왜 그런지 시험삼아 이 제약을 어겨보도록 합시다. 다음의 술어 구문 클래스는 넘겨지는 매개 변수에 상관없이 세 번째 호출될 때 true를 정확히 한 번 반환하고, 이외에는 false를 반환합니다.
        
        이제 이 클래스를 가지고 vector<Widget>에서 셋째 Widget 객체를 없애보기로 하죠.
        
        코드 자체는 아주 괜찮은 모양을 하고 있지만, STL의 제품의 상당수에서 이 코드는 셋째 Widget 객체 뿐만 아니라, 여섯째 Widget 객체까지 없애버립니다.
        
        잘못된 예제 코드 보기
        
        
        

        1. class BadPredicate: // 이 기본 클래스에 대해서는
        2. public unary_function<Widget, bool> { // 항목 40을 참고하시죠.
        3. public:
        4. BadPredicate(void): timesCalled(0) {} // timesCalled를 0으로 초기화합니다.
        5. bool operator()(const Widget&)
        6. {
        7. return ++timesCalled == 3;
        8. }
        10. private:
        11. size_t timesCalled;
        12. };
        13.  
        14. vector<Widget> vw; // 벡터를 만들고 Widget 객체를
        15. ... // 몇 개 넣습니다.
        16.  
        17. vw.erase(remove_if(vw.begin(), // 셋째 Widget를 없앱니다.
        18. vw.end(), // erase와 remove_if가 어떤 관계
        19. BadPredicate()), // 인지는 항목 32를 참고하세요.
        20. vw.end());
        21.  

        
        
        잘못된 예제 코드 접기
        
        
        왜 이렇게 되는지를 이해하려면, 우선 remove_if가 어떤 식으로 구현되어 있는지 확인하는 것이 좋습니다. 다음의 remove_if 구현 예제 코드는 "자주" 이런 식으로 구현되어 있다는 것이지 항상 그렇다는 것은 아닙니다.
        
        remove_if 구현 예제 코드 보기
        
        
        

        1. template <typename FwdIterator, typename Predicate>
        2. FwdIterator remove_if(FwdIterator begin, FwdIterator end, Predicate p)
        3. {
        4. begin = find_if(begin, end, p);
        5. if (begin == end) return begin;
        6. else {
        7. FwdIterator next = begin;
        8. return remove_copy_if(++next, end, begin, p);
        9. }
        10. }

        
        
        remove_if 구현 예제 코드 접기
        
        
        remove_if를 처음 호출하면, 익명의 BadPredicate 객체가 만들어지면서 이 객체의 timesCalled 멤버가 0으로 초기화된 상태로 됩니다.
        
        이 객체(p)는 find_if로 복사되기 때문에, find_if는 또한 0의 timesCalled 값을 가진 BadPredicate 객체를 받게 됩니다.
        
        find_if는 이 객체가 true를 반환할 때까지 호출합니다. 따라서 세 번 호출하게 되겠죠. 그리고 나서 find_if는 remove_if로 제어권을 돌려줍니다.
        
        이제 remove_if는 자신의 실행을 계속하여 결국 remove_copy_if를 호출하게 되는데, 이때 p의 또다른 사본을 술어 구문으로 넘겨줍니다.
        
        하지만 p의 timesCalled 멤버는 여전히 0인 상태인 것입니다! find_if는 절대로 p를 호출하지 않으며 p의 사본만을 호출할 뿐입니다.
        
        결국 remove_copy_if는 자신의 술어 구문을 사용하는 셈이고, 이 술어 구문은 세 번의 호출 후에 다시 true를 반환할 것입니다.
        
        그 결과 셋째 Widget 객체와 함께 여섯째 Widget 객체가 제거되는 것이죠.

      • 이런 엉터리 같은 자기 모순에 빠지지 않는 가장 쉬운 방법은 술어 구문 클래스 안에 넣는 operator() 함수를 const로 선언하는 것입니다. 이렇게 하면 컴파일러는 클래스의 데이터 멤버를 변경하는 일을 원천 봉쇄합니다.

        이 방법은 위의 문제를 막는 가장 확실하고 간단한 방법입니다.
        
        하지만 이렇게 하더라도 mutable로 선언된 멤버 데이터, const가 아닌 지역 static 객체, const가 아닌 클래스 static 객체, 네임 스페이스 스코프 안에 있는 const가 아닌 객체, 그리고 const가 아닌 전역 객체를 건드리면, 다 소용 없어집니다.
        
        그러니, 술어 구문 클래스 안의 operator() 함수를 const로 만드는 것은 물론이고, operator()가 방금 나열한 객체들을 참조하는 일이 없도록 주의해서 술어 구문 클래스를을 만들어야 합니다.
        
        예제 코드 보기
        
        
        

        1. class BadPredicate:
        2. public unary_function<Widget, bool> {
        3. public:
        4. bool operator()(const Widget&) const
        5. {
        6. return ++timesCalled == 3; // 에러입니다! const 멤버 함수에서
        7. } // 지역 데이터를 변경할 수 없습니다.
        8. ...
        9. };

        
        
        예제 코드 접기
        
        
        

      • 술어 구문 클래스의 객체가 필요한 경우에 술어 구문 함수도 동일하게 쓸 수 있습니다. 물론 술어 구문 클래스 안의 operator() 함수가 순수 함수이어야 하는 것과 마찬가지로 술어 구문 함수도 순수 함수이어야 합니다.

        다음의 함수는 BadPredicate클래스로 만든 객체만큼이나 생각 없이 만들어진 나쁜 술어 구문입니다.
        
        잘못된 예제 코드 보기
        
        
        

        1. bool anotherBadPredicate(const Widget&, const Widget&)
        2. {
        3. static int timesCalled = 0; // 오 노오오우우우!!
        4. return ++timesCalled == 3; // 술어 구문은 순수 함수이어야 하고,
        5. } // 순수 함수는 상태를 가질 수 없습니다.
        6.  

        
        
        잘못된 예제 코드 접기
        
        
        어쨌든 술어 구문을 만들 때에는 항상 순수 함수로 만드세요. 부탁입니다.

  40. 함수자 클래스는 어댑터 적용이 가능하게(adaptable) 만들자 / 255

      • 4대 표준 함수 어댑터(not1, not2, bind1st, bind2nd) 모두 함수 객체에게 typedef 타입을 요구합니다. 따라서 이러한 typedef 타입이 없는, 함수 포인터와 같은 경우는 표준 함수 어댑터에 바로 적용할 수 없고, ptr_fun을 적용한 후에 어댑터를 써야 합니다. ptr_fun은 어댑터가 요구하는 typedef 타입을 제공해 주는 역할을 합니다.

        예제 코드 보기
        
        
        

        1. // Widget* 포인터의 리스트가 하나 있고,
        2. // 흥미로운 데이터를 가진 Widget 객체를
        3. // 가리키는 포인터인지 아닌지를 알려 주는
        4. // 함수가 하나 있다고 합시다.
        5.  
        6. list<Widget*> widgetPtrs;
        7. bool isInteresting(const Widget *pw);
        8.  
        9. // 여기서, 리스트에서 isInteresting 함수가
        10. // true를 반환하는 첫째 포인터를 찾고
        11. // 싶다고 해 보죠.
        12.  
        13. list<Widget*>::iterator i = find_if(widgetPtrs.begin(), widgetPtrs.end(),
        14. isInteresting);
        15.  
        16. if (i != widgetPtrs.end()) {
        17. ... // 흥미로운 Widget 객체
        18. } // 에 대한 첫째 포인터
        19. // 를 처리합니다.
        20.  
        21. // 그렇다면, 이번에는 흥미롭지 않은 Widget에
        22. // 대한 첫째 포인터를 찾으려고 합니다.
        23.  
        24. // 그런데, 다음과 같이 하려고 하면 컴파일부터
        25. // 되지 않습니다.
        26.  
        27. list<Widget*>::iterator i =
        28. find_if(widgetPtrs.begin(), widgetPtrs.end(),
        29. not1(isInteresting)); // 에러입니다! 컴파일이 안 됩니다.
        30.  
        31. // 그 대신, not1을 적용하기 전에
        32. // isInteresting 함수에 ptr_fun를 사용하면
        33. // 되지요.
        34.  
        35. list<Widget*>::iterator i =
        36. find_if(widgetPtrs.begin(), widgetPtrs.end(),
        37. not1(ptr_fun(isInteresting))); // OK.
        38.  
        39. if (i != widgetPtrs.end()) {
        40. ... // 흥미롭지 않은 Widget 객체에 대한
        41. } // 첫째 포인터를 처리합니다.
        42.  

        
        
        예제 코드 접기
        
        
        

      • 어댑터들이 요구하는 typedef를 제공하는 함수 객체를 "어댑터 적용이 가능(adaptable)하다"라고 하고, 이런 typedef를 가지고 있지 않은 것들을 "어댑터 적용이 불가능하다"라고 일컫습니다. 어댑터 적용이 가능한 함수 객체는 그렇지 않은 것보다 더 많은 경우에 사용할 수 있기 때문에, 여러분의 함수 객체는 할 수 있으면 항상 그렇게 만드셨으면 좋겠습니다.

        어댑터들이 요구하는 typedef 타입이란 argument_type, first_argument_type, second_argument_type, result_type의 네 개입니다.
        
        하지만 이것만 가지고는 마음에 다가오지 않지요. 왜냐하면 다른 종류의 함수자 클래스에서 이들 이름을 부분적으로 다르게 제공해야 하기 때문입니다.
        
        사실 어댑터를 직접 만들 생각이 없는 분이라면 이들 typedef에 대해 전혀 몰라도 됩니다. 그도 그럴 것이 기본 클래스(정확하게는 기본 구조체)에서 필요한 typedef를 상속하면 가장 편하게 이들 typedef를 제공할 수 있으니까요.
        
        하나의 매개 변수를 받는 operator()를 가진 함수자 클래스라면 그 클래스에 상속시킬 기본 구조체는 std::unary_function입니다.
        
        operator()가 두 개의 매개 변수를 받는 경우라면, std::binary_function에서 상속시키면 됩니다.
        
        unary_function과 binary_function은 템플릿입니다. 따라서 여기서 바로 상속시킬 수는 없고, 이 템플릿으로 만든 구조체에서 상속시켜야 하지요.
        
        unary_function이라면 여러분이 만들 함수자 클래스의 operator()가 받는 매개 변수의 타입(하나)과 operator()의 반환값 타입을 지정해 주어야 합니다.
        
        binary_function이라면 세 개의 타입 매개 변수를 지정하면 됩니다. operator()의 첫째와 둘째 매개 변수의 타입, 그리고 operator()의 반환 타입이죠.
        
        예제 코드 보기
        
        
        

        1. template <typename T>
        2. class MeetsThreshold: public std::unary_function<Widget, bool> {
        3. private:
        4. const T threshold;
        6. public:
        7. MeetsThreshold(const T& threshold);
        8. bool operator()(const Widget&) const;
        9. ...
        10. };
        11.  
        12. struct WidgetNameCompare:
        13. std::binary_function<Widget, Widget, bool> {
        14. bool operator()(const Widget& lhs, const Widget& rhs) const;
        15. };
        16.  
        17. // unary_function 혹은 binary_function으로
        18. // 넘겨지는 타입이 함수자 클래스가
        19. // 받고 반환하는 타입과 같다는 점에
        20. // 주의해서 보기 바랍니다.
        21.  
        22. // operator()의 반환 타입이 unary_function이나
        23. // binary_function의 마지막 매개 변수로
        24. // 넘겨진다는 점만 조금 이상하지만요.
        25.  
        26. // MeetsThreshold는 클래스인데,
        27. // WidgetNameCompare는 구조체로
        28. // 되어 있네요.
        29.  
        30. // 사실, 함수자를 클래스로 선언하느냐,
        31. // 구조체로 선언하느냐는 개인적인
        32. // 스타일입니다.
        33.  
        34. // 대개 상태가 없는(데이터 멤버가 없는)
        35. // 함수자 클래스는 구조체로 선언됩니다.

        
        
        예제 코드 접기
        
        
        

      • 일반적으로, unary_function이나 binary_function에 넘겨지는 비포인터(non-pointer) 타입은 const와 참조자 표시를 빼는 것이 상례입니다. 그런데, operator()가 포인터를 매개 변수로 받는 경우에는 이야기가 달라집니다. 일반적으로 포인터를 매개 변수로 받고 반환값으로 돌려주는 함수자 클래스에 대해서는 operator()가 받고 반환하는 타입을 그대로 unary_function과 binary_function에 넘겨주면 됩니다.

        예제 코드 보기
        
        
        

        1. struct WidgetNameCompare:
        2. std::binary_function<Widget, Widget, bool> {
        3. bool operator()(const Widget& lhs, const Widget& rhs) const;
        4. };
        5.  
        6. // operator()는 const Widget& 타입을
        7. // 받지만 binary_function에는 Widget 타입을
        8. // 넘겨줍니다.
        9.  
        10. struct PtrWidgetNameCompare:
        11. std::binary_function<const Widget*, const Widget*, bool> {
        12. bool operator()(const Widget* lhs, const Widget* rhs) const;
        13. };
        14.  
        15. // 반면 포인터의 경우에는 그대로
        16. // const Widget* 타입을 넘겨줍니다.

        
        
        예제 코드 접기
        
        
        조금 아리송하지만, unary_function과 binary_function이 있기에 다음과 같이 할 수 있는 것입니다.
        
        예제 코드 보기
        
        
        

        1. list<Widget> widgets;
        2. ...
        3. list<Widget>::reverse_iterator i1 = // 문턱값(threshold)이 10인
        4. find_if(widgets.begin(), widgets.end(), // 조건을 만족시키지 못하는
        5. not1(MeetsThreshold<int>(10))); // 마지막 Widget을 찾습니다
        6. // (되기만 하면).
        7.  
        8. Widget w(constructor arguments);
        9.  
        10. list<Widget>::iterator i2 = // WidgetNameCompare에서
        11. find_if(widgets.begin(), widgets.end(), // 정의된 정렬 순서에 의해
        12. bind2nd(WidgetNameCompare(), w)); // w보다 앞에 오는 첫째
        13. // Widget을 찾습니다.
        14.  

        
        
        예제 코드 접기
        
        
        

      • STL 함수 객체는 C++ 함수를 기본으로 짜여진 것이고, 하나의 C++ 함수는 한 종류의 매개 변수 타입과 하나의 반환 타입 밖에 가지지 않습니다. 결국, STL은 함수자 클래스는 operator() 함수를 하나 밖에 가질 수 없다고 내부적으로 가정하고 있고, unary_function이나 binary_function에 넘겨질 매개 변수와 반환값 타입도 한 가지 뿐입니다.

        가끔은 이런 생각이 드실 것입니다. "하나의 함수자 클래스에 여러 개의 호출 형태를 넣도록 하는 것이 더 합당하지 않을까?(어댑터 적용은 못하겠지만)"하고요.
        
        이것에 관련해서는 항목 7, 20, 23, 그리고 25에서 예제와 함께 잘 이야기되어 있습니다.
        
        하지만, 이런 함수자 클래스는 사파(邪派)이지, 정파(正派)가 아닙니다. 어댑터 적용성(adaptability)은 매우 중요한 요소이므로, 여러분은 함수자 클래스를 만들 때에는 이것을 반드시 따르도록 최대한 신경 쓰셔야 합니다.

  41. ptr_fun, mem_fun, mem_fun_ref의 존재에는 분명한 이유가 있다 / 260

      • f란 이름의 함수와 x란 이름의 객체가 하나 있습니다. 여기서 x에 대해 f를 호출하고 싶으며, 호출하는 위치는 x의 멤버 함수의 바깥쪽입니다. 이런 상황에서 C++는 다음의 세 가지 문법을 제공합니다.

        • 문법 #1: f(x);
          f가 멤버 함수가 아닌 경우
        • 문법 #2: x.f();
          f가 x의 멤버 함수이고, x는 객체이든지 객체에 대한 참조자인 경우
        • 문법 #3: p->f();
          f가 x의 멤버 함수이고, p는 x 객체에 대한 포인터인 경우

      • for_each를 포함한 모든 알고리즘은 내부적으로 문법 #1만을 사용합니다. 따라서, 알고리즘에 멤버 함수를 넘겨주면(문법 #2 혹은 문법 #3을 사용해야 하는 경우), 컴파일이 되지 않습니다. 이처럼 알고리즘에 멤버 함수를 넘겨줘야 하는 상황에서 mem_fun_ref(문법 #2)나 mem_fun(문법 #3)을 사용합니다.

        이제, Widget 객체를 검사(test)할 수 있는 함수가 하나 있다고 가정하지요. 그리고 Widget 객체의 컨테이너가 하나 있습니다. 이 컨테이너에 들어 있는 모든 Widget 객체를 테스트하려면 for_each를 사용할 수 있겠지요.
        
        test가 Widget의 멤버 함수가 아닌 경우라면(즉, 문법 #1이 사용되어야 한다면), 문제 없이 for_each를 사용할 수 있습니다.
        
        하지만, test가 Widget의 멤버 함수라면(즉, 문법 #2이 사용되어야 한다면), for_each에 test를 넘겨주는 부분이 컴파일되지 않습니다.
        
        컨테이너가 Widget 객체에 대한 포인터를 담고 있고, test가 Widget의 멤버 함수인 경우(문법 #3이 사용되어야 합니다)도 마찬가지이지요.
        
        예제 코드 보기
        
        
        

        1. void test(Widget& w); // w를 검사해서, 검사 기준을 통과하지 않으면
        2. // "failed"라고 표시합니다.
        3.  
        4. vector<Widget> vw; // vw에는 Widget 객체가 담겨져 있습니다.
        5.  
        6. for_each(vw.begin(), vw.end(), test); // 호출 #1 (컴파일됩니다)
        7.  
        8. // 하지만, test가 Widget의 멤버 함수라면?
        9.  
        10. class Widget {
        11. public:
        12. ...
        13. void test(void); // 자체 검사를 수행합니다; 검사를 통과 하지
        14. ... // 않으면 "this"가 "failed"라고 표시됩니다.
        15. }
        16.  
        17. for_each(vw.begin(), vw.end(),
        18. &Widget::test); // 호출 #2 (컴파일되지 않습니다)
        19.  
        20. // test가 Widget의 멤버 함수이고,
        21. // 컨테이너에 Widget의 포인터가 담겨 있다면?
        22.  
        23. list<Widget*> lpw; // lpw는 Widget 객체에 대한 포인터를 가지고 있습니다.
        24. for_each(lpw.begin(), lpw.end(),
        25. &Widget::test); // 호출 #3 (컴파일은 어림도 없습니다)
        26.  

        
        
        예제 코드 접기
        
        
        왜냐하면 for_each(를 포함한 모든 알고리즘)는 문법 #1만을 사용하기 때문입니다. 아마도 for_each는 다음과 예제와 같이 구현되어 있을 것입니다.
        
        for_each 예제 코드 보기
        
        
        

        1. template <typename InputIterator, typename Function>
        2. Function for_each(InputIterator begin, InputIterator end, Function f)
        3. {
        4. while (begin != end) f(*begin++);
        6. return f;
        7. }

        
        
        for_each 예제 코드 접기
        
        
        

      • mem_fun과 mem_fun_ref은 실제로 함수 템플릿이며, 매개 변수의 개수와 멤버 함수의 const 멤버 여부에 따라 약간씩 변형된 mem_fun과 mem_fun_ref의 변이 형태가 몇 가지 더 있습니다.

        말로만 떠들기에는 부족한 듯 싶어 템플릿 선언문 하나를 따 왔습니다.
        
        mem_fun 예제 코드 보기
        
        
        

        1. template <typename R, typename C> // 매개 변수를 받지 않고
        2. mem_fun_t<R, C> // const 멤버가 아닌 멤버 함수에 대한
        3. mem_fun(R (C::*pmf)(void)); // mem_fun의 선언문, C는 클래스이며
        4. // R은 포인터로 가리켜지는 멤버 함수
        5. // (pmf)의 반환값 타입입니다.
        6.  
        7. // mem_fun은 멤버 함수의 포인터, pmf를 받아
        8. // mem_fun_t 타입의 객체를 반환합니다.
        9.  
        10. // 즉, 이것은 멤버 함수 포인터를 가지고
        11. // 있으면서 operator()에 넘겨진 객체에
        12. // 대해 멤버 함수를 호출해 주는(물론
        13. // 포인터를 통해) operator()를 제공하는
        14. // 함수자 클래스라고 할 수 있습니다.
        15.  
        16. // 예를 하나 들까요? 다음의 코드를 보도록 하죠.
        17.  
        18. list<Widget*> lpw; // 이전과 같습니다.
        19. ...
        20. for_each(lpw.begin(), lpw.end(),
        21. mem_fun(&Widget::test)); // 이제는 컴파일됩니다.
        22.  

        
        
        mem_fun 예제 코드 접기
        
        
        for_each는 Widget::test의 포인터를 가지고 있는 (mem_fun이 반환해주는)mem_fun_t 타입의 객체를 받습니다.
        
        for_each는 lpw내의 Widget* 포인터에 대해 mem_fun_t 객체를 불러오게 되는데, 이때 문법 #1을 쓰는 것이죠. 그리고 mem_fun_t 객체는 바로 Widget* 포인터에 대해 Widget::test를 호출합니다. 문법 #3을 사용해서요.
        
        간단히 말하면, Widget::test가 Widget* 포인터와 함께 쓰일 때 필요한 문법(문법 #3)을 문법 #1, 즉 for_each가 사용하는 문법으로 맞추어 주는 어댑터입니다.
        
        mem_fun_t과 같은 클래스는 함수 객체 어댑터로 알려져 있습니다. 이와 비슷한 방식으로, mem_fun_ref는 문법 #2를 문법 #1에 맞추어 주는 어댑터로서, mem_fun_ref_t 타입의 어댑터 객체를 만들어 냅니다.

      • mem_fun과 mem_fun_ref에서 만들어지는 객체는 STL 컴포넌트에서 모든 함수를 한 가지 종류의 문법(문법 #1)을 사용해서 호출하도록 하는 일 이상의 것을 품고 있습니다. 아주 중요한 typedef 타입도 이 함수 템플릿들이 지원합니다. ptr_fun에서 만들어지는 객체도 그렇습니다. 이 typedef는 항목 40에서 이야기했던 바로 그 녀석입니다.

        앞에서 보았던 예제 중 일부를 가져와 보았습니다.
        
        for_each(vw.begin(), vw.end(), test);
        
        이 문장은 진짜 함수를 넘기기 때문에(즉, 문법 #1을 통해 호출되기 때문에) for_each에서 쓰는 문법으로 맞출 필요가 없습니다.
        
        또한 for_each는 ptr_fun이 추가해 주는 typedef를 사용하지 않기 때문에 test에 ptr_fun을 사용할 필요도 없습니다.
        
        뭐 그렇지만 typedef가 더해진다고 해도 전혀 문제가 될 것은 없습니다. 다음의 코드는 방금 전의 코드와 똑같이 컴파일되고 동작합니다.
        
        for_each(vw.begin(), vw.end(),
        ptr_fun(test));
        
        ptr_fun은 항상 써도 별 문제는 없지만, 꼭 필요할 때만 써도 됩니다. 꼭 필요한 경우에 쓰지 않았다면 여러분의 컴파일러가 미친듯이 경보를 울려줄 것이니, 빠진 부분에 다시 추가하면 되니까요.
        
        mem_fun과 mem_fun_ref이라면 상황이 근본적으로 다릅니다. STL 컴포넌트에 멤버 함수를 넘길 때에는 세상이 없어져도 이 어댑터를 사용해야 합니다.

  42. less<T>는 operator<의 의미임을 꼭 알아두자 / 266

      • less를 사용하겠다면 반드시 operator<의 의미를 가지게 하세요.

        C++ 프로그래머는 몇 가지 사항에 대해 아무 생각 없이 이런 가정을 합니다.
        
        이를테면 그들은 복사 생성자는 복사를 할 것이라고 가정합니다(항목 8에서 보이고 있듯, 이 규칙을 지키지 않으면 끔찍한 일이 생깁니다).
        
        그들은 객체의 주소를 받아내면 포인터가 나온다는 가정도 합니다(항목 18로 가셔서, 그렇지 않을 때 어떤 일이 생기는지 알아보세요).
        
        bind1st와 not2 같은 어댑터는 함수 객체에 적용될 것이라고 가정합니다(항목 40에서는 그렇지 않을 때 어떻게 산통이 깨지는지 설명하고 있습니다).
        
        C++ 프로그래머는 operator+는 더하기를 하고(string만 제외하고요. 하지만 문자열 잇기에 "+"를 사용하는 것은 긴 내력을 가지고 있습니다), operator-는 빼기를 하고, operator==는 비교한다고 가정하죠.
        
        마지막으로 less는 operator<과 다름없다고 생각해 버립니다.
        
        이러한 프로그래머의 기대를 져버리게 되면 쓸데없는 혼란이 생깁니다. operator+가 빼기를 한다고 생각해 보세요. 끔찍하죠?
        
        바람직하지 않은 예제 코드 보기
        
        
        

        1. // Widget 객체는 무게(weight)와
        2. // 최대 속도(maximum speed)를
        3. // 가지고 있다고 합시다.
        4.  
        5. class Widget {
        6. public:
        7. ...
        8. size_t weight(void) const;
        9. size_t maxSpeed(void) const;
        10. ...
        11. };
        12.  
        13. // 그리고, Widget 객체는 무게를 기준으로
        14. // 정렬됩니다.
        15.  
        16. // 즉, Widget 객체의 operator< 연산자는
        17. // 다음과 같이 되어 있습니다.
        18.  
        19. bool operator<(const Widget& lhs, const Widget& rhs)
        20. {
        21. return lhs.weight() < rhs.weight();
        22. }
        23.  
        24. // 그런데, Widget 객체를 최대 속도를
        25. // 가지고 정렬하는 multiset<Widget>을
        26. // 만들고 싶다고 가정을 해 봅시다.
        27.  
        28. // less<Widget>은 내부적으로
        29. // operator<를 호출할 것입니다.
        30.  
        31. // 하지만 Widget의 operator<는
        32. // 최대 속도가 아니라 무게를 기준으로
        33. // 비교를 합니다.
        34.  
        35. // 별로 바람직하지 않은 방법으로, less<Widget>
        36. // 과 operator<의 밀원 관계를 끊는
        37. // 방법이 있습니다.
        38.  
        39. template <>
        40. struct std::less<Widget>:
        41. public std::binary_function<Widget,
        42. Widget,
        43. bool> {
        44. bool operator()(const Widget& lhs, const Widget& rhs) const
        45. {
        46. return lhs.maxSpeed() < rhs.maxSpeed();
        47. }
        48. };
        49.  
        50. // 이러한 사정을 모르는 사람이 less<Widget>을
        51. // 사용하려 할때, less<Widget>은 당연히
        52. // 내부적으로 Widget의 operator<를
        53. // 사용할 것이라고 생각하고 less<Widget>을
        54. // 사용할 것입니다.
        55.  
        56. // 하지만, 그렇지 않기 때문에 혼란이 생깁니다.
        57.  
        58. // 예를 들어 다음 multiset을 보고는
        59.  
        60. multiset<Widget> widgets;
        61.  
        62. // widgets가 Widget의 operator<를 기준으로
        63. // (그러니까 무게를 기준으로) 정렬되었다고
        64. // 생각할 것입니다.
        65.  
        66. // 하지만 실제로는 less<Widget>의 의미가
        67. // 무게가 아닌 최대 속도를 기준으로 비교하도록
        68. // 바뀌었기 때문에 혼란이 생깁니다.
        69.  

        
        
        바람직하지 않은 예제 코드 접기
        
        
        

      • less(그러니까 operator<)가 아닌 '다른' 기준을 가지고 객체를 정렬하겠다면 less라고 불리지 않는 특수한 함수자 클래스를 만드세요.

        다음 예제 코드는, 방금 전 예제 코드의 상황을 보다 바람직하게 해결한 예제 코드입니다.
        
        바람직한 예제 코드 보기
        
        
        

        1. // Widget 객체를 weight가 아닌 maxSpeed를
        2. // 기준으로 정렬하고 싶으면 less의 의미
        3. // (weight를 기준으로 비교하는 operator<)를
        4. // 바꿀 것이 아니라, maxSpeed를 기준으로
        5. // 비교하는 새로운 함수자 클래스를 만듭니다.
        6.  
        7. struct MaxSpeedCompare:
        8. public binary_function<Widget, Widget, bool> {
        9. bool operator()(const Widget& lhs, const Widget& rhs) const
        10. {
        11. return lhs.maxSpeed() < rhs.maxSpeed();
        12. }
        13. };
        14.  
        15. // maxSpeed를 기준으로 정렬하는 multiset을
        16. // 생성할 때에는, MaxSpeedCompare를 비교
        17. // 타입으로 써서 기본적으로 사용되는 비교 타입,
        18. // 즉 less<Widget>이 사용되지 않게 합니다.
        19.  
        20. multiset<Widget, MaxSpeedCompare> widgets;
        21.  
        22. // 이제 위의 multiset 타입을 보면,
        23. // MaxSpeedCompare를 기준으로 정렬된다는
        24. // 사실이 명확하게 드러납니다.

        
        
        바람직한 예제 코드 접기
        
        
        

      • less의 동작을 변경하더라도 operator<의 의미에서 벗어나지 않는 선에서 변경하도록 합니다.

        대표적인 예로 스마트 포인터의 경우가 있습니다. Boost 라이브러리의 shared_ptr(항목 7과 50에서 이야기한 그 스마트 포인터입니다)의 일부를 다음에 실어 보았습니다. 한 번 보세요.
        
        예제 코드 보기
        
        
        

        1. namespace std {
        2. template <typename T> // boost::shared_ptr<T>의
        3. struct less<boost::shared_ptr<T> >: // std::less의 골격입니다
        4. public // (boost는 네임 스페이스입니다).
        5. binary_function<boost::shared_ptr<T>,
        6. boost::shared_ptr<T>, // 습관처럼 쓰이는 기본 클래스
        7. bool> { // 입니다(항목 40을 보시죠).
        8. bool operator()(const boost::shared_ptr<T>& a,
        9. const boost::shared_ptr<T>& b) const
        10. {
        11. return less<T*>()(a.get(), b.get()); // shared_ptr::get은
        12. } // shared_ptr 객체 안에 있는
        13. // 본래의 포인터를 반환합니다.
        14. };
        15. }
        16.  
        17. // 이건 절대로 엉터리가 아니고,
        18. // 놀라움을 주지도 않습니다.
        19.  
        20. // less를 한정하는 일은 단지
        21. // 스마트 포인터의 정렬 동작을
        22. // 원래의 포인터의 정렬과
        23. // 똑같이 하기 위해서니까요.

        
        
        예제 코드 접기
        
        
        

• Chapter 7   STL 프로그래밍을 더 재미있게 해주는 팁 모음

  43. 어설프게 손으로 작성한 루프보다는 알고리즘이 더 낫다 / 272

      • 손으로 작성한 어떤 루프보다도 한 번의 알고리즘 호출이 대개 더 괜찮습니다. 더 효율적이고, 더 정확하며, 유지보수성마저 더 뛰어납니다.

        • 효율(Efficiency): 알고리즘은 프로그래머가 만든 루프보다 자주 훨씬 효율적입니다.
        • 정확성(Correctness): 루프를 직접 작성하면 알고리즘을 호출하는 경우보다 에러가 일어나기 쉽습니다.
        • 유지보수성(Maintainability): 직접 만든 루프와 비교해서, 알고리즘은 훨씬 깨끗하고 간명한 코드로 만들어져 있는 경우가 많습니다.
        
        
        이제부터는 각각의 경우를 이야기해 볼까 합니다.

      • 알고리즘은 프로그래머가 만든 루프보다 자주 훨씬 효율적입니다.

        효율의 관점에서 볼 때 알고리즘은 세 가지 측면에서 손으로 작성한 루프를 압도합니다. 두 가지는 주된 것이고, 한 가지는 부가적인 것입니다.
        
        부가적인 면은 쓸데 없는 계산량을 줄일 수 있다는 것입니다.
        
        예제 코드 보기
        
        
        

        1. // 여러분이 다시 그리기(redraw)를 지원하는
        2. // Widget 클래스를 가지고 있다고 합시다.
        3.  
        4. class Widget {
        5. public:
        6. ...
        7. void redraw(void) const;
        8. ...
        9. };
        10.  
        11. // 그리고 어떤 list 안에 있는 모든 Widget
        12. // 객체에게 다시 그리기를 지시하고 싶다면
        13. // 이렇게 루프를 만들겠지요.
        14.  
        15. list<Widget> lw;
        16. ...
        17. for (list<Widget>::iterator i = lw.begin(); i != lw.end(); ++i) {
        18. i->redraw();
        19. }
        20.  
        21. // 잘 보면 for문에서 i와 lw.end()를
        22. // 비교 하는 부분이 루프를 수행할 때마다
        23. // 실행되는 것을 알 수 있습니다.
        24.  
        25. // 즉 루프를 수행할 때마다 lw.end()
        26. // 가 호출된다는 것입니다.
        27.  
        28. // 반면 알고리즘을 호출하는 경우에는
        29. // lw.end()가 한번만 호출됩니다.
        30.  
        31. for_each(lw.begin(), lw.end(), // lw.end()를 정확히 한 번만
        32. mem_fun_ref(&Widget::redraw)); // 평가합니다.
        33.  

        
        
        예제 코드 접기
        
        
        STL 제작자들은 begin과 end(그리고 size 등의 함수들)이 아주 자주 사용된다는 사실을 파악하고 있기 때문에 알고리즘을 구현할 때 최대의 효율을 내는데 온 신경을 씁니다.
        
        제작자 중 십중팔구는 알고리즘을 인라인(inline) 함수로 만들며, 반복되는 연산 결과를 루프 바깥으로 빼어 대부분의 컴파일러가 이런 부분을 피해갈 수 있도록 용을 씁니다.
        
        알고리즘이 수작업 루프보다 효율이 좋은 두 가지의 주요 원인 중 첫 번째는 라이브러리 제작자가 컨테이너의 구현 방식을 충분히 파악하고 있기 때문에, 컨테이너의 횡단(traversal) 코드를 더욱 최적화시킬 수 있다는 점입니다.
        
        예를 들죠. deque에 저장된 객체는 (내부적으로) 하나 이상의 고정 크기 배열에 저장되어 있습니다. 이 배열은 포인터를 통해 횡단하는 것이 반복자를 사용하는 것보다 훨씬 빠릅니다.
        
        하지만 포인터 기반의 횡단을 할 수 있는 칼자루는 라이브러리 제작자만이 쥐고 있습니다. 왜냐하면, 그들만이 내부 배열의 크기와 배열 사이의 이동 방법을 알고 있기 때문입니다.
        
        이렇게 컨테이너의 내부 데이터 구조를 고려하여 만들어진 알고리즘은 "순진하게" 구현한 알고리즘보다 20% 정도 빠르다고 알려져 있습니다. 이것은 deque뿐만이 아니라 다른 컨테이너 타입도 그럴 수 있습니다.
        
        수작업 루프보다 알고리즘이 효율적인 두 번째 이유는, 가장 허접한 것을 제외한 모든 STL 알고리즘은 평범한 C++ 프로그래머의 수준으로 따라오긴 힘들 정도로 세련된(가끔은 훨씬 세련된 것도 있습니다) 컴퓨터 공학적인 알고리즘을 사용합니다.
        
        sort와 그의 형제들(항목 31 참조)을 압도할 코드를 수작업으로 짤 확률은 별로 높지 않습니다.
        
        정렬된 범위에서의 탐색 알고리즘(항목 34와 45 참조)도 못지 않게 훌륭합니다.
        
        게다가 연속 메모리 컨테이너에서 몇 개의 객체를 제거하는 등의 평범한 일들조차 erase-remove 합성 구문이 훨씬 효율적입니다(항목 9 참조).

      • 루프를 직접 작성하면 알고리즘을 호출하는 경우보다 에러가 일어나기 쉽습니다.

        루프를 직접 만들때 실수하기 딱 좋은 예제를 가져와 보았습니다.
        
        예제 코드 보기
        
        
        

        1. // 예를 들어 배열이 하나 있고, 배열의
        2. // 모든 요소마다 41을 더한 후 그 결과를
        3. // 데크(deque)의 앞에 삽입하고 싶습니다.
        4.  
        5. // 루프를 직접 작성한다면 다음과 같은
        6. // 정도의 코드가 나올 것입니다.
        7.  
        8. // C API: 이 함수는 최대 arraySize 만큼의 double을 가진 배열의 포인터를 받아
        9. // 데이터를 채웁니다. 이 함수는 채워진 데이터의 개수를 반환합니다.
        10.  
        11. size_t fillArray(double *pArray, size_t arraySize);
        12. double data[maxNumDoubles]; // 가능한 최대 크기의 배열을
        13. // 지역 변수로 만듭니다.
        14.  
        15. deque<double> d; // 데크를 하나 만들고, 데이터를
        16. ... // 여기에 넣게 됩니다.
        17.  
        18. size_t numDoubles =
        19. fillArray(data, maxNumDoubles); // API로부터 배열 데이터를 채웁니다.
        20.  
        21. for (size_t i = 0; i < numDoubles; ++i) { // data내의 i에 대해,
        22. d.insert(d.begin(), data[i] + 41); // data[i] + 41를 계산한 결과를
        23. } // d의 앞에 삽입합니다; 이 코드는
        24. // 버그를 가지고 있습니다!
        25.  
        26. // 동작은 하지만, 삽입하는 위치가 d.begin()
        27. // 이기 때문에, 마지막에 삽입된 요소는 이
        28. // 데크의 앞에 있게 됩니다. 즉, 순서가
        29. // 거꾸로 뒤집어졌습니다!
        30.  
        31. // 이런 문제를 깨닫게 된다면 허겁지겁
        32. // 다음과 같이 고치지 않을까요?
        33.  
        34. deque<double>::iterator insertLocation = // d의 시작 반복자를
        35. d.begin(); // 기억해 둡니다.
        36.  
        37. for (size_t i = 0; i < numDoubles; ++i) { // data[i] + 41를
        38. d.insert(insertLocation++, data[i] + 41); // insertLocation에 삽입하고,
        39. } // 그렇게 한 후에
        40. // insertLocation를
        41. //증가시킵니다; 이 코드도
        42. // 버그를 잘도 가지고 있습죠.
        43.  
        44. // 이 코드를 실행하면 프로그램이 바로
        45. // 다운됩니다.
        46.  
        47. // deque::insert는 호출될 때마다
        48. // 데크의 모든 반복자를 무효화시키는데,
        49. // insertLocation도 이 영향을
        50. // 피할 수 없습니다.
        51.  
        52. // 결국 코드를 다시 다음과 같이 수정해야
        53. // 합니다.
        54.  
        55. deque<double>::iterator insertLocation =
        56. d.begin(); // 이전과 같습니다.
        57.  
        58. for (size_t i = 0; i < numDoubles; ++i) { // insert가 호출될 때마다
        59. insertLocation = // insertLocation를 업데이트
        60. d.insert(insertLocation, data[i] + 41); // 해서 반복자를 항상 유효한
        61. ++insertLocation; // 상태로 유지한 후에 이것을
        62. } // 증가시킵니다.
        63.  
        64. // 드디어 여러분이 원하는 대로 동작하게
        65. // 되었습니다만, 코드가 대체 몇 줄이죠?
        66.  
        67. // 알고리즘을 사용한 다음의 코드와 비교해
        68. // 보시죠.
        69.  
        70. transform(data, data + numDoubles, // data의 모든 요소에
        71. inserter(d, d.begin()), // 41을 더한 결과를
        72. bind2nd(plus<int>(), 41)); // d의 앞에 복사합니다.
        73.  

        
        
        예제 코드 접기
        
        
        부주의한 반복자 관리가 패가망신으로 이어지는 다른 예제가 궁금하신 분은 항목 9를 보기 바랍니다. erase를 루프를 통해 호출할 때 발생되는 문제점을 읽을 수 있습니다.

      • 직접 만든 루프와 비교해서, 알고리즘은 훨씬 깨끗하고 간명한 코드로 만들어져 있는 경우가 많습니다.

        STL 알고리즘의 이름은 그 자체가 의미적인 정보를 가지고 있어서, 마구잡이로 만든 어느 루프보다도 명확한 의미를 프로그래머에게 던져 줍니다.
        
        이를테면 transform을 호출하려고 하는 프로그래머는 범위 내의 모든 객체에 어떤 함수가 적용되고, 그 함수의 호출 결과가 어딘가에 기록된다는 생각을 머리에 넣고 있습니다.
        
        replace_if는 범위 안의 객체 중에 어떤 술어 구문에 제시된 조건을 만족하는 객체를 변경한다는 인상을 바로 풍깁니다.
        
        partition은 또 어떻습니까. 조건을 만족하는 객체와 그렇지 않은 객체를 따로 분리하여 모아둘 것이란 느낌을 주지 않습니까?(항목 31 참조)
        
        반면, for, while, do를 보면 '아, 어떤 루프가 나오겠구나'란 생각은 바로 나옵니다. 하지만 그 루프가 무엇을 하는지 파악하려면 처음부터 죽 살펴보아야 할걸요?
        
        간단히 말해, 알고리즘의 이름은 자신의 동작을 그대로 말해 주지만, "for", "while", "do"는 그렇지 않습니다.

      • 하지만 루프를 써서 만든 코드가 알고리즘보다 명확할 수 있는 경우도 있습니다.

        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // x보다 크고 y보다 작은 첫 번째 값을
        3. // 벡터에서 찾고 싶다고 가정합시다.
        4.  
        5. // 루프로는 이렇게 되겠죠.
        6.  
        7. vector<int> v;
        8. int x, y;
        9. ...
        10. vector<int>::iterator i = v.begin(); // v.begin()부터 시작하여
        11. for (; i != v.end(); ++i) { // 원하는 값을 찾든가 v.end()에
        12. if (*i > x && *i < y) break; // 올 때까지 루프를 돕니다.
        13. }
        14. ... // i는 원하는 값을 가리키든가
        15. // v.end()와 같습니다.
        16.  
        17.  
        18. //-----------------------------------------------------------------------------
        19. // 루프로 되는 일은 알고리즘으로도
        20. // 할 수 있습니다.
        21.  
        22. // find_if를 쓰면 동일한
        23. // 로직의 구현이 가능합니다.
        24.  
        25. // 하지만 이 경우에는 SGI의
        26. // compose2라는 비표준 함수 객체
        27. // 어댑터(항목 50 참조)를 사용
        28. // 해야 합니다.
        29.  
        30. vector<int> iterator i =
        31. find_if(v.begin(), v.end(), // val > x와
        32. compose2(logical_and<bool>(), // val < y의 "and" 결과가
        33. bind2nd(greater<int>(), x), // true인 첫 번째 값
        34. bind2nd(less<int>(), y))); // val을 벡터 v에서
        35. // 찾습니다.
        36.  
        37. // 비표준 컴포넌트를 사용하지 않아도
        38. // 이 문장은 명확성과는 동떨어진
        39. // 코드라고 할 수 있습니다
        40. // (항목 47 참조).
        41.  
        42. // 앞의 find_if 호출문의 값을 검사하는
        43. // 로직을 떼어서 별도의 함수자 클래스에다가
        44. // 모아두면 규모를 줄일 수 있긴 합니다.
        45.  
        46. template <typename T>
        47. class BetweenValues:
        48. public unary_function<T, bool> { // 항목 40을 보세요.
        49. public:
        50. BetweenValues(const T& lowValue,
        51. const T& highValue) // 생성자(ctor)를 써서
        52. : lowVal(lowValue), highVal(highValue) // 최소 최대값을 지정합니다.
        53. {}
        55. bool operator()(const T& val) const // 지정한 최소 최대값
        56. { // 사이에 val이 있는지의
        57. return val > lowVal && val < highVal; // 여부를 반환합니다.
        58. }
        60. private:
        61. T lowVal;
        62. T highVal;
        63. };
        64. ...
        65. vector<int> iterator i = find_if(v.begin(), v.end(),
        66. BetweenValues<int>(x, y));
        67.  
        68. // 하지만 이 방법은 그 자체에 약점을
        69. // 가지고 있습니다.
        70.  
        71. // 우선, BetweenValues 템플릿 만들기가
        72. // 루프를 직접 작성하는 것보다 일이 더
        73. // 많습니다.
        74.  
        75. // 그냥 줄만 세어 보아도 압니다.
        76.  
        77. // 둘째로, find_if가 찾고자 하는 것의
        78. // 상세한 사항이 find_if 호출문에
        79. // 빠져 있습니다.
        80.  
        81. // 즉, 이 문장이 어떤 일을 하는지
        82. // 파악하려면 BetweenValues 템플릿을
        83. // 찾아봐야 한단 말인데, BetweenValues
        84. // 은 find_if 호출문을 가지고 있는
        85. // 함수의 바깥 부분에서 선언되어야
        86. // 합니다.
        87.  
        88. // 다음과 같이 BetweenValues을 안쪽
        89. // 부분에서 선언해 보려고 하면,
        90.  
        91. { // 함수의 시작
        92. ...
        93. template <typename T>
        94. class BetweenValues: public unary_function<T, bool> { ... };
        95. vector<int>::iterator i = find_if(v.begin(), v.end(),
        96. BetweenValues<int>(x, y));
        97. ...
        98. } // 함수의 끝
        99.  
        100. // 당연히 컴파일 에러를 보게 됩니다.
        101.  
        102. // 템플릿은 함수 안에서 선언될 수
        103. // 없기 때문이지요.
        104.  
        105. // 그렇다고 BetweenValues를 템플릿이
        106. // 아닌 클래스로 만들어 버리면,
        107.  
        108. { // 함수의 시작
        109. ...
        110. class BetweenValues: public unary_function<int, bool> { ... };
        111. vector<int>::iterator i = find_if(v.begin(), v.end(),
        112. BetweenValues(x, y));
        113. ...
        114. } // 함수의 끝
        115.  
        116. // 아직 운과 여러분은 거리가 멀다는 사실을
        117. // 재확인하게 됩니다.
        118.  
        119. // 왜냐하면, 함수 안에서 정의된 클래스는
        120. // 지역 클래스(local class)로 간주되는데,
        121. // 이 지역 클래스 타입은 템플릿의 타입
        122. // 매개 변수로 쓰일 수가 없기 때문입니다.

        
        
        예제 코드 접기
        
        
        코드의 명확성의 근본은 여러분이 루프에서 무엇을 할 것인가에 달려 있다고 봅니다.
        
        알고리즘이 이미 제공하고 있거나 알고리즘이 제공하는 동작과 상당히 비슷한 일을 해야 한다면 알고리즘을 쓰는 것이 명확합니다.
        
        루프로는 꽤 간단한 작업인데, 알고리즘으로는 바인더나 어댑터를 비비 꼬거나 별도의 함수자를 만들어야 한다면 루프가 좋습니다.
        
        마지막으로, 루프로는 상당히 길고 복잡한 작업을 해야 한다면 알고리즘을 써서 규모를 줄일 수 있습니다. 왜냐하면, 길고 복잡한 연산은 대개 별도의 함수에 옮겨 놓을 수 있으니까요.
        
        이렇게 루프의 몸체를 옮긴 함수를 알고리즘에 넘기는 식으로 코드를 만들면 어느 정도 직관적이고 명확한 코드를 만들 수 있습니다.

  44. ★ 같은 이름을 가진 것이 있다면 일반 알고리즘 함수보다 멤버 함수가 더 낫다 / 282

      • 컨테이너 관련 문서를 보면 STL 알고리즘과 같은 이름을 가진 멤버 함수를 찾을 수 있습니다. 연관 컨테이너는 count, find, lower_bound, upper_bound, equal_range를 제공하는가 하면, list는 remove, remove_if, unique, sort, merge, reverse를 제공하지요.

        항목의 제목에서 제대로 느낄 수 있듯이 같은 이름의 알고리즘보다는 멤버 함수가 낫습니다.
        
        여기에는 두 가지 이유가 있는데요, 첫째는 멤버 함수가 빠르다는 점, 둘째는 멤버 함수는 해당 컨테이너와 더 잘 맞물려 있다는 점입니다(특히 연관 컨테이너는 더욱 그렇습니다).
        
        이는, 같은 이름을 가진 알고리즘과 멤버 함수는 대개 정확히 똑같은 동작을 하진 않기 때문입니다.

      • 표준 연관 컨테이너에서는 알고리즘보다 멤버 함수를 사용하면 몇 가지 이득을 얻을 수 있습니다. 우선 선형 시간이 아닌 로그 시간의 수행 성능이 그 첫째요, 연관 컨테이너에서 자연스럽게 통하는 동등성 검사를 그대로 사용할 수 있다는 점이 둘째요, 맵이나 멀티맵의 경우 자동으로 키 부분만 다루게 된다(페어 전체가 아니라)는 점이 셋째입니다.

        예를 들어 백 만 개의 정수 값을 가진 set<int>가 있고 여기서 727이란 값이 어디에 있는지 찾고 싶습니다.
        
        이 탐색을 수행하는 방법에는 두 가지가 있겠죠. 하나는 set의 멤버 함수를 사용하는 것이고, 다른 하나는 STL 알고리즘을 사용하는 것입니다.
        
        예제 코드 보기
        
        
        

        1. set<int> s; // 셋을 만들고,
        2. ... // 1,000,000 개의 값을
        3. // 여기에 넣습니다.
        4.  
        5. set<int>::iterator i = s.find(727); // find 멤버 함수를
        6. if (i != s.end()) ... // 사용합니다.
        7.  
        8. set<int>::iterator i = find(s.begin(), s.end(), 727); // find 알고리즘을
        9. if (i != s.end()) ... // 사용합니다.
        10.  

        
        
        예제 코드 접기
        
        
        find 멤버 함수는 로그 시간에 실행됩니다. 따라서 727이란 값이 있든 말든 많아봐야 약 40번, 평균 약 20번의 비교만에 탐색이 완료됩니다.
        
        반면, find 알고리즘은 선형 시간에 실행되기 때문에 727이 들어 있지 않으면 백만번의 비교를 수행해야 하고, 들어 있다 쳐도 평균 500,000번의 비교를 해야 합니다.
        
        항목 19에서 이미 이야기했듯이, STL 알고리즘은 두 개의 객체가 같은 값을 가지고 있는지 판단할 때 상등성(equality)을 기준으로 삼지만 연관 컨테이너는 동등성(equivalence)을 기준으로 삼습니다.
        
        이런 미묘한 차이 때문에, 연관 컨테이너에 find 알고리즘을 적용했을 때 헤매는 예(find 멤버를 쓰면 제대로 찾는데도 불구하고)를 항목 19에서 찾아볼 수 있습니다.
        
        결국 연관 컨테이너를 써서 프로그래밍 할 때에는 find, count, lower_bound 등의 작업은 알고리즘 대신에 멤버 함수를 사용하는 것이 좋다 이겁니다. 그 컨테이너의 다른 멤버 함수와 제대로 맞물려 동작하기 때문이죠.
        
        이 차이는 map과 multimap을 가지고 프로그래밍할 때에 특히 두드러집니다.
        
        이 컨테이너는 pair 객체를 저장하고 있고, 각 멤버 함수는 pair 객체의 키(key) 부분만을 고려하기 때문이지요.
        
        하지만, 알고리즘은 (a)상등성을 기준으로 삼고 (b)페어에 들어 있는 두 개의 멤버를 전부 고려한 탐색을 수행합니다.
        
        알고리즘이 페어의 키 부분만 고려하도록 하려면 항목 23으로 다시 가셔야 합니다(상등성 검사를 동등성 검사로 대체할 수 있는 경우를 설명해 두었습니다).
        
        그런데, 여러분이 진짜로 효율에 신경을 쓰고 계시다면, 항목 23의 기법과 항목 34의 로그 시간 탐색 일고리즘을 합치는 일을 염두에 두셔야 할 것입니다.
        
        또 그래도 정녕 효율이 필요하다고 생각된다면 항목 25에서 이야기한 비표준 해쉬 컨테이너도 쓰셔야 할 거구요.

      • list의 경우에도 동명의 알고리즘을 호출하는 것보다 멤버 함수를 호출하는 편이 효율적입니다. 게다가 list의 멤버 함수는 같은 이름의 알고리즘과 다르게 동작하는 경우가 적지 않다는 점도 꼭 기억해 두어야 합니다.

        list를 가지고 동작하는 동명의 알고리즘(remove, remove_if, unique, sort, merge, reverse)은 객체를 복사하지만, list 전용 멤버 함수는 복사를 전혀 하지 않습니다. 그냥 리스트 노드를 연결하는 포인터를 이리저리 조작할 뿐이죠.
        
        알고리즘과 list 멤버 함수의 알고리즘적 복잡도는 똑같지만, 포인터 조작이 객체 복사보다 빠르다는 사실은 삼척동자도 아는 사실입니다.
        
        항목 32에서 이야기하고 있듯, 컨테이너에서 진짜로 객체를 제거하려면 remove, remove_if, unique 알고리즘만 호출해서는 안되고 erase를 반드시 붙여 주어야 합니다.
        
        하지만 list의 remove, remove_if, unique 멤버 함수는 자신이 객체를 없애줍니다. erase가 불필요하단 말이지요.
        
        정렬 동작에 대해서도 차이가 납니다. sort 알고리즘과, list의 sort 멤버 함수의 중대한 차이는 전자의 것은 list에 적용할 수 없다는 사실입니다. list의 반복자는 양방향 반복자이기 때문에 애초부터 sort 알고리즘에 넘길 수가 없습니다.
        
        merge 알고리즘과 list의 merge 멤버 함수 사이의 거리도 심오하게 깁니다. 알고리즘 버전은 작업 대상이 되는 범위를 건드릴 수 없지만, list::merge는 항상 거리낌없이 바꿉니다.

  45. count, find, binary_search, lower_bound, upper_bound, 그리고 equal_range를 제대로 파악해 두자 / 286

      • 컨테이너에서 어떤 값을 찾고 싶을 때, cout, count_if, find, find_if, binary_search, lower_bound, upper_bound를 사용할 수 있습니다.

        이후부터는 count나 find 같은 _if의 변종을 가진 알고리즘은 _if를 생략하겠습니다. 술어 구문을 받아들이는 binary_search, lower_bound와 upper_bound, equal_range의 변종도 무시하겠습니다.
        
        기본으로 주어지는 탐색 술어 구문을 쓰느냐, 여러분이 만든 것을 쓰느냐에 상관없이 탐색 알고리즘의 선택 기준은 똑같기 때문입니다.

      • 탐색 전략의 선택은 반복자가 정렬된 범위를 지정하고 있느냐에 상당 부분이 걸려 있습니다. 만일 그렇다면 binary_search, lower_bound, upper_bound, equal_range 등의 알고리즘(대개 로그 시간에 수행됩니다. 항목 34를 참고하세요)을 써서 높은 속도를 얻을 수 있습니다.

        정렬되지 않은 범위가 정렬된다는 것은 정렬 이외의 또 하나의 변화를 뜻합니다. 두 개의 값이 같은지를 비교할 때 사용되던 상등성(equality) 기준이 동등성(equivalence)으로 바뀐다는 것이죠(항목 19 참조).
        
        count나 find 알고리즘은 상등성을 가지고 탐색하는 반면, binary_search, lower_bound, upper_bound, equal_range는 동등성을 사용한다는 사실만 주의하시면 됩니다.

      • 하지만 정렬된 범위가 아니라면 선형 시간의 알고리즘인 count나 find 밖에 사용할 수 없습니다.

        count는 이런 물음에 답해 줍니다. "제가 찾는 값이 있나요? 있다면 몇 개나 있나요?" 하지만, find가 답하는 물음은 이렇습니다. "제가 찾는 값이 있나요? 있다면 어디에 있나요?"
        
        값의 존재 여부를 점검하는 목적으로는 count를 사용한 코드가 약간 더 간단합니다. 그와 동시에 탐색이 성공했을 때 효율이 좋지 않아서 문제죠.
        
        왜냐하면, find는 탐색이 성공하면 바로 끝내지만, count는 같은 값이 더 있는지를 찾기 위해 범위의 끝까지 갑니다.
        
        대부분의 프로그래머라면 약간 복잡하더라도 효율적인 find를 선택하는데 주저하지 않을 것입니다.
        
        어떤 값을 가진 객체의 존재 여부 뿐만 아니라, 그 객체 자체에 대해 알고 싶다면 find가 해답입니다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // w와 같은 값을 가진 Widget 객체가
        3. // list 안에 있는지가 궁금하다고
        4. // 가정합시다.
        5.  
        6. // count를 써서 코드를 만들면 다음과
        7. // 같겠지요.
        8.  
        9. list<Widget> lw; // Widget 객체의 리스트
        10. Widget w; // 특별한 Widget 값
        11. ...
        12. if (count(lw.begin(), lw.end(), w)) {
        13. ... // w는 lw에 들어 있습니다.
        14. }
        15. else {
        16. ... // 들어 있지 않습니다.
        17. }
        18.  
        19. // count는 0(false) 혹은 양수(true)를
        20. // 반환한다는 사실을 이용한 코드입니다.
        21.  
        22. // 좀 더 명확하게 다음과 같이 쓸 수도 있습니다.
        23.  
        24. if (count(lw.begin(), lw.end(), w) != 0) ...
        25.  
        26. // 하지만, 원래의 예제 코드처럼 내부적으로
        27. // 해석하는 것이 더 보편적입니다.
        28.  
        29.  
        30. //-----------------------------------------------------------------------------
        31. // find를 사용한 코드는 조금 더 복잡합니다.
        32.  
        33. if (find(lw.begin(), lw.end(), w) != lw.end()) {
        34. ... // w는 lw에 들어 있습니다.
        35. }
        36. else {
        37. ... // 들어 있지 않습니다.
        38. }
        39.  
        40.  
        41. //-----------------------------------------------------------------------------
        42. // 원하는 값을 가진 Widget 객체가
        43. // 컨테이너에 들어있는지의 여부 뿐만 아니라
        44. // 그 객체의 위치까지 알고 싶다면 find를
        45. // 써야 합니다.
        46.  
        47. list<Widget>::iterator i = find(lw.begin(), lw.end(), w);
        48. if (i != lw.end()) {
        49. ... // 찾았습니다. i는 첫 번째 객체를 가리킵니다.
        50. }
        51. else {
        52. ... // 못 찾았습니다.
        53. }

        
        
        예제 코드 접기
        
        
        

      • 정렬된 범위에서 어떤 값이 있는지를 알아 보는데에는 binary_search가 그만입니다. 표준 C 라이브러리의 bsearch와 달리, binary_search는 값이 있는지, 없는지를 나타내는 bool 값만을 반환합니다.

        만약에 이외의 정보가 더 필요하다면 다른 알고리즘을 사용해야 합니다. 다음의 예제는 binary_search가 정렬된 벡터에 적용될 때의 코드입니다(정렬된 벡터의 미덕은 항목 23에서 읽으시기 바랍니다).
        
        binary_search 예제 코드 보기
        
        
        

        1. vector<Widget> vw; // 벡터를 만들고,
        2. ... // 데이터를 넣고,
        3. sort(vw.begin(), vw.end()); // 벡터를 정렬합니다.
        4.  
        5. Widget w; // 우리가 찾을 값
        6. ...
        7. if (binary_search(vw.begin(), vw.end(), w)) {
        8. ... // w가 vw 안에 있습니다.
        9. }
        10. else {
        11. ... // 없습니다.
        12. }

        
        
        binary_search 예제 코드 접기
        
        
        

      • 정렬된 범위가 있고 그 안에서 특정 값을 갖는 객체의 위치를 찾고 싶다면, equal_range가 우선적인 답입니다만, lower_bound도 고려해 보는 것이 좋습니다. equal_range를 알아보기 전에 lower_bound부터 알아봅시다.

        값을 찾는 데에 lower_bound를 호출하면, 이 알고리즘은 원하는 값을 가진 객체의 첫째 사본(찾았을 때) 아니면 그 값이 삽입될 적당한 위치(찾지 못했을 때)를 가리키는 반복자를 반환합니다.
        
        find와 마찬가지로, lower_bound의 결과(반복자)가 여러분이 원하는 값을 제대로 가리키고 있는지 점검해야 하는데요, 이 경우에는 반복자가 가리키는 객체가 여러분이 원하던 값을 가리키고 있는지를 점검하면 됩니다.
        
        이 때 많은 분들이 상등성 검사를 해서 점검을 하더군요. 많은 경우 상등성 검사를 해도 문제가 없지만, 항목 19에서 볼 수 있듯이 상등성 검사와 동등성 검사의 결과가 얼마든지 달라질 수 있습니다.
        
        따라서 상등성 검사 대신 동등성 검사를 하는 것이 맞다고 할 수 있습니다(항목 19에는 그 방법이, 항목 24에는 그렇게 해도 괜찮은 예가 설명되어 있습니다).
        
        한 가지 주의해야 할 점은, 동등성 검사를 할 때 lower_bound에서 사용된 것과 똑같은 비교 함수를 써야 한다는 것입니다.
        
        lower_bound 예제 코드 보기
        
        
        

        1. vector<Widget>::iterator i = lower_bound(vw.begin(), vw.end(), w);
        2. if (i != vw.end() && *i == w) { // i가 객체를 가리키고 있는지 확인합니다;
        3. // 그 객체가 원하는 값을 가지고 있는지
        4. // 확인해야 하죠. 이 코드엔 버그가 있습니다!
        5.  
        6. ... // 있는 첫째 객체를 가리킵니다.
        7. }
        8. else {
        9. ... // 못 찾았습니다.
        10. }
        11.  
        12. // 위의 코드에서 다음 부분을 잘 보면
        13.  
        14. if (i != vw.end() && *i == w) ...
        15.  
        16. // 상등성 검사를 하고 있는 것을 볼 수
        17. // 있습니다.
        18.  
        19. // 이렇게 하면 대개 맞지만, 원하지 않는
        20. // 동작을 할 가능성도 있습니다.
        21.  
        22. // 따라서 다음과 같이 동등성 검사를
        23. // 하는 것이 정확합니다.
        24.  
        25. if (i != vw.end() && !(less<Widget>()(w, *i))) ...
        26.  

        
        
        lower_bound 예제 코드 접기
        
        
        

      • lower_bound보다 좀 더 쉬운 방법은 equal_range를 쓰는 것입니다. equal_range는 반복자 쌍으로 구성된 pair 객체를 반환하는데, 첫째 반복자는 lower_bound가 반환하는 그것과 같고, 둘째 반복자는 upper_bound가 반환하는 그것(찾고자하는 것과 동등한 값을 가진 범위의 끝의 바로 다음)과 같습니다.

        말하자면 여러분이 찾고자 하는 것과 동등한 값의 범위를 지정하는 두 개의 반복자를 내어주는 알고리즘이 equal_range인 것입니다.
        
        equal_range의 반환값은 두 가지의 중요한 의미를 갖습니다. 첫째로, 두 반복자가 같으면 그 범위 안에 아무 것도 없다는 뜻입니다. 동등한 값을 못 찾은 거죠. "원하는 값이 있나요?"라는 의문이 있을 때 이것을 쓰면 됩니다.
        
        두 번째 의미는, 두 반복자 사이의 거리(distance)를 구하면 범위 내의 객체의 개수가 나온다는 것입니다. 우리가 찾고자 하는 값과 동등한 값을 가진 객체의 개수죠.
        
        equal_range 예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // 컨테이너에 찾고자 하는 값이 들어있는지의
        3. // 여부를 알아내고 싶을 때는, equal_range가
        4. // 반환한 두 반복자가 같은지를 비교하면
        5. // 됩니다.
        6.  
        7. vector<Widget> vw;
        8. ...
        9. sort(vw.begin(), vw.end());
        10. typedef vector<Widget>::iterator VWIter; // 다시 보아도 편리한 typedef
        11. typedef pair<VWIter, VWIter> VWIterPair;
        12. VWIterPair p = equal_range(vw.begin(), vw.end(), w);
        13. if (p.first != p.second) { // equal_range가 빈 범위를
        14. // 반환하지 않았다면...
        15.  
        16. ... // 값을 찾은 것입니다. p.first는
        17. // 시작을, 그리고 p.second는
        18. // 끝 바로 다음을 가리킵니다.
        19. }
        20. else { // 못 찾았습니다. p.first와
        21. ... // p.second는 모두 우리가
        22. // 찾고자 하는 삽입 위치를
        23. } // 가리키고 있습니다.
        24.  
        25.  
        26. //-----------------------------------------------------------------------------
        27. // 컨테이너에 찾고자 하는 값이 몇 개나
        28. // 들어있는지를 알아보려면, equal_range가
        29. // 반환한 두 반복자의 거리를 구하면
        30. // 됩니다.
        31.  
        32. VWIterPair p = equal_range(vw.begin(), vw.end(), w);
        33. cout << "There are " << distance(p.first, p.second)
        34. << " elements in vw equivalent to w.";
        35.  

        
        
        equal_range 예제 코드 접기
        
        
        

      • 범위 내의 위치를 찾고자 하는 경우에도 lower_bound나 upper_bound를 쓸 수 있습니다.

        예를 하나 들죠. Timestamp란 클래스로 만든 벡터(vt)가 하나 있는데, 이 벡터는 오래된 타임스탬프 값이 먼저 오도록 정렬되었다고 가정합시다.
        
        그리고 ageLimit이란 문제의 타임스탬프를 하나 만들죠. 그리고 이 ageLimit보다 오래된 타임스탬프를 모두 vt에서 없애고자 합니다.
        
        이 경우는 정확한 값을 가진 요소가 하나도 없기 때문에, vt에서 ageLimit과 동등한 Timestamp를 찾는 것이 아닙니다. 그 대신에 ageLimit보다 오래 되지 않은 첫 번째 요소의 위치를 찾고 싶은 것이죠.
        
        이럴때 vt.begin()과 lower_bound(vt.begin(), vt.end(), ageLimit)가 반환한 반복자 사이의 값을 모두 erase하면 됩니다.
        
        생각이 조금 바뀌어 ageLimit만큼 오래된 타임스탬프를 모두 없애고 싶다면, lower_bound 대신 upper_bound를 쓰면 간단히 해결됩니다.
        
        upper_bound는 정렬된 범위에 객체를 삽입할 때 동등한 값을 가진 것들은 삽입된 순서대로 지정되도록 할 때에도 멋지게 쓸 수 있습니다.
        
        예제 코드 보기
        
        
        

        1. //-----------------------------------------------------------------------------
        2. // Timestamp란 클래스로 만든 벡터가
        3. // 하나 있고, 이 벡터는 오래된 타임스탬프
        4. // 값이 먼저 오도록 정렬됩니다.
        5.  
        6. class Timestamp { ... };
        7. bool operator<(const Timestamp& lhs, // lhs가 rhs보다 시간적으로
        8. const Timestamp& rhs); // 앞서 있는지의 여부를 반환합니다.
        9.  
        10. vector<Timestamp> vt; // 벡터를 만들고, 데이터를 넣은
        11. ... // 후에, 오래된 것이 먼저 오도록
        12. sort(vt.begin(), vt.end()); // 이 벡터를 정렬합니다.
        13.  
        14. // 이제 타임스탬프 ageLimit를 만들고
        15. // 이 ageLimit보다 오래 된
        16. // 타임스탬프를 모두 지우려고 합니다.
        17.  
        18. // lower_bound를 쓰면 간단히 만들 수 있습니다.
        19.  
        20. Timestamp ageLimit;
        21. ...
        22. vt.erase(vt.begin(), lower_bound(vt.begin(), // vt에서, ageLimit보다
        23. vt.end(), // 오래 된 것들을 모두
        24. ageLimit)); // 없앱니다.
        25.  
        26. // 최소한 ageLimit만큼 오래된 타임스탬프를
        27. // 모두 없애고 싶다면, lower_bound대신
        28. // upper_bound를 씁니다.
        29.  
        30. vt.erase(vt.begin(), upper_bound(vt.begin(), // vt에서, ageLimit보다
        31. vt.end(), // 오래 되거나, 동등한
        32. ageLimit)); // 객체를 모두
        33. // 없앱니다.
        34.  
        35.  
        36. //-----------------------------------------------------------------------------
        37. // 정렬된 범위에 객체를 삽입할 때
        38. // 동등한 값을 가진 것들은 삽입된
        39. // 순서대로 저장되도록 할 때에도
        40. // upper_bound를 쓸 수 있습니다.
        41.  
        42. class Person {
        43. public:
        44. ...
        45. const string& name(void) const;
        46. ...
        47. };
        48.  
        49. struct PersonNameLess:
        50. public binary_function<Person, Person, bool> { // 항목 40을 보세요.
        52. bool operator()(const Person& lhs, const Person& rhs) const
        53. {
        54. return lhs.name() < rhs.name();
        55. }
        56. };
        57. list<Person> lp;
        58. ...
        59. lp.sort(PersonNameLess()); // PersonNameLess를 써서
        60. // lp를 정렬합니다.
        61.  
        62. Person newPerson;
        63. ...
        64. lp.insert(upper_bound(lp.begin(), // newPerson의 앞에
        65. lp.end(), // 오든지 동등한
        66. newPerson, // 객체중 가장 마지막
        67. PersonNameLess()), // 것의 뒤에다가 newPerson
        68. newPerson); // 을 삽입합니다.
        69.  

        
        
        예제 코드 접기
        
        
        

      • 하지만 list를 쓰는 경우에는 binary_search, lower_bound, upper_bound, equal_range 알고리즘이 로그 시간만에 동작한다는 기대를 가져서는 안됩니다. 항목 34를 읽어보시면 알 수 있는데, list를 가지고 돌리는 알고리즘이기 때문에 비교는 로그 시간에 이루어지지만, 탐색은 선형 시간에 이루어지거든요. 결과적으로 선형 시간에 이루어지게 됩니다.

      • 표준 시퀸스 컨테이너(vector, string, deque, list)에 대해서는 지금까지 설명한 내용을 그대로 적용해도 무방합니다. 하지만, 표준 연관 컨테이너(set, multiset, map, multimap)을 쓴다면 이야기가 달라집니다. 이들은 STL 알고리즘보다 일반적으로 더 잘 쓰이는 탐색용 멤버 함수를 가지고 있기 때문이죠.

        항목 44에서 설명해 두었지만, 간단히 정리하면 이 멤버 함수들이 훨씬 빠르며 동작도 자연스럽습니다. 다행히 이들의 이름이 이에 대응하는 알고리즘과 똑같습니다.
        
        이런 전차로, 연관 컨테이너에서 탐색할 때에는 count, find, equal_range, lower_bound, upper_bound에 대해서는 똑같은 이름의 멤버 함수를 사용하는 것이 좋다는 결론이 내려지겠죠?
        
        binary_search만 예외인데, 이 알고리즘과 비슷한 멤버 함수는 없습니다. 어쨌든 set이나 map에서 어떤 값이 있는지를 알아낼 땐 count를 쓸 수 있습니다.
        
        예제 코드 보기
        
        
        

        1. set<Widget> s; // 셋을 하나 만들고 데이터를 채웁니다.
        2. ...
        3. Widget w; // w는 여전히 우리가 찾고자 하는 값을 가집니다.
        4. ...
        5. if (s.count(w)) {
        6. ... // w와 동등한 값이 존재합니다.
        7. }
        8. else {
        9. ... // 존재하지 않습니다.
        10. }

        
        
        예제 코드 접기
        
        
        multiset이나 multimap에서 어떤 값이 있는지 알아보는 데에는 count보다 find가 일반적으로 좋습니다. find는 값을 찾으면 바로 멈추는 반면에, count는 최악의 경우에 컨테이너 안의 모든 객체를 일일이 찾게 됩니다.
        
        하지만 연관 컨테이너에서 count로 객체 세기(counting)는 매우 안정적입니다. 특히 equal_range가 반환하는 두 반복자의 거리를 구하는 것보다 더 좋습니다.
        
        첫째로, count가 더 명확합니다. 둘째로, 더 쉽습니다. 셋째로, 아마도 count가 더 빠를 것입니다.

      • 자, 여기까지 왔습니다. 이젠 정리할 시간이죠? 다음의 표를 보시기 바랍니다.

        표 보기
        
        
        

        
        
        표 접기
        
        
        표에서 정렬된 범위에 대한 열(column)을 살펴보면, equal_range의 개수가 조금 놀랍습니다. 탐색할 때에는 동등성 검사가 그만큼 중요하게 여겨진다는 의미이겠지요.
        
        lower_bound와 upper_bound는 상등성 검사(equality test)를 사용하기 쉽습니다. 하지만 equal_range의 경우는 동등성 검사만이 자연스럽게 쓰일 수 있지요.
        
        그리고, 정렬된 범위에 대한 둘째 행을 보세요. equal_range가 find를 압도하는 또 다른 요인은 equal_range는 로그 시간에 수행되지만, find는 선형 시간이 소요된다는 점입니다.
        
        multiset과 multimap에 대해서는 find와 lower_bound가 여러분이 원하는 값을 가진 첫째 객체를 찾을 때 적합하다는 결론을 내릴 수 있겠습니다.
        
        find는 set과 map에서 제 구실을 합니다. multi- 버전에서는, 동등한 객체가 두 개 이상 있을 때에는 find를 호출한다고 해서 원하는 결과를 얻는다는 보장을 할 수 없습니다.
        
        이 중에서 하나를 골라 내야 하는데, 진짜로 원하는 값을 가진 첫째 객체를 찾아내려면 lower_bound를 호출해야 합니다.
        
        이때, 원하는 값이 그 값인지를 확인하는 용도로 항목 19에서 설명한 동등성 검사의 두 번째 부분을 직접 구현해야 합니다(equal_range를 쓰면 자동으로 되긴 하지만, lower_bound를 호출했을 때보다 비용이 많이 듭니다).

      • count, find, binary_search, lower_bound, upper_bound, equal_range 중에서 무엇을 선택할지 선택하는 일은 지극히 쉽습니다. 눈을 감고 여러분이 원하는 동작과 수행성능을 가지며 호출시의 비용이 가장 적게 드는 것을 선택하면 됩니다. 이 항목에서 다루었던 내용이나, 마지막에 나온 표를 참고하면 혼란에 빠질 일은 없습니다.

  46. ★ 알고리즘의 매개 변수로는 함수 대신 함수 객체가 괜찮다 / 297

      • 고수준 언어로 프로그래밍하면서 느끼는 불만 중 하나가 추상화(abstraction)의 정도가 높아질수록 코드의 효율은 곤두박질 친다는 점입니다. 그러나, 예외도 있습니다. STL 함수 객체(함수로 가장한 객체)를 알고리즘에 넘기는 것이 진짜 함수를 넘기는 것보다 빠릅니다. 그 이유는 함수의 인라이닝 때문입니다.

        넘겨진 함수 객체의 operator()가 인라인 함수라면, 함수 객체의 operator()를 호출할 때 실제로는 함수 호출 과정이 일어나지 않습니다.
        
        함수를 넘길때는 함수의 포인터가 넘어가며, 이 함수 포인터를 통해 함수 호출이 이루어집니다. 그런데 이 넘겨진 함수가 인라인 함수인지 아닌지에 상관없이 함수 포인터를 통해 호출되는 함수는 인라인되지 않습니다.
        
        그 결과 함수 객체를 넘겨주는 것이 함수를 넘겨주는 것보다 훨씬 빠른 결과가 나오게 됩니다.
        
        예제 코드 보기
        
        
        

        1. // 예를 하나 볼까요?
        2.  
        3. // double의 벡터를 내림차순으로
        4. // 정렬하고 싶다고 합시다.
        5.  
        6. // STL의 정공법이라면 sort 알고리즘과
        7. // greater<double>을 함께 사용하는
        8. // 것입니다.
        9.  
        10. vector<double> v;
        11. ...
        12. sort(v.begin(), v.end(), greater<double>());
        13.  
        14. // 추상화 때문에 함수를 넘기는 것보다
        15. // 느릴 것 같습니다.
        16.  
        17. // 그래서 인라인 함수를 만들고
        18. // 함수를 넘겨 봅니다.
        19.  
        20. inline
        21. bool doubleGreater(double d1, double d2)
        22. {
        23. return d1 > d2;
        24. }
        25. ...
        26. sort(v.begin(), v.end(), doubleGreater);
        27.  
        28. // 위의 sort 호출문은 doubleGreater를
        29. // sort에 넘기지 않습니다.
        30.  
        31. // doubleGreater의 포인터를 넘기죠.
        32.  
        33. // 이 sort 템플릿이 인스턴스화될 때
        34. // 만들어지는 함수의 선언문을 한 번
        35. // 보시겠습니까?
        36.  
        37. void sort(vector<double>::iterator first, // 범위의 시작
        38. vector<double>::iterator last, // 범위의 끝
        39. bool (*comp)(double, double)); // 비교 함수
        40.  
        41. // comp는 함수 포인터이기 때문에 sort
        42. // 내부에서 사용될 때마다 간접 함수
        43. // 호출(포인터를 통한)을 매번 합니다.
        44.  
        45. // 대부분의 컴파일러는 포인터로 호출되는
        46. // 함수는 인라인으로 만들지 않습니다.
        47.  
        48. // 이 예제에는 inline이 있어서
        49. // 최적화가 될 것 같지만 절대로
        50. // 인라인으로 만들지 않습니다.
        51.  
        52. // 반면 함수 객체를 넘기는 경우에는
        53. // 함수 객체의 operator()가
        54. // 인라인이기만 하면 최적화가
        55. // 이루어집니다.
        56.  
        57. // 그래서 함수를 넘기는 것보다
        58. // 함수 객체를 넘기는 것이
        59. // 훨씬 효율적인 것이죠.

        
        
        예제 코드 접기
        
        
        인라이닝과 컴파일러 최적화에 관한 이야기는 Effective C++의 항목 30과 불카(Bulka)와 메이휴(Mayhew)가 쓴 Efficient C++[10]의 8, 10장에서 자세히 공부할 수 있습니다.
        
        이런 이유로 C++의 sort가 C의 qsort보다 속도에서 당황스럽게 앞서게 됩니다. 백 만 개의 double을 가진 벡터를 써서 실험해보았더니 C++의 sort가 C의 qsort보다 무려 670%나 빨랐습니다(플랫폼마다 다를 수 있으니 그대로 듣지 마시고 직접 해보세요).

      • 알고리즘의 매개 변수로 진짜 함수보다 함수 객체를 선호하는 데에는 다른 이유도 있습니다. 효율과는 상관이 없고, 프로그램 컴파일과 상관이 있는 이유입니다. 어떤 구실을 막론하고 STL 플랫폼에서 완벽하게 유효한 코드를 거부하는 경우가 생길 수 있거든요.

        이는 컴파일러나 라이브러리 중에 하나 혹은 모두가 엉터리일 수 있기 때문입니다. 가장 폭넓게 사용되는 STL 플랫폼을 예로 들지요. 셋에 저장된 string 객체의 길이를 출력하는 다음의 코드를 거부한다네요. 맞는데도 말이죠.
        
        예제 코드 보기
        
        
        

        1. set<string> s;
        2. ...
        3. transform(s.begin(), s.end(),
        4. ostream_iterator<string::size_type>(cout, "\n"),
        5. mem_fun_ref(&string::size));
        6.  
        7. // 문제의 원인은 이 STL 플랫폼이 const
        8. // 멤버 함수(string::size)를 처리하는데
        9. // 버그를 가지고 있다는 점입니다.
        10.  
        11. // 이 문제를 해결하려면 함수 객체로
        12. // 대신해야 합니다.
        13.  
        14. struct StringSize:
        15. public unary_function<string, string::size_type> {
        17. string::size_type operator()(const string& s) const
        18. {
        19. return s.size();
        20. }
        21. };
        22. transform(s.begin(), s.end(),
        23. ostream_iterator<string::size_type>(cout, "\n"),
        24. StringSize());
        25.  

        
        
        예제 코드 접기
        
        
        

      • 진짜 함수보다 함수 객체를 선호하는 또 한 가지 이유는 함수 객체가 미묘한 언어 문제를 막아 줄 수 있다는 점입니다.

        프로그래밍을 하다 보면, 맞는 것 같아 보이는 소스 코드를 컴파일러는 애매한 이유를 대며 거부하는 바람에 환장하는 일이 더러 있습니다. 예를 들어, 함수 인스턴스 이름이 함수의 이름과 같지 않은 경우도 여기에 속합니다. 다음의 코드를 보시지요.
        
        예제 코드 보기
        
        
        

        1. template <typename FPType>
        2. FPType average(FPType val1, FPType val2)
        3. {
        4. return (val1 + val2) / 2;
        5. }
        6.  
        7. template <typename InputIter1,
        8. typename InputIter2>
        9. void writeAverage(InputIter1 begin1,
        10. InputIter1 end1,
        11. InputIter2 begin2,
        12. ostream& s)
        13. {
        14. transform(
        15. begin1, end1, begin2,
        16. ostream_iterator<typename iterator_traits<InputIter1>::value_type>(s, "\n"),
        17. average<typename iterator_traits<InputIter1>::value_type> // 에러인가?
        18. );
        19. }
        20.  
        21. // 이 코드는 많은 컴파일러들이 받아들입니다만,
        22. // 참으로 야속하게 C++ 표준안에서 이것을
        23. // 금지하고 있답니다.
        24.  
        25. // 이유인즉, 이론적으로 타입 매개 변수를
        26. // 하나 가지고 있는 average란 이름의
        27. // 다른 함수 템플릿이 존재할 수 있다는
        28. // 것이라는군요.
        29.  
        30. // 만일 그렇다면 average<typename iterator_traits<InputIter1>::value_type>은
        31. // 애매한 표현식일 수 있습니다.
        32.  
        33. // 결국 문제를 해결하는 방법은 역시
        34. // 함수 객체에 의존하는 것입니다.
        35.  
        36. template <typename FPType>
        37. struct Average:
        38. public binary_function<FPType, FPType, FPType> {
        40. FPType operator()(FPType val1, FPType val2) const
        41. {
        42. return average(val1, val2);
        43. }
        44. };
        45.  
        46. template <typename InputIter1, typename InputIter2>
        47. void writeAverage(InputIter1 begin1, InputIter1 end1,
        48. InputIter2 begin2, ostream& s)
        49. {
        50. transform(
        51. begin1, end1, begin2,
        52. ostream_iterator<typename iterator_traits<InputIter1>::value_type>(s, "\n"),
        53. Average<typename iterator_traits<InputIter1>::value_type>()
        54. );
        55. }
        56.  
        57. // 이렇게 고친 코드는 모든 컴파일러가 받아들일
        58. // 뿐만 아니라, transform 안에서 호출되는
        59. // Average::operator()는 인라이닝 대상입니다.
        60.  
        61. // average는 꿈도 못 꿀 일이죠. average는
        62. // 함수 템플릿이지, 함수 객체가 아니잖아요.

        
        
        예제 코드 접기
        
        
        

  47. 쓰기 전용(write-only) 코드는 만들지 말자 / 302

      • 쓰기 전용 코드란, 쓰기에는 쉽지만 읽고 이해하는데는 머리에 쥐가 나는, 그런 코드를 말합니다. 당연히 유지보수에 악영향을 주기 때문에 바람직하지 못합니다.

        코드를 쓰기보다는 읽기를 더 많이 하는 것이 소프트웨어 공학의 본질이요 이치입니다. 소프트웨어는 개발보다 유지보수에 더 많은 시간이 들어갑니다.
        
        읽기에 거북하고 이해하기 힘든 소프트웨어는 유지보수가 그만큼 어렵고, 유지 보수가 불가능한 소프트웨어는 있을 가치가 없습니다.
        
        꼭 기억해 두세요. 여러분이 오늘 작성한 코드는 언젠가 다른 사람들(여러분 자신일 수도 있습니다)이 읽을 거라는 사실을요.
        
        예제 코드 보기
        
        
        

        1. // vector<int>가 하나 있습니다.
        2.  
        3. // 이 벡터에서 x보다 작은 값을 모두 지우고
        4. // 싶은데, y보다 크거나 같은 값 중 가장
        5. // 마지막 것의 앞에 있는 것들은 모두 그대로
        6. // 두려고 합니다.
        7.  
        8. // 그리하여 다음의 코드를 만들었습니다.
        9.  
        10. vector<int> v;
        11. int x, y;
        12. ...
        13. v.erase(
        14. remove_if(find_if(v.rbegin(), v.rend(),
        15. bind2nd(greater_equal<int>(), y)).base(),
        16. v.end(),
        17. bind2nd(less<int>(), x)),
        18. v.end()
        19. );
        20.  
        21. // 이 코드가 주목을 받는 이유는 두 가지가
        22. // 있습니다.
        23.  
        24. // 먼저, 이 코드는 중첩된 함수 호출의
        25. // 극치를 보입니다.
        26.  
        27. // Lisp 류(함수식 언어) 프로그래밍을
        28. // 해보지 않은 대다수의 사람들은
        29. // 이와 같은 코드를 읽는것이
        30. // 익숙하지 않을 것입니다.
        31.  
        32. // 두 번째 이유는, STL에 대한 심오한 이해를
        33. // 필요로 한다는 것입니다.
        34.  
        35. // 베테랑 STL 프로그래머들이야 별 어려움 없이
        36. // 이런 조합을 소화할 수 있겠지만, 훨씬 많은
        37. // C++ 개발자는 이 코드를 한 입도 물기 전에
        38. // 눈에 핏발을 세웁니다.
        39.  
        40. // 따라서 위와 같이 만들기보다는 코드를 조금
        41. // 나누고 주석을 추가합니다.
        42.  
        43.  
        44. //-----------------------------------------------------------------------------
        45. typedef vector<int>::iterator VecIntIter;
        46. // rangeBegin를 y보다 크거나 같은 요소 중
        47. // 가장 마지막 요소로 초기화합니다. 이런 요소가 없으면,
        48. // rangeBegin는 v.begin()로 초기화합니다.
        49.  
        50. VecIntIter rangeBegin = find_if(v.rbegin(), v.rend(),
        51. bind2nd(greater_equal<int>(), y)).base();
        52.  
        53. // rangeBegin부터 v.end()까지 횡단하면서 x보다 작은 값을 모두 지웁니다.
        54. v.erase(remove_if(rangeBegin, v.end(), bind2nd(less<int>(), x)), v.end());
        55. //-----------------------------------------------------------------------------
        56.  
        57.  
        58. // 이렇게 만든 코드에도 혼란스러워 하는
        59. // 분들이 분명히 있습니다.
        60.  
        61. // 하지만 코드에 끼워 넣은 주석문과
        62. // 훌륭한 STL 참고서만 있으면
        63. // '웬만한' C++ 프로그래머는
        64. // 큰 불편 없이 이 코드를 파악할 수
        65. // 있어야 합니다.

        
        
        예제 코드 접기
        
        
        

  48. 용도에 맞는 헤더를 항상 #include하자 / 306

      • 마이너한 경우이긴 하지만 어떤 플랫폼에서 컴파일되는 소프트웨어를 다른 플랫폼으로 옮기려면 #include 지시자 몇 개를 더 붙여야 할 때가 있습니다. 이는 C의 표준안과 달리 C++의 표준안이 표준 헤더 사이의 인클루드 관계를 명확하게 정해두지 않았기 때문입니다.

        서로 다른 다섯 개의 STL 플랫폼(A, B, C, D, E)을 가지고 몇 가지 실험을 통해, 간접적으로 어떤 헤더가 다른 헤더를 #include하고 있는지를 알아 보았습니다.
        
        
        • A와 C의 경우, <vector>는 <string>를 #include합니다.
        • C의 경우, <algorithm>은 <string>를 #include합니다.
        • C와 D의 경우, <iostream>은 <iterator>를 #include합니다.
        • D의 경우, <iostream>은 <string>과 <vector>를 #include합니다.
        • D와 E의 경우, <string>은 <algorithm>을 #include합니다.
        • 모든 경우에서 <set>은 <functional>을 #include합니다.

      • std 네임스페이스의 구성 요소를 사용하고 계신 한, 용도에 맞는 헤더를 #include할 책임은 여러분에게 있습니다. 이렇게 해야 이식성 있는 코드를 만들 수 있게 됩니다.

        어떤 헤더가 언제 필요한지가 헷갈리는 분들을 위해, 표준 STL 관련 헤더에 무엇이 있는지 간단히 정리해 보았습니다.
        
        
        • 거의 모든 컨테이너들은 같은 이름의 헤더에 정의되어 있습니다. 이를테면 벡터는 <vector>, 리스트는 <list>에 선언되어 있지요. <set>과 <map>은 예외입니다. <set>은 set과 multiset을 선언하고 있으며, <map>은 map과 multimap을 선언하고 있습니다.
        • 네 개를 제외한 모든 알고리즘이 <algorithm>에 선언되어 있습니다. 제외된 네 개는 accumulate(항목 37 참조), inner_product, adjacent_difference, partial_sum 이며, <numeric>에서 선언되어 있습니다.
        • istream_iterator와 istreambuf_iterator(항목 29 참조)를 포함한 특별한 종류의 반복자는 <iterator>에 선언되어 있습니다.
        • 표준 함수자(예를 들면, less<T>)와 함수자 어댑터(not1, bind2nd 같은 것)는 <functional>에 선언되어 있습니다.

  49. STL에 관련된 컴파일러 진단 메시지를 해석하는 능력을 가지자 / 308

      • STL을 사용하다 아주 간단한 실수(문법 오류)를 저질렀을 때, 컴파일러가 보여주는 오류 메시지는 매우 복잡한 경우가 많습니다. 이런 복잡한 오류 메시지를 만나더라도 당황하지 말고 해석할 수 있는 능력을 기르는 것이 좋습니다.

      • string은 클래스가 아니라 typedef 타입입니다. 특히 basic_string<char, char_traits<char>, allocator<char> >를 가지고 만든 typedef 타입이지요. 따라서 오류 메시지에 basic_string 어쩌고가 나온다면 이것을 "string"으로 바꾸어 해석하면, 좀 더 쉽게 오류 메시지를 해석할 수 있습니다.

        vector는 처음부터 요소의 개수를 정해 주고 생성해도 상관이 없습니다. 다음과 같이 말이죠.
        
        vector<int> v(10);
        // 크기 10의 벡터를
        // 하나 만듭니다.
        
        string도 vector와 비슷하게 동작한다는 사실을 알기 때문에, 이렇게 할 수 있다고 생각할 지도 모르지요.
        
        string s(10);
        // 크기 10인 string 객체를
        // 만들려고 합니다.
        
        애석하게 이 문장은 컴파일되지 않습니다. int 매개 변수를 받는 생성자가 string에 없기 때문인데요, 이렇게 했을 때 STL 플랫폼 중 하나가 다음과 같이 바가지를 긁더라 이겁니다.
        
        진단 메시지 보기
        
        
        

        1. example.cpp(20): error C2664:'__thiscall std::basic_string<char, struct
        2. std::char_traits<char>,class std::allocator<char>
        3. >::std::basic_string<char, struct std::char_traits<char>,class
        4. std::allocator<char> >(const class std::allocator<char> &)': cannot convert
        5. parameter 1 from 'const int' to 'const class std::allocator<char> &'
        6.  
        7. Reason: cannot convert from 'const int' to 'const class std::allocator<char>'
        8.  
        9. No constructor could take the source type, or constructor overload
        10. resolution was ambiguous

        
        
        진단 메시지 접기
        
        
        멋지지 않습니까? 이 메시지의 첫 번째 부분은 무슨 새끼 고양이 한 마리가 키보드를 밟고 지나간 것 같고, 두 번째 부분은 신비스럽게도 소스 코드에 써 주지도 않은 할당자를 들먹거리고 있으며, 세 번째 부분은 생성자 호출이 잘못 되었다고 합니다.
        
        물론 셋째 부분은 맞습니다. 그러나 고양이가 저질러 놓은 결과에 우선 주목하도록 합시다. string을 사용할 때 자주 보게되는 진단 메시지의 대표격이니까요.
        
        위에서 string은 basic_string 클래스 템플릿으로 찍어낸 클래스의 typedef 타입이라는 이야기를 했었죠? 이렇게 만든 이유는 C++가 문자열이란 일반적인 개념으로 보기 때문입니다.
        
        C++는 임의의 문자 특성(trait)을 가진 임의의 문자 타입을 임의의 할당자를 써서 메모리에 저장한 단위의 시퀸스를 문자열이라고 봅니다.
        
        C++에서 쓰이는 string처럼 동작하는 모든 객체는 basic_string 템플릿을 인스턴스화한 것입니다. 이것이 string을 조금만 잘못 사용했을 때 나타나는 컴파일러 진단 메시지에 basic_string이 언급되는 이유입니다.
        
        실제 컴파일러 진단 메시지에서 보게 되는 것은 매우 근접하지만, 컴파일러마다 조금씩 다릅니다. 어떤 다른 STL 플랫폼에서는 string을 다음과 같이 부르고 있었습니다.
        
        basic_string<char,
        string_char_traits<char>,
        __default_alloc_template<false,0> >
        
        string_char_traits와 __default_alloc_template이란 이름은 표준이 아닙니다. 몇몇 STL 제품은 약간씩 표준을 벗어나 있습니다.
        
        여러분이 사용하고 있는 STL이 표준을 지키지 않는 것들이 마음에 들지 않으면 다른 것으로 바꾸세요. 항목 50에 있는 STL 제품 정보가 많은 도움이 될 것입니다.
        
        아무튼 간에 우리의 목표는 이 진단 메시지를 조금이라도 우리에게 의미 있는 것으로 줄이는 것입니다. 앞에 나왔던 진단 메시지의 경우,
        
        std::basic_string<char,
        struct std::char_traits<char>,
        class std::allocator<char> >
        
        를 string으로 바꾸면 다음과 같이 됩니다(이런 작업은 명령행 컴파일러를 사용하는 분이라면 시드(sed) 같은 프로그램이나 펄(per), 파이썬(python), 루비(ruby) 같은 스크립트 언어를 써서 쉽게 처리할 수 있습니다).
        
        진단 메시지 보기
        
        
        

        1. example.cpp(20): error C2664:'__thiscall string::string(const class
        2. std::allocator<char> &)': cannot convert parameter 1 from 'const int' to
        3. 'const class std::allocator<char> &'

        
        
        진단 메시지 접기
        
        
        메시지의 의미가 이전보다 확실해졌습니다. string 생성자에 넘겨진 매개 변수의 타입이 문제라는 것이죠.
        
        그런데, 할당자를 언급하는 부분은 아직도 신비롭기만 합니다. 왜 그럴까요? 모든 표준 컨테이너엔 할당자를 받아들이는 생성자가 준비되어 있습니다. string도 마찬가지구요.
        
        컴파일러는 몇 가지 이유 때문에 매개 변수를 하나 넣은 생성자를 무조건 할당자를 받아들이는 생성자로 간주해 버립니다. 컴파일러가 착각한 것이고 이 진단 메시지는 틀렸습니다.
        
        할당자를 받는 생성자는 웬만하면 쓰지 마세요. 이 생성자는 해당 컨테이너와 동일한 타입인데, 동등하지 않은(inequivalent) 할당자를 가진 상태로 빠뜨려 버립니다. 이것은 일반적으로 매우 나쁩니다(항목 11 참조).

      • 복잡한 컨테이너의 타입(클래스 템플릿)을, typedef를 써서 알아보기 쉬운 타입명으로 대체하는 것도 한 방법입니다. 밑줄(_) 뒤에 따라오는 대문자로 시작하는 이름은, 라이브러리 제작자들에게 예약된 것임을 떠올립시다. 이러한 이름을 갖는 템플릿에게 넘기는 타입 매개 변수들을 SOMETHING으로만 바꿔도, 진단 메시지가 훨씬 읽기 쉬워집니다.

        전자메일 프로그램을 하나 만든다고 가정해 보세요. 사용자는 전자메일 대신에 별명을 쓸 수 있습니다. 이런 프로그램을 STL로 만든다면 별명을 전자메일 주소에 대응시킨 맵을 사용해야 할 것이고, 주어진 별명에 연관된 전자메일 주소를 출력하는 showEmailAddress란 멤버 함수가 제공되어야 할 것입니다.
        
        예제 코드 보기
        
        
        

        1. class NiftyEmailProgram {
        2. private:
        3. typedef map<string, string> NicknameMap;
        4. NicknameMap nicknames; // 별명을 전자메일 주소에
        5. // 연관시킨 맵
        6. public:
        7. ...
        8. void showEmailAddress(const string& nickname) const;
        9. };
        10.  
        11. // showEmailAddress의 내부에는 저장된
        12. // 별명에 연결된 맵 엔트리를 찾는
        13. // 코드를 넣어 주어야 합니다.
        14.  
        15. void NiftyEmailProgram::showEmailAddress(const string& nickname) const
        16. {
        17. ...
        18. NicknameMap::iterator i = nicknames.find(nickname);
        19. if (i != nicknames.end()) ...
        20. ...
        21. }
        22.  

        
        
        예제 코드 접기
        
        
        문제는 컴파일러가 이런 코드를 좋아하지 않는다는 것입니다. 충분한 이유가 있지만, 더 큰 문제는 그 문제를 이해할 수 없다는 것입니다. 다음의 진단 메시지는 어떤 STL 플랫폼 하나가 위의 코드를 컴파일하려하자 뱉어낸 메시지입니다.
        
        진단 메시지 보기
        
        
        

        1. example.cpp(17): error C2440: 'initializing': cannot convert from 'class std::_Tree<class
        2. std::basic_string<char, struct std::char_traits<char>,class std::allocator<char> >,struct
        3. std::pair<class std::basic_string<char, struct std::char_traits<char>,class
        4. std::allocator<char> > const .class std::basic_string<char, struct
        5. std::char_traits<char>,class std::allocator<char> > >,struct std::map<class
        6. std::basic_string<char, struct std::char_traits<char>,class std::allocator<char> >.class
        7. std::basic_string<char, struct std::char_traits<char>,class std::allocator<char> >,struct
        8. std::less<classstd::basic_string<char,structstd::char_traits<char>, class
        9. std::allocator<char> > >,class std::allocator<class std::basic_string<char, struct,
        10. std::char_traits<char>,class std::allocator<char> > > >::_Kfn, struct std::less<class
        11. std::basic_string<char, struct std::char_traits<char>,class std::allocator<char> > >,class
        12. std::allocator<class std::basic_string<char, struct, std::char_traits<char>,class
        13. std::allocator<char> > > >::const_iterator' to 'class std::_Tree<class
        14. std::basic_string<char, struct std::char_traits<char>,class std::allocator<char> >,struct
        15. std::pair<class std::basic_string<char, struct std::char_traits<char>,class
        16. std::allocator<char> > const .class std::basic_string<char, struct
        17. std::char_traits<char>,class std::allocator<char> > >,struct std::map<class
        18. std::basic_string<char, struct std::char_traits<char>,class std::allocator<char> >,class
        19. std::basic_string<char, struct std::char_traits<char>,class std::allocator<char> >,struct
        20. std::less<classstd::basic_string<char,structstd::char_traits<char> .class
        21. std::allocator<char> > >,class std::allocator<class std::basic_string<char,struct
        22. std::char_traits<char>,class std::allocator<char> > > >::_Kfn, struct std::less<class
        23. std::basic_string<char, struct std::char_traits<char>,class std::allocator<char> > >,class
        24. std::allocator<class std::basic_string<char, struct std::char_traits<char>,class
        25. std::allocator<char> > > >::iterator'
        26. No constructor could take the source type, or constructor overload resolution was
        27. ambiguous

        
        
        진단 메시지 접기
        
        
        이 메시지, 끔찍스럽게 징그럽지 않습니까? 이런 끔찍한 상황을 진정시켜 봅시다. 우선 basic_string 궁시렁 궁시렁 하는 것을 string으로 바꿉시다.
        
        진단 메시지 보기
        
        
        

        1. example.cpp(17): error C2440: 'initializing': cannot convert from 'class
        2. std::_Tree<class string, struct std::pair<class string const ,class string
        3. >,struct std::map<class string, class string, struct std::less<class string
        4. >,class std::allocator<class string > >::_Kfn, struct std::less<class string
        5. >,class std::allocator<class string > >::const_iterator' to 'class
        6. std::_Tree<class string, struct std::pair<class string const .class string
        7. >,struct std::map<class string, class string, struct std::less<class string
        8. >,class std::allocator<class string > >::_Kfn,struct std::less<class string
        9. >,class std::allocator<class string > >::iterator'
        10.  
        11. No constructor could take the source type, or constructor overload
        12. resolution was ambiguous

        
        
        진단 메시지 접기
        
        
        훨씬 나아졌습니다. 눈에 처음 밟히는 것은 std::_Tree입니다. 밑줄(_) 뒤에 따라오는 대문자는 라이브러리 제작자들에게 예약된 것입니다.
        
        즉 std::_Tree는 STL의 컴포넌트를 구현하는데 사용되는 내부 템플릿 입니다.
        
        거의 모든 STL 제품들이 이런 식의 내부 템플릿을 써서 표준 연관 컨테이너(set, multiset, map, multimap)를 구현하고 있는 것이 사실입니다.
        
        이름은 STL 제품마다 조금씩 다릅니다. __tree 혹은 __rb_tree 도 있었습니다. 후자의 이름에서는 빨강-검정(red-black) 트리라는 것을 눈치챌 수 있습니다. 대부분의 STL 제품에서 사용되는 균형 트리 말입니다.
        
        잠깐 _Tree를 뒤로 제껴 놓더라도 이 메시지에는 우리가 파악해야 할 타입이 하나 있습니다. std::map<class string, class string, struct std::less<class string>, class std::allocator<class string> >이라고 조금 길죠.
        
        바로 이것이 우리가 사용하는 맵의 정확한 타입입니다. 이 부분을 NicknameMap으로 바꿔 버립시다. 그 결과는 다음과 같습니다.
        
        진단 메시지 보기
        
        
        

        1. example.cpp(17): error C2440: 'initializing': cannot convert from 'class
        2. std::_Tree<class string, struct std::pair<class string const, class string
        3. >,struct NicknameMap::_Kfn, struct std::less<class string >,class
        4. std::allocator<class string > >::const_iterator' to 'class std::_Tree<class
        5. string, struct std::pair<class string const ,class string >,struct
        6. NicknameMap::_Kfn, struct std::less<class string >,class std::allocator<class
        7. string > >::iterator'
        8.  
        9. No constructor could take the source type, or constructor overload resolution was ambiguous

        
        
        진단 메시지 접기
        
        
        길이가 짧아지긴 했지만, 알아보기가 크게 좋아지진 않은 것 같습니다. _Tree에 뭔가를 해 주어야 합니다. _Tree는 STL 제품마다 다른 템플릿이기 때문에, 템플릿 매개 변수의 의미를 캐내려면 소스 코드를 읽는 것 외에는 방법이 없습니다.
        
        하지만, 그럴 필요까지 없고요. 그냥 간단하게, _Tree에 넘겨지는 매개 변수를 SOMETHING으로만 바꾸어도 충분합니다. 다음이 그 결과입니다.
        
        진단 메시지 보기
        
        
        

        1. example.cpp(17): error C2440: 'initializing': cannot convert from 'class
        2. std::_Tree<SOMETHING>::const_iterator' to 'class
        3. std::_Tree<SOMETHING>::iterator'
        4.  
        5. No constructor could take the source type, or constructor overload
        6. resolution was ambiguous

        
        
        진단 메시지 접기
        
        
        이제 적극적으로 읽을 마음이 용솟음치는 상태가 되었습니다. 알고 보니 const_iterator를 iterator로 변환하려고 하는데에 컴파일러가 불만을 품은 것이로군요.
        
        문제의 코드를 다시 읽어 봅시다. 이번에는 컴파일러가 에러는 낸 줄을 굵게 표시했습니다.
        
        예제 코드 보기
        
        
        

        1. class NiftyEmailProgram {
        2. private:
        3. typedef map<string, string> NicknameMap;
        4. NicknameMap nicknames;
        5.  
        6. public:
        7. ...
        8. void showEmailAddress(const string& nickname) const;
        9. };
        10.  
        11. void NiftyEmailProgram::showEmailAddress(const string& nickname) const
        12. {
        13. ...
        14. NicknameMap::iterator i = nicknames.find(nickname);
        15. if (i != nicknames.end()) ...
        16. ...
        17. }

        
        
        예제 코드 접기
        
        
        이상하지 않습니까? nicknames를 가지고 호출했는데, nicknames는 상수 객체가 아니고, find는 비상수 반복자를 반환하기 때문입니다.
        
        하지만 잘 보세요. 해당 문장을 포함한 showEmailAddress함수가 const 멤버 함수로 선언되어 있습니다. const 멤버 함수 안에서는 모든 비정적 데이터 멤버는 무조건 상수 멤버가 된다는 사실을 잊지 마세요.
        
        결국 showEmailAddress에 const를 붙이지 말든지, i를 const_iterator로 바꾸면 문제가 해결됩니다.

      • 마지막으로 STL의 신비스럽고 오묘한 컴파일러 메시지를 이해하는데 도움을 줄 힌트를 몇 개 정리해 보았습니다.

        • vector와 string의 경우, 반복자는 포인터와 똑같습니다. 따라서, iterator를 가지고 실수를 했다면 컴파일러 진단 메시지는 포인터 타입을 언급할 가능성이 99.897%입니다. 예를 들어 소스 코드에 vector<double>::iterator가 들어있으면 컴파일러 메시지는 십중 팔구 double* 포인터라고 합니다(예외가 있는데 STLport에서 구한 제품을 디버그 모드에서 사용할 경우입니다. 이 경우에는 vector와 string의 반복자가 포인터가 아니기 때문이죠).
        • back_insert_iterator, front_insert_iterator, insert_iterator 등을 운운하는 메시지는 거의 항상 back_inserter나 front_inserter, inserter를 호출할 때 실수를 저질렀다는 뜻입니다(back_inserter는 back_insert_iterator 타입의 객체를, front_inserter는 front_insert_iterator 타입의 객체를, inserter는 insert_iterator 타입의 객체를 반환합니다. 이들 반복자 타입에 대해서는 항목 30을 참고하시죠). 만일 이런 류의 함수를 호출한 적이 없다면 여러분이 호출한 다른 함수에서 이 함수들을 호출했을 것입니다.
        • 비슷한 식으로 에러 메시지에서 binder1st나 binder2nd 등이 발견되었다면 bind1st 혹은 bind2nd를 잘못 호출했다고 생각하면 됩니다(bind1st는 binder1st 타입의 객체를, bind2nd는 binder2nd 타입의 객체를 반환합니다).
        • 출력 반복자(예를 들면, ostream_iterator, ostreambuf_iterator (항목 29를 보세요) 그리고 그리고 back_inserter, front_inserter, inserter에서 반환된 반복자들)는 대입 연산자(operator=)의 내부에서 출력 혹은 삽입 동작을 취하기 때문에, 이런 반복자에 대해 실수했을 때에는 전혀 여러분이 듣지도 못한 대입 연산자를 들먹이는 부분을 에러 메시지에서 찾을 수 있습니다. 한 번 다음의 코드를 컴파일해 보세요.
          
          컴파일 오류가 나는 예제 코드 보기
          
          
          

          1. vector<string*> v; // string* 포인터를
          2. copy(v.begin(), v.end(), // string 객체로
          3. ostream_iterator<string>(cout, "\n")); // 출력해 보시라구요.
          4.  

          
          
          컴파일 오류가 나는 예제 코드 접기
          
          
          
        • STL 알고리즘의 내부가 잘못 되었다고 불평하는 메시지라면(즉, 에러를 일으킨 소스 코드가 <algorithm>에 있었다면), 그 알고리즘과 함께 사용한 타입에 문제가 있었다는 뜻으로 알아들으세요. 그 문제란 예를 들어 잘못된 부류의 반복자를 넘겼다든가 하는 것입니다. 이런 에러를 보고 싶으면 다음의 코드를 컴파일러에게 '먹이고' 여러분의 심성을 개발하시기(즐기셔도 됩니다!) 바랍니다.
          
          컴파일 오류가 나는 예제 코드 보기
          
          
          

          1. list<int>::iterator i1, i2; // 임의 접근 반복자를 요구하는
          2. sort(i1, i2); // 알고리즘에다가 양방향 반복자를
          3. // 넘겨 봅니다.
          4.  

          
          
          컴파일 오류가 나는 예제 코드 접기
          
          
          
        • vector나 string, for_each와 같이 자주 쓰이는 STL 컴포넌트를 사용하고 있는데 컴파일러 쪽에서 여러분이 의도한 바를 파악하지 못하겠다는 에러 메시지를 내면, 십중팔구는 필요한 헤더를 #include하지 않은 까닭입니다. 항목 48에서도 언급하고 있듯이, 이 문제는 지금은 조용히 잘 컴파일되지만, 다른 플랫폼으로 이식하려고 하는 코드에서 발생할 수 있습니다.

  50. STL 관련 웹 사이트와 친구하자 / 318

      • '꿈과 희망과 미래가 넘실거리는' 인터넷에는 STL 정보가 잘도 널려 있습니다. 이 중에서 거의 모든 사람들이 가장 많이 찾는 사이트로 꼽는 것을 골라 보았습니다.

        • SGI STL 사이트: http://www.sgi.com/tech/stl/.
        • STLport 사이트: http://www.stlport.org/.
        • Boost 사이트: https://www.boost.org/.

      • SGI STL 웹 사이트

        SGI(실리콘 그래픽스)의 STL 웹 사이트는 STL 관련 사이트 중 단연 1순위입니다. 그도 그럴게, STL의 모든 컴포넌트를 종합적으로 설명해 놓은 문서를 제공하고 있으니까요.
        
        많은 프로그래머들은 자신이 사용하는 STL 플랫폼에 관계없이 이 사이트를 온라인 참고 매뉴얼로 사용하고 있습니다.
        
        SGI 사이트에서는 STL 프로그래밍을 위한 다른 것들도 구할 수 있습니다. SGI에서 구현한 공개용 STL이 바로 그것이죠.
        
        이 배포본은 몇 개의 컴파일러에서만 돌아가도록 이식되었지만 이 배포본을 기초로 하여 만들어진 것이 STLport라고 불리는, 프로그래머 사이에서 폭넓게 사용되는 STL 배포본입니다.
        
        또한, SGI 판은 STL 프로그래밍을 좀 더 강력하고, 재미있고, 융통성 있게 만들어 주는 비표준 컴포넌트를 많이 제공하고 있습니다. 이들 중 인기 있는 것들을 꼽아 보면 다음과 같습니다.
        
        
        • 해쉬 연관 컨테이너(hashed associative containers)
          hash_set, hash_multiset, hash_map, hash_multimap이 여기에 속합니다. 자세한 정보는 항목 25를 참고하세요.
        • 단일 연결 리스트 컨테이너(singly linked list container)
          slist입니다. 여러분이 상상한 대로 구현되었고, 역시 가리켜질 것 같은 리스트 노드를 반복자가 가리키고 있습니다.
          
          안타까운 점은 insert와 erase 멤버 함수의 동작이 상당히 느리다는 것인데, 반복자가 가리키는 노드의 앞에 있는 노드의 포인터를 조정해야 하기 때문입니다. 단일 연결 리스트에서는 뒤의 노드로 이동할 때 선형 시간이 소요됩니다(앞에서부터 다시 와야 하니까요).
          
          SGI는 이 문제를 비표준 멤버 함수인 insert_after 와 erase_after(이 함수들은 상수 시간에 동작 합니다)를 통해 해결하려고 했습니다. 이런 멤버 함수를 쓰는것이 불만이고 insert와 erase를 자주 쓰시는 분은 slist 대신에 list를 쓰셔야 할 것입니다.
          
          딩컴웨어(Dinkumware)에서도 slist란 똑같은 이름의 단일 연결 리스트 컨테이너를 지원합니다. 하지만 이 컨테이너의 반복자는 조금 다르게 구현되었기 때문에 insert와 erase의 수행 성능이 그대로 상수 시간입니다(딩컴웨어에 대한 자세한 내용은 부록 B 를 참고하세요).
        • 매우 긴 문자열을 담을 수 있는 string 류의 컨테이너(string-like container for very large strings)
          이 컨테이너는 rope(로프) 라고 불립니다. SGI는 로프를 이렇게 규정하고 있습니다.
          
          로프는 확장성을 갖춘 문자열 객체로서, 문자열 전체를 대상으로 한 동작에 최적화시켜 설계되었습니다. 문자열 대입, 문자열 연결, 부분 문자열 연산 등이 문자열의 길이에 거의 상관없는 속도로 수행됩니다. C 문자열과 달리, 로프는 매우 긴 문자열을 표한하는데 적합한 구조로서, 편집기 버퍼나 메일 메시지를 구현 하는데 효과적입니다.
          
          속을 살짝 들추어 보면, rope는 참조 카운팅으로 관리하는 부분 문자열의 트리로 구현되어 있습니다. 그리고 각 부분 문자열은 char 배열로서 저장되어 있지요.
          
          로프 인터페이스의 재미있는 특징은 begin과 end 함수가 무조건 const_iterator를 반환한다는 점입니다. 애초부터 rope는 문자열 전체를 다루는 동작에 최적화된 클래스이기 때문에 문자를 하나씩 바꾸는 동작은 비용이 꽤 높습니다.
        • 다양한 비표준 함수자 객체와 어댑터들
          가장 처음에 발표된 HP의 STL에는 현재의 표준 C++에 있는 것 이외의 함수자 클래스가 더 많이 들어 있었습니다. 이들 중에 많은 초창기 STL 고수들이 아쉬워 했던 두 가지가 select1st와 select2nd입니다. map과 multimap으로 작업할 때 매우 편리했기 때문입니다.
          
          어떤 pair가 있을 때, select1st는 첫째 멤버(키)를 반환하고 select2nd는 둘째 멤버(값)을 반환합니다. 이렇게 사용할 수 있지요.
          
          예제 코드 보기
          
          
          

          1. map<int, string> m;
          2.  
          3. ...
          4.  
          5. // 맵에 들어 있는 모든 키를 cout으로 출력합니다.
          6. transform(m.begin(), m.end(),
          7. ostream_iterator<int>(cout, "\n"),
          8. select1st<map<int, string>::value_type>());
          9.  
          10. // 벡터를 하나 만들고, 맵 안의 모든 값들을 그 벡터에 넣습니다.
          11. vector<string> v;
          12. transform(m.begin(), m.end(), back_inserter(v),
          13. select2nd<map<int, string>::value_type>());
          14.  

          
          
          예제 코드 접기
          
          
          보다시피, select1st와 select2nd가 없었다면 앞의 코드에서 여러분은 간단한 알고리즘 대신에 루프를 직접 만드는게 편했을 것입니다(항목 43 참조).
          
          하지만 이 함수자가 표준이 아니라는 사실은 이것을 사용한 여러분의 코드가 유지보수성이나 이식성에서 떨어질 거라는 뜻도 됩니다(항목 47 참조).
          
          SGI가 구현한 비표준 함수 객체는 이외에도 identity, project1st, project2nd, compose1, compose2 등이 있습니다. 항목 43에서 compose2를 사용한 예제를 보셨겠지만 자세한 사항은 웹 사이트를 직접 방문하셔서 알아보는 것이 좋겠네요.
        
        
        SGI 사이트에서는 무료로 다운로드할 수 있는 것이 하나 더 준비되어 있는데, 그것이 C++ 입출력 스트림(iostream) 계열 라이브러리입니다.
        
        이 라이브러리는 SGI에서 만든 만큼 SGI의 STL과 가장 잘 통합되는 것이 당연하겠지만, 다른 C++ 컴파일러 및 개발 도구에 들어 있는 iostream 라이브러리보다도 월등한 성능을 자랑합니다.

      • STLport(STL포트) 웹 사이트

        STLport를 찾는 가장 큰 요인은 SGI의 STL 배포본(iostream을 포함해서)을 여러 컴파일러에 맞게 수정한 제품을 내놓고 있다는 점에 있는데요, 이 사이트에서 지원하는 컴파일러의 개수가 무려 20개가 넘습니다.
        
        SGI의 라이브러리와 마찬가지로 STLport의 것도 무료로 다운로드할 수 있습니다. 다중 플랫폼으로 프로그래밍하는 분이라면 이 STLport의 라이브러리로 작업하는 것이 슬픔의 구렁텅이에서 여러분을 구원하는 길일 것입니다.
        
        STLport만의 독특한 기능은 디버그 모드입니다. 이 기능은 컴파일은 조용히 되지만 프로그램 다운 등의 정의되지 않은 동작을 일으키는 STL 사용 오류를 잡아내는 데 좋습니다.
        
        예를 들어 항목 30에서는 흔히 볼 수 있는 프로그래밍 실수를 설명하면서 컨테이너의 범위를 넘어가는 곳에 데이터를 쓰는 예를 보였지요.
        
        예제 코드 보기
        
        
        

        1. int transmogrify(int x); // 이 함수는 x를 사용해서
        2. // 어떤 새로운 값을 만듭니다.
        3. vector<int> values;
        4. ... // values에다가 데이터를 넣습니다.
        5. vector<int> results;
        6. transform(values.begin(), values.end(), // results의 끝을 넘어
        7. results.end(), // 데이터를 기록하려고 하는
        8. transmogrify); // 괘씸한 코드입니다!
        9.  

        
        
        예제 코드 접기
        
        
        이 코드는 분명히 컴파일은 잘 되지만, 실행하면 프로그램이 다운될 것입니다. transform을 호출하다가 문제가 발생되는 것은 운이 좋은 경우입니다.
        
        정말 재수가 없는 경우는 transform이 엉뚱한 주소 공간에다가 데이터를 차곡차곡 쌓아놓는 것인데, 이럴 때에는 이후에도 문제를 찾아낼 수 없으며, 메모리가 이상해지는 원인을 찾으며 쩔쩔 매다가 환장할 겁니다.
        
        STLport의 디버그 모드는 이러한 모든 역경을 해쳐 갈 수 있게 해줍니다. STLport의 디버그 모드에서 앞의 코드가 실행되면 다음의 메시지가 만들어집니다(라이브러리가 C:\STLport 에 설치되어 있다고 가정할 때).
        
        진단 메시지 보기
        
        
        

        1. C:\STLport\stlport\stl\debug\_iterator.h:265 STL assertion failure:
        2. Dereferenceable(*this)

        
        
        진단 메시지 접기
        
        
        이와 동시에 프로그램이 멈추는데, 라이브러리 내부에서 에러를 만났을 때 abort를 호출하기 때문입니다. 이 동작이 싫으면 STLport의 구성 정보를 조정해서 예외(exception)로 처리할 수도 있습니다.
        
        사실 앞의 메시지도 그리 명확하지는 않습니다. 또한, 에러가 보고된 파일과 코드 위치(줄 번호)가 transform을 호출한 그 부분이 아니라, STL 내부의 조건 설정(assertion) 부분이라는 것도 마음에 들지 않습니다.
        
        그렇지만 transform을 그냥 지나쳐 실행된 후에 왜 메모리가 이상해졌는지 찾으려고 애쓰는 일보다는 훨씬 낫지요. STLport의 디버그 모드에서는 디버거를 실행시켜 호출 스택을 추적하면서 여러분이 잘못 작성한 코드를 찾아내면 끝입니다. 에러가 보고된 소스 파일은 일반적으로 문제가 없습니다.
        
        이 외에도 STLport의 디버그 모드는 자주 저지르기 쉬운 에러도 몇 개 잡아냅니다.
        
        이를테면 유효하지 않은 범위를 알고리즘에 넘긴다든지, 텅 빈 컨테이너에서 데이터를 읽으려고 한다든지, 어떤 컨테이너에서 얻어낸 반복자를 다른 컨테이너의 멤버 함수에다가 넘기려고 하는 일 등이죠.
        
        이것이 가능한 이유는 반복자와 컨테이너가 서로의 상태를 추적하도록 구현했기 때문입니다. 이렇듯 STLport는 디버그 모드에서 조금 특이한 반복자를 사용하기 때문에 vector와 string의 반복자는 포인터가 아니라 클래스 객체입니다.

      • Boost(부스트) 웹 사이트

        Boost는 여러 사람들에 의해 검토되고 보완된 C++ 라이브러리를 무료로 제공하는 웹 사이트입니다. C++ 표준 라이브러리와 잘 조화되어 동작하며 이식이 가능한 라이브러리를 만드는 데에 중점을 두고 있는데, 이런 취지에는 다음과 같은 동기가 있었다고 합니다.
        
        라이브러리를 확장한 결과는 그 자체가 현재의 기술이 되며, 언젠가는 차후의 표준으로 제안될 수 있을 것입니다. Boost.org를 통해 라이브러리를 공개하는 일은 그러한 방법 중에 하나입니다...
        
        쉽게 말해서, Boost는 미래의 표준 C++ 라이브러리의 일부가 될 수 있는 구성 요소들의 옥석을 가려주는 역할을 한다고 볼 수 있네요.
        
        이 사이트에 감사해야할 또 한 가지 이유는 풍부하게 구할 수 있는 라이브러리 모음입니다. 그 중에서 두 가지는 꼭 소개해 드리고 싶네요.
        
        첫째는 shared_ptr을 자랑으로 삼고 있는 스마트 포인터 라이브러리입니다. shared_ptr은 참조 카운팅으로 관리되는 스마트 포인터 템플릿인데요, 표준 라이브러리의 auto_ptr과 달리 STL 컨테이너에 안전하게 저장할 수 있습니다(항목 8 참조).
        
        이외에도 shared_array라는 참조 카운팅으로 관리되는 동적 할당 배열을 제공하는데, 동적 할당 배열이 vector나 string보다 나쁜 경우도 있으니까(항목 13 참조) 충분히 알고 썼으면 좋겠습니다.
        
        두 번째는 STL에 관련된 풍부한 함수 객체와 부속 장치입니다. 이들 라이브러리는 기존의 STL 함수 객체와 어댑터를 근본적으로 다시 설계하고 구현한 것으로, 표준 함수자에 인위적으로 가한 제약을 없앴습니다.
        
        이런 제약의 예는 bind2nd를 mem_fun이나 mem_fun_ref에 써서 어떤 객체와 멤버 함수의 매개 변수를 바인딩하려 하는데, 그 멤버 함수가 '참조 전달' 형태일 때 컴파일 에러가 나는 것입니다.
        
        not1이나 not2를 ptr_fun에 사용하든지, 참조자 타입을 받아들이는 함수에다가 사용해도 동일한 에러를 볼 수 있습니다.
        
        그 이유는 템플릿을 인스턴스로 만드는 도중에 대부분의 STL 플랫폼이 참조자에 대한 참조자를 만드는데, 참조자에 대한 참조자는 C++에서 말이 안 되는 타입이기 때문입니다.
        
        다음의 예제 코드는 소위 '참조자에 대한 참조자 문제'로 알려진 이런 상황을 만들어 냅니다.
        
        예제 코드 보기
        
        
        

        1. class Widget {
        2. public:
        3. ...
        4. int readStream(iostream& stream); // readStream은
        5. ... // 매개 변수를 참조자로
        6. }; // 받아 들입니다.
        7.  
        8. vector<Widget*> vw;
        9. ...
        10. for_each( // 대부분의 STL 플랫폼에서는
        11. vw.begin(), vw.end(), // 이 코드를 처리할 때
        12. bind2nd(mem_fun(&Widget::readStream), cin) // 참조자에 대한 참조자
        13. ); // 를 만듭니다.
        14. // 이렇게 만든 코드는
        15. // 컴파일되지 않습니다.
        16.  

        
        
        예제 코드 접기
        
        
        Boost의 함수 객체는 이 문제를 포함한 여러 가지 제약을 피해 가며, 함수 객체의 표현력까지 엄청나게 확장시켜 줍니다.

• 부록

  1. 로케일(Locale), 그리고 대소문자를 구분하지 않는 문자열 비교법 / 333

     • 대소문자를 구분하지 않는 문자열 클래스는 애초부터 꿈을 꾸지 않는 것이 좋습니다. C++ 표준 라이브러리의 일반 알고리즘은 정책적으로 매개 변수화가 가능하므로, 이 부분을 끌어내야 합니다.

       상등성 검사와 대소 검사를 적절하게 재정의해서 맞춘 문자 특성 매개 변수를 넣어 주면 <과 == 연산자가 대소문자를 구분하지 않고 동작하도록 basic_string을 인스턴스화할 수 있습니다. 자, 말로는 가능합니다. 하지만 이것은 고민한 만큼의 가치가 없습니다. 어떤 고민이냐고요?
       
       
       • I/O를 하려면 엄청난 고통 없이는 불가능합니다. 표준 라이브러리의 I/O 클래스, 이를테면 std::basic_istream과 std::basic_ostream 같은 것들은 std::basic_string 처럼 문자 타입과 문자 특성을 받는 템플릿으로 동작합니다.
         
         문자 특성 정보는 일치해야 합니다. 만약에 여러분만의 문자열 클래스를 만든다고 std::basic_string<char, my_traits_class>를 사용하려고 한다면 이것을 스트림으로 출력하기 위한 별도의 클래스인 std::basic_ostream<char, my_traits_class>를 사용해야 합니다.
         
         즉, cin이나 cout 같은 보통의 스트림 객체와는 안녕을 해야 한다는 말입니다.
       • 활자 케이스 무관성(Case insensitivity)의 문제는 어떤 객체를 만들 것이냐가 아니라 객체를 어떻게 사용할 것이냐에 맞추어 생각해야 합니다. 즉, 어떤 환경에서는 문자열을 활자 케이스를 고려하여 처리하고, 다른 환경에서는 활자 케이스에 무관하게 처리하는 식으로 가는 것이 지극히 당연한 것입니다.
         
         필요에 따라 별도의 타입을 만들어 쓰는 것은 오히려 불편함만 가중시킬 뿐입니다.
       • 표준 라이브러리에 자연스럽지 않습니다. 모든 문자 특성(traits) 클래스가 그렇지만 char_traits는 크기가 작고 간단하며, 상태가 없습니다.
       • 뭔가 불충분합니다. basic_string의 모든 멤버 함수가 대소문자를 구분하지 않는다 하더라도, std::search나 std::find_end 같이 멤버가 아닌 일반 알고리즘을 사용할 때에는 전혀 도움이 되지 않습니다.
         
         효율을 고려해서 basic_string의 컨테이너를 문자열 테이블로 바꾸었을 때에도 역시 도움이 되지 않습니다.
       한편, 일반 알고리즘은 여러분도 알다시피 융통성이 있기 때문에 대소문자를 구분하지 않고 문자열을 처리할 수 있도록 만들 수 있습니다.
       
       예를 들어 string의 컨테이너를 정렬하되 대소문자에 무관한 순서로 하고 싶다면, 그에 맞는 적절한 함수 객체를 만들어 알고리즘에 보내면 됩니다.

     • 사전식(Lexicographical) 문자열 비교는 문자 비교를 기반으로 하여 구현합니다. 즉, 대소문자를 구분하지 않는 문자 비교를 수행하는 함수 객체를 만들었다면 문제는 반 이상 해결된 것입니다(이것을 재사용해서 다른 종류의 문자 시퀸스(vector<char>, 문자열 테이블, 통상의 C 문자열)를 비교하는 데에 사용하면 됩니다).

       대소문자를 구분하지 않는 문자 비교는 지극히 일반적인 방법으로 구현할 수 있습니다. 두 문자를 모두 대문자로 바꾼 후에 그 결과를 비교하면 되는 것이죠. 이 아이디어를 C++ 함수 객체로 바로 옮겨 버린 결과가 다음의 코드입니다.
       
       예제 코드 보기
       
       
       

       1. struct lt_nocase
       2. : public std::binary_function<char, char, bool> {
       3. bool operator()(char x, char y) const {
       4. return std::toupper(static_cast<unsigned char>(x)) <
       5. std::toupper(static_cast<unsigned char>(y));
       6. }
       7. };

       
       
       예제 코드 접기
       
       
       이 예제는 거의 맞지만, 충분히 좋지는 않습니다. 아주 미묘한 문제가 있습니다. 다음 예제 코드를 보세요.
       
       예제 코드 보기
       
       
       

       1. int main(void)
       2. {
       3. const char* s1 = "GEW\334RZTRAMINER"
       4. const char* s2 = "gew\374rztraminer"
       5. printf("s1 = %s, s2 = %s\n", s1, s2);
       6. printf("s1 < s2: %s\n",
       7. std::lexicographical_compare(s1, s1 + 14, s2, s2 + 14, lt_nocase())
       8. ? "true" : "false");
       9. }
       10.  
       11. // IRIX 6.5가 설치된 실리콘 그래픽스 O2 에서는
       12. // 다음과 같은 결과가 나옵니다.
       13.  
       14. // "s1 = GEWÜRZTRAMINER, s2 = gewürztraminer"
       15. // "s1 < s2: true"
       16.  
       17. // 참 이상하죠? 대소문자를 구분하지 않는 비교를
       18. // 했으니 두 문자열은 똑같아야 당연한 것 아닐까요?
       19.  
       20. // 이제 앞의 코드의 printf 문장 앞에
       21. // 다음 문장을 추가해 봅시다.
       22.  
       23. setlocale(LC_ALL, "de");
       24.  
       25. // 갑자기 출력 결과가 바뀝니다.
       26.  
       27. // "s1 = GEWÜRZTRAMINER, s2 = gewürztraminer"
       28. // "s1 < s2: false"

       
       
       예제 코드 접기
       
       
       대소문자를 구분하지 않는 문자열 비교는 보기보다 상당히 복잡합니다.

     • 대소문자를 비교하지 않는 문자열 비교는 생각보다 어렵습니다. 이것은 로케일(locale)을 고려하지 않으면 전혀 의미가 없습니다. 따라서 문자 비교 함수 객체를 만들 때 로케일 정보를 저장해 두도록 해야 합니다. 수행 속도가 중요하다면 고비용의 패싯 조작을 반복적으로 호출하는 일은 피하도록 합시다.

       • 로케일(Locale)
         문자 조작 함수는 문자 집합을 가지고 동작하는데, 이 문자 집합은 기본적으로 영문 텍스트에 적합하게 되어 있습니다.
         
         정수 '\374'는 글자가 아니기 때문에 toupper의 영향을 받지 않습니다. 하지만, 이 값은 어떤 시스템에서는 ü로 출력시키는 글자로 해석될 수 있습니다.
         
         영문 텍스트를 조작하도록 만들어진 C 라이브러리에서는 의미가 없습니다. 따라서 다음의 문장,
         
         setlocale(LC_ALL, "de");
         
         은 C 라이브러리를 독일어 방식으로 동작시키라고 알려줍니다(최소한 이 코드는 IRIX에서는 동작합니다. 로케일 이름은 표준화되어 있지는 않답니다). 독일어에는 ü 문자가 있으므로, toupper는 ü를 Ü로 바꿉니다.
         
         여기서 중요한 문제는 toupper가 전역 변수에 의존하여 동작한다는 것입니다. 이 때문에, 언젠가 toupper를 사용하는 함수는 전체 프로그램 내의 다른 모든 함수에 따라 코드를 바꾸어야 할 수도 있다는 거죠.
         
         이 문제는 C로 풀 수 있는 좋은 해결책은 없습니다. C 라이브러리는 하나의 전역 변수를 쓰니까요. 하지만, C++로는 해결책이 있습니다.
       • C++에서의 로케일
         C++ 표준 라이브러리의 로케일은 전역 데이터가 아니라, std::locale 타입의 객체입니다. 여러분은 이 객체를 생성해서 다른 객체처럼 함수에 넘기면 되는 거죠.
         
         통상의 로케일은 다음과 같이 하면 생성할 수 있습니다. 다음을 보시죠.
         
         std::locale L =
         std::locale::classic();
         
         특정 언어, 이를테면 독일어 로케일은 이렇게 하면 생성됩니다.
         
         std::locale L("de");
         
         C 라이브러리처럼, 로케일의 이름은 표준화되어 있지 않습니다. 여러분이 쓰고 있는 라이브러리의 문서를 점검해서 로케일 이름을 찾아 쓰도록 합시다.
         
         C++의 로케일은 패싯(facets)이란 것으로 나뉘어져 있습니다. 패싯이란 국제화를 다루는 방식에 따라 나뉜 단위로서, 특정한 로케일 객체에서 std::use_facet을 호출하면 얻을 수 있습니다.
         
         ctype 패싯은 활자 케이스 변환 등의 문자 분류를 맡습니다. 그러므로 c1과 c2가 char 타입일 때 다음의 코드는 문자 비교를 대소문자 구분에 무관하게, 그리고 로케일 L에 맞게 수행합니다.
         
         예제 코드 보기
         
         
         

         1. const std::ctype<char>& ct = std::use_facet<std::ctype<char> >(L);
         2. bool result = ct.toupper(c1) < ct.toupper(c2);
         3.  
         4. // 짧게 줄일 수도 있습니다. 아래의 문장은
         5.  
         6. std::toupper(c, L);
         7.  
         8. // c가 char 타입이라면 다음의 표현식과
         9. // 동일한 의미를 갖습니다.
         10.  
         11. std::use_facet<std::ctype<char> >(L).toupper(c);
         12.  
         13. // 이 방법은 use_facet의 호출 횟수를
         14. // 줄인다는 점에서 상당한 가치가 있습니다.
         15.  
         16. // use_facet은 비용이 높은 함수이기
         17. // 때문입니다.

         
         
         예제 코드 접기
         
         
         이 방법도 항상 적합하지는 않습니다. 독일어를 예로 들면, 소문자 "ß"를 대문자로 바꾼 결과는 "SS"입니다.
         
         하지만, 애석하게도 문자 단위로 비교하는 방법까지가 우리가 할 수 있는 마지막입니다. 두 개 이상의 문자에 대해서도 활자 케이스를 바꾸어 주는 수단은 C에서도 C++에서도 찾을 수 없습니다. 이 제약이 마음에 걸린다면, 이제는 표준 라이브러리의 영역을 벗어나야 합니다.
       • 또 하나의 패싯
         collate 패싯은 문자열 정렬 메커니즘을 정밀하게 캡슐화한 클래스로서 C 라이브러리 함수 strcmp와 매우 흡사한 인터페이스를 가진 멤버 함수를 가지고 있습니다. 심지어 약간 편리한 기능도 있지요.
         
         로케일 객체 L이 있다면, 귀찮게 use_facet을 호출해서 collate 멤버 함수를 호출하는 일 없이 L(x, y)만으로 문자열을 비교할 수 있습니다.
         
         통상의 C 로케일이 가지고 있는 collate 패싯은 사전적 문자열 비교를 수행합니다. operator<와 같지요. 하지만 다른 로케일은 어떤 방식의 문자열 비교도 할 수 있습니다.
         
         어쩌다가 여러분의 시스템이 대소문자를 구분하지 않는 문자열 비교를 수행하는 로케일을 가지고 있다면 그대로 쓰시면 됩니다. 하지만, 그런 시스템이 없는 분들에게는 지금 드리는 말씀이 별 도움이 되지 않을 것입니다.
         
         누군가가 여러분 대신에 대소문자를 구분하지 않는 문자열 비교를 수행하는 함수를 만들어 놓지 않았다면 직접 만들어야죠 뭐.
       • 대소문자를 구분하지 않는 문자열 비교
         이번에는 전역변수가 아닌 로케일 객체를 써서 대소문자를 구분하지 않고 문자열을 비교하는 방법을 보여드리겠습니다.
         
         참고로, 두 개의 문자를 대문자로 바꾸는 일은 두 개의 문자를 소문자로 바꾸는 일과 똑같은 결과를 내어 주지는 않습니다.
         
         예를 들어 불어의 경우, 대문자에서는 악상(accent) 기호를 생략하는 것이 관례입니다. 따라서 불어권 로케일에서는 toupper가 손실 변환일 수 밖에 없습니다. 'é'와 'e'가 모두 'E'로 바뀌니까요.
         
         이런 환경에서는 아마 toupper를 써서 구현하는것이 맞는 답일 것입니다(하지만 이것은 언어, 지역적 관습, 그리고 여러분의 작업 용도에 따라 달라질 것입니다).
         
         예제 코드 보기
         
         
         

         1. struct lt_str_1
         2. : public std::binary_function<std::string, std::string, bool> {
         3. struct lt_char {
         4. const std::ctype<char>& ct;
         6. lt_char(const std::ctype<char>& c) : ct(c) {}
         8. bool operator()(char x, char y) const {
         9. return ct.toupper(x) < ct.toupper(y);
         10. }
         11. };
         12. std::locale loc;
         13. const std::ctype<char>& ct;
         15. lt_str_1(const std::locale& L = std::locale::classic())
         16. : loc(L), ct(std::use_facet<std::ctype<char> >(loc)) {}
         18. bool operator()(const std::string& x, const std::string& y) const {
         19. return std::lexicographical_compare(x.begin(), x.end(),
         20. y.begin(), y.end(),
         21. lt_char(ct));
         22. }
         23. };

         
         
         예제 코드 접기
         
         
         이 방법은 아직 상당한 최적화가 필요합니다. toupper를 루프에서 호출하고 있고, C++ 표준안에 의하면 toupper는 가상 함수 호출을 수행해야 합니다. 루프 안에서 가상 함수 호출문을 피하는 것이 급선무입니다.
         
         하지만, 가상 함수를 피해 가는 작업이 그리 간단하지는 않습니다. 한 가지 대안은 모든 문자에 대해 활자 케이스 변환을 수행한 후에 그 결과를 캐싱해 두는 것입니다.
         
         이 방법은 일반적인 해결책은 아닙니다(예를 들어, 32비트 UCS-4 문자 집합을 가지고 작업하고 있다면 전혀 의미가 없을 수도 있습니다).
         
         예제 코드 보기
         
         
         

         1. const char* ctype<char>::toupper(char* f, char* l) const;
         2.  
         3. // 이 함수는 범위 [f, l) 안의 문자들의
         4. // 활자 케이스를 바꾸어 줍니다.
         5.  
         6. struct lt_str_2
         7. : public std::binary_function<std::string, std::string, bool> {
         8. struct lt_char {
         9. const char* tab;
         11. lt_char(const char* t) : tab(t) {}
         13. bool operator()(char x, char y) const {
         14. return tab[x - CHAR_MIN] < tab[y - CHAR_MIN];
         15. }
         16. };
         17. char tab[CHAR_MAX - CHAR_MIN + 1];
         19. lt_str_2(const std::locale& L = std::locale::classic()) {
         20. const std::ctype<char>& ct = std::use_facet<std::ctype<char> >(L)
         21.  
         22. for (int i = CHAR_MIN; i <= CHAR_MAX; ++i) {
         23. tab[i - CHAR_MIN] = (char)i;
         24. }
         25. ct.toupper(tab, tab + (CHAR_MAX - CHAR_MIN + 1));
         26. }
         28. bool operator()(const std::string& x, const std::string& y) const {
         29. return std::lexicographical_compare(x.begin(), x.end(),
         30. y.begin(), y.end(),
         31. lt_char(tab));
         32. }
         33. };

         
         
         예제 코드 접기
         
         
         lt_str_2은 짧은 문자열 몇 개를 비교하는 데에 사용하면 여전히 느려 터질지도 모릅니다. 하지만, 실제로 사용해 보면 lt_str_2가 lt_str_1보다 비약적으로 빠릅니다.

  2. 마이크로소프트의 STL 플랫폼에 대한 첨언(添言) / 347

     • 지금부터 하는 이야기는 마이크로소프트 비주얼 C++(이후 MSVC) 4-6을 사용하는 개발자를 위한 것입니다. 비주얼 C++ .NET의 사용자는 넘어가셔도 됩니다. 비주얼 C++ .NET의 STL 플랫폼은 여기서 이야기한 문제점을 가지고 있지 않으니까요.

     • STL에서의 멤버 함수 템플릿

       Widget 객체의 벡터가 두 개 있고, 한 벡터의 데이터를 다른 벡터의 끝에다가 복사하고 싶다고 가정합시다. 쉽죠? vector의 범위 버전 insert 함수를 사용하면 되니까요(항목 5 참조).
       
       vector와 deque가 있을 때에도 동일하게 하면 됩니다.
       
       사실 이러한 식의 프로그래밍은, 복사할 객체를 가지고 있는 컨테이너의 타입과 상관없이 가능합니다. 사용자 정의 컨테이너라도 동작합니다.
       
       이러한 융통성 있는 코딩이 가능한 이유는 vector의 범위 버전 insert가 진짜 함수가 아니라, 멤버 함수 템플릿이기 때문입니다.
       
       예제 코드 보기
       
       
       

       1. //-----------------------------------------------------------------------------
       2. // 한 벡터에 들어 있는 객체들을
       3. // 다른 벡터의 뒤에 추가합니다.
       4.  
       5. vector<Widget> vw1, vw2;
       6. ...
       7. vw1.insert(vw1.end(), vw2.begin(), vw2.end()); // vw2에 있는 Widget 객체들을
       8. // vw1 뒤에 추가합니다.
       9.  
       10.  
       11. //-----------------------------------------------------------------------------
       12. // vector와 deque가 있을 때에도
       13. // 동일하게 하면 됩니다.
       14.  
       15. vector<Widget> vw;
       16. deque<Widget> dw;
       17. ...
       18. vw.insert(vw.end(), dw.begin(), dw.end()); // dw에 있는 Widget 객체들을
       19. // vw 뒤에 추가합니다.
       20.  
       21.  
       22. //-----------------------------------------------------------------------------
       23. // 사실, 복사할 객체를 가지고 있는
       24. // 컨테이너의 타입과 상관없이 가능합니다.
       25.  
       26. vector<Widget> vw;
       27. ...
       28. list<Widget> lw;
       29. ...
       30. vw.insert(vw.begin(), lw.begin(), lw.end()); // lw 안에 있는 Widget 객체를
       31. // vw에 퍼뜨립니다.
       32. set<Widget> sw;
       33. ...
       34. vw.insert(vw.begin(), sw.begin(), sw.end()); // sw 안에 있는 Widget 객체를
       35. // vw에 퍼뜨립니다.
       36.  
       37. template <typename T, // 사용자가 정의한
       38. typename Allocator = allocator<T> > // STL 호환
       39. class SpecialContainer { ... }; // 컨테이너의 템플릿
       40. SpecialContainer<Widget> scw;
       41. ...
       42. vw.insert(vw.end(), scw.begin(), scw.end()); // scw 안에 있는 Widget 객체를
       43. // vw에 퍼뜨립니다.
       44.  
       45.  
       46. //-----------------------------------------------------------------------------
       47. // 표준안에서는 vector와 insert 멤버 함수
       48. // 템플릿을 이렇게 선언해 놓고 있습니다.
       49.  
       50. template <class T, class Allocator = allocator<T> >
       51. class vector {
       52. public:
       53. ...
       54. template <class InputIterator>
       55. void insert(iterator position, InputIterator first, InputIterator last);
       56. ...
       57. };

       
       
       예제 코드 접기
       
       
       

     • MSVC 버전 4-6

       애석하게도, MSVC 4-6에 들어 있는 STL엔 멤버 함수 템플릿이 전혀 없습니다. 이 라이브러리는 원래 MSVC 4용으로 개발된 것인데, 이 컴파일러는(그 당시의 컴파일러가 대부분 그랬듯이) 멤버 함수 템플릿 기능을 가지고 있지 않았습니다.
       
       버전 4에서 버전 6으로 오면서 컴파일러엔 이 기능이 추가되었지만, 마이크로소프트가 개입된 이상한 법적 소송 때문에 STL은 그대로 남아 있던 것이죠.
       
       MSVC 4-6에 들어 있는 STL은 멤버 함수 템플릿 기능이 없는 컴파일러용으로 설계된 것이다 보니, 라이브러리 제작자는 같은 컨테이너 타입의 반복자만을 받아들이는 특정한 함수로 이 템플릿 기능을 대체해서 비슷하게 만들어 놓았습니다.
       
       결과적으로 완전히 같은 컨테이너 타입끼리만 범위 복사를 할 수 있습니다.
       
       예제 코드 보기
       
       
       

       1. //-----------------------------------------------------------------------------
       2. // MSVC 4-6에 들어 있는 STL은
       3. // 멤버 함수 템플릿이 없습니다.
       4.  
       5. void insert(iterator position, // "iterator"는 컨테이너의
       6. iterator first, iterator last); // 반복자 타입입니다.
       7.  
       8.  
       9. //-----------------------------------------------------------------------------
       10. // 결과적으로, 완벽하게 유효한 다음의 코드들은
       11. // MSVC 4-6에서는 컴파일되지 않습니다.
       12.  
       13. istream_iterator<Widget> begin(cin), end; // cin으로부터 Widget 객체를
       14. // 읽기 위해서 begin과 end
       15. // 반복자를 생성합니다
       16. // (항목 6을 보세요).
       17.  
       18. vector<Widget> vw(begin, end); // cin에서 Widget 객체를 읽어 vw
       19. // 에 세팅합니다(역시 항목 6을 보세요);
       20. // MSVC 4-6에서는 컴파일되지 않습니다.
       21. list<Widget> lw;
       22. ...
       23. lw.assign(vw.rbegin(), vw.rend()); // vw의 내용을 lw에 대입합니다
       24. // (거꾸로); MSVC 4-6에서는
       25. // 컴파일되지 않습니다.
       26. SpecialContainer<Widget> scw;
       27. ...
       28. scw.insert(scw.end(), lw.begin(), lw.end()); // scw의 끝에다가 lw 안에 들어 있는
       29. // Widget 객체를 복사합니다;
       30. // MSVC 4-6에서는 컴파일되지 않습니다.
       31.  

       
       
       예제 코드 접기
       
       
       해결책은 여러분이 사용하고 있는 MSVC의 버전과 마이크로소프트 제품에 들어있는 STL을 꼭 써야하는지의 여부에 달려 있다고 볼 수 있습니다.

     • MSVC 버전 4-5에서의 문제 회피법

       앞의 예제에서 문제가 있던 부분들은, 호출 형태는 다르지만 컴파일이 실패한 이유는 똑같습니다. 이 STL에서는 멤버 함수 템플릿이 빠져 있기 때문이지요.
       
       다음과 같이 하면 한 방에 모두를 해치울 수 있습니다. copy와 삽입 반복자(항목 30 참조)를 대신 사용하는 것이지요. 앞의 코드를 이렇게 고쳐 보겠습니다.
       
       예제 코드 보기
       
       
       

       1. istream_iterator<Widget> begin(cin), end;
       2. vector<Widget> vw; // vw의 기본 생성자를 호출합니다.
       3. copy(begin, end, back_inserter(vw)); // cin에서 읽은 Widget 객체를
       4. // vw에 넣습니다.
       5. list<Widget> lw;
       6. ...
       7. lw.clear(); // lw에 들어 있는 이전의 Widget
       8. copy(vw.rbegin(), vw.rend(), back_inserter(lw)); // 객체를 없앱니다; 즉, vw에
       9. // 들어 있는 Widget 객체로 덮어
       10. // 쓰는 것입니다(거꾸로).
       11. SpecialContainer<Widget> scw;
       12. ...
       13. copy(lw.begin(), lw.end(), // lw의 Widget 객체를
       14. inserter(scw, scw.end())); // scw의 뒤에 복사합니다.
       15.  

       
       
       예제 코드 접기
       
       
       하지만 항목 5에서 이야기하고 있듯이, copy 알고리즘은 거의 항상 범위 멤버 함수보다 성능에서 뒤집니다. 따라서 멤버 함수 템플릿 기능이 지원되는 STL 플랫폼으로 업그레이드할 기회가 생기면 copy 방법을 쓰던 곳에 범위 멤버 함수를 되돌려 놓도록 합시다.

     • MSVC 버전 6에 대한 추가적인 문제 회피법

       버전 6에도 앞에서 설명한 MSVC 4-5의 문제 회피법을 쓸 수 있습니다. 하지만 버전 6의 경우 선택 사항이 하나 더 있습니다.
       
       MSVC 4-5에 들어 있는 컴파일러는 원래부터 멤버 함수 템플릿 기능을 지원하지 않았기 때문에 STL도 어쩔 수 없이 그렇게 만들어졌습니다. 하지만, MSVC 6부터는 멤버 함수 템플릿 기능을 지원하기 시작한 것이죠.
       
       MSVC 6 컴파일러와 함께 쓸 수 있는 다른 STL로는 항목 50에서 설명한 SGI와 STLport의 무료 배포본을 우선 들 수 있습니다. 그리고 딩컴웨어(Dinkumware)의 최신 버전의 MSVC 호환 STL을 구입해 써도 됩니다.
       
       SGI와 STLport의 제품은 공짜입니다. 즉 소프트웨어의 공식 지원을 전혀 하지 않겠다는 뜻입니다. 또한 이 제품들은 여러 컴파일러에 대해 동작하도록 설계되었기 때문에 MSVC 6의 대부분의 기능을 사용하려면 직접 수작업으로 구성 정보를 지정해 주어야 합니다.
       
       또한, 다른 MSVC 6 라이브러리(특히 DLL)와 링크할 때에도 번거롭게 신경 쓸 몇 가지 사항도 무시할 수 없습니다. 쓰레딩과 디버깅 세팅에 맞게 이것저것 조절해야 합니다.
       
       이런 일이 성가시다면 딩컴웨어의 MSVC 6용 STL 라이브러리를 권해 드립니다. MSVC 6에 들어 있는 STL을 구현한 회사가 딩컴웨어란 사실을 감안하면, 그들이 만든 최신 라이브러리가 MSVC 6의 구닥다리 STL을 대체할 라이브러리로 가장 적합할 것임은 안 봐도 비디오 아니겠습니까?
       
       딩컴웨어의 STL에 대해 더 알고픈 분은 직접 회사 웹 사이트를 방문해 보세요. https://www.dinkumware.com/입니다.
       
       MSVC 6에 들어있는 STL을 그냥 사용하다가 문제가 생겼을 때에도 딩컴웨어 사이트에 방문하면 도움될 것을 찾을 수 있습니다.
       
       이 사이트에는 MSVC 6 라이브러리의 알려진 버그를 목록으로 만들어 놓고, 버그를 없애기 위해 어떻게 라이브러리를 수정해야 하는지를 알려 주고 있습니다(물론, 라이브러리를 잘못 수정해서 발생한 문제의 책임은 여러분이 지셔야 합니다).
       
       무엇을 사용하든 간에, 대체 라이브러리를 사용하면 멤버 함수 템플릿 이상의 것을 누릴 수 있습니다.
       
       다른 영역에서의 이상한 일치성 문제(string에서 push_back 선언을 실패한다든지 하는...)를 피할 수 있고, 유용한 STL 확장 컴포넌트도 사용할 수 있습니다.
       
       해쉬 컨테이너(항목 25 참조)와 단일 연결 리스트(slist)가 여기에 포함되지요.
       
       SGI와 STLport의 배포본은 이외의 아주 다양한 비표준 함수자 클래스도 제공합니다. select1st와 select2nd 같은 것들이지요(항목 50 참조).