어떻게 보면 유익하기도, 어떻게 보면 시간 낭비일 수도 있는 글타래:
안녕하세요^^ STL은 항상 논란거리인것 같습니다^^;

솔직히 STL을 빡시게 쓴 적이 얼마되지 않는다. 과거 회사에서 작업한 코드들은 100% 윈도우 기반이었고, 마침 MFC 7.0부터 도입된 MFCATL 라이브러리가 사용하기 너무 좋아서 계속 이 녀석을 사용했다. 예전 MFC collection 에 없던 Red-black tree도 추가되었고, 특정 타입의 여러 행동을 정의하는 Traits (일종의 functor 같은 것)도 사용하기가 무척 쉬웠다. CString이나 CList와는 달리 CAtlString과 CAtlList는 의존성도 약해서 non-MFC 코드에도 쉽게 사용할 수 있다. 무엇보다 소스를 이해하는데도 전혀 부담이 없었고 팀원들도 사용하는데 어려움이 없었다. 내가 주로 만들었던 프로그램은 게임 서버와 같은 성격은 아니고 패키지용 소프트웨어라서 그런지 STL을 써야한다는 그런 주변의 이야기도 잘 듣지 못하였다.

어차피 최적의 속도를 위해서는 포인터 기반의 자료구조 자체가 쥐약이다. 포인터 기반의 리스트, 트리, 혹은 그래프를 순회하는 경우를 흔히 pointer chasing이라고 부른다. 순회를 하는 과정이 새로운 주소로 점프하는 과정이라 캐쉬 미스를 엄청 유발한다. 그래서 정말 성능 크리티컬한 상황이라면 최대한 locality를 높일 수 있는 자료구조로 만들어야 한다.

나도 STL의 난해한 소스코드와 짜증났던 iterator 패턴 때문에 STL을 좋아하지 않았다. for 문이 두 줄 이상으로 나뉘어야 하는 경우가 다반사다. ::iterator를 쳐야하는 삽질은 typedef로 최대한 막으면 되지만 항상 타입을 맞춰야 하는 것이 귀찮기는 하다. 여전히 pair의 first, second와 같은 작명 센스는 맘에 들지 않는다. empty라는 메소드가 '비우다'라는 동사로서의 empty가 아니라 IsEmpty라는 성격인 것도 헷갈리기 딱 좋다. string 객체를 부득이하게 printf로 찍어야 하는 경우, .c_str()을 부르지 않아 삽질을 계속한다. 플랫폼마다 map의 이터레이터 구현이 달라 삽질한 경우도 있다.

그러나 쭉 써보면 이런 설계에 고개가 끄덕여진다. algorithm이나 functional에 있는 것들을 쓰면서 "내가 참 뭘 몰라도 한참 모르고 STL을 욕했네" 라는 반성이 들면서 다시 C++ 책을 봐야겠다는 생각이 든다. 과거 삽질을 해서 짰던 코드들을 이렇게 표현할 수도 있구나라고 깨닫고 있는 중이다. 그런 깨달음이 여러 경우 있었는데 말하면 나의 무식이 탄로날 것 같아 그냥 넘어가겠다.

더 현실적인 이유를 대자면, STL이 바보 같다고해서 자신이 직접 자료구조를 만들었다 하자. 내가 장담컨데, 전혀 획기적으로 새로운 자료구조가 아닌 이상, 이건 99% 삽질이다. 무시하는 것 처럼 들려도 하는 수 없다. 당신이 만든 자료구조가 STL보다 더 안전하고 더 빠르게 돌아가기를 기대하는 것이 쉽지 않다. STL이 완벽하지는 않지만 그렇다고 당신이 만든 자료구조도 완벽하지 않다.

어렸을 때는 MFC의 Doc/View 구조가 너무 짜증났었다. 왜 저렇게 불필요한 추상화를 둬서 더 복잡하게 하느냐고. 그래서 저거 다 날리고 직접 날 코딩했다. 그러다가 좀 복잡한 프로그램을 짜면서 나름대로 추상화를 하고 그러다보니 결국 MFC Doc/View 구조 비슷하게 흘러가는 것을 보고 MFC 설계자를 욕했던 나 자신을 반성한 적이 있었다. 여전히 Doc/View는 잘 안쓰지만 그것에 깔린 설계 철학은 훌륭하고 본 받을만 하다.

그러니까 결국 아는 만큼 보인다. 중학교 때였나 BASIC만 쓰다가 처음 C코드를 보고 도대체 #, ; 이런 괴상한 기호들이 왜 붙는거야? 라고 투덜거렸던 기억이 떠오른다.

추가.

#1. 위에서 string을 출력하는데 .c_str()을 호출하지 않아 삽질했다고 했다. 예를 들어, 아래 m_nameRTN이라는 변수는 STL string 타입이고 이걸 printf의 "%s"로 출력하고 싶다고 하자. string 객체는 묵시적인 const char*로의 변환이 없다. 반면, MFC/ATL의 CString은 이 캐스팅이 함축되어있어 그냥 클래스 객체를 날려도 문제가 없다. 아쉽게도 VC++ 컴파일러는 이런 경우 어떠한 warning을 만들어내지 않는다. 반면, 인텔 알바해서 자꾸 인텔 제품 광고하는 것 처럼 보이는데, 정말 컴파일러는 인텔 C/C++ 컴파일러가 gcc, VC++ 컴파일러보다 좋다. 특히 아래와 같은 경우에도 친절히 warning을 띄어준다. 게다가 에러가 난 column 위치까지 잡아준다. 너무 맘에 들어!!!!!! (자바나 C#는 원래부터 되는건데..) 인텔 C/C++ 컴파일러 for Windows는 비주얼스튜디오 전 버전에 아주 찰싹같이 달라붙어 사용하기 무지 편하다. 윈도우 버전은 돈 주고 사야하는 것이 좀 단점이지만... 트라이얼은 가능. (수정: 이 printf 출력 경우는 const char*로의 캐스팅이 일어나는 것이 아니라 MFC/ATL의 CString 객체의 첫번째 데이터가 char* 변수라서 제대로 표현이 되는 것입니다.)

Compiling with Intel(R) C++ 10.1.022 [IA-32]... (Intel C++ Environment)
Function.cpp
Function.cpp(165): warning #1595: non-POD (Plain Old Data) class type passed through
ellipsis
    fprintf(g_outLoopDiscovery, "%s: %d BBs found.\n", m_nameRTN, m_numBB);
                                                       ^

#2. template으로 많은 타입에 대해 instantiation이 되어 code bloat을 우려하는 대목도 있었는데, 요즘 컴파일러 그렇게 바보가 아니다. int, UINT32 같은 타입에 대해 중복된 템플릿 코드가 생성되어 있어도, whole program 최적화 (=IPO)로 동일한 코드들은 아예 하나로 합쳐 버린다.

#3. 그래도 때론 STL 소스코드가 MFCATL 컬렉션 소스처럼 좀 보기가 편했으면 얼마나 좋을까라는 생각은 해본다. 이제는 자꾸 들여다보니 좀 익숙해졌다만... 난 템플릿 공부를 <atlcoll.h>에 있는 코드를 보고 꽤 많이 했다.

#4. 많은 사람들이 "표현"에 굉장히 집착하는 것 같다. STL이 욕 먹는 주요한 이유 중 하나가 코드가 이쁘지 않아서 그렇다는 것인데 물론 나도 코드 표현에 집착하던 때가 있었다.