The Winner Takes It All

 우연히 웹서핑을 하던 도중, Visual Leak Detector란 녀석을 알게 되었다.
(사실, 제법 이전부터 알고는 있었지만, 쓰지는 않았다.)

사용법은 매우 단순하다. 코드에 #inclue <vld.h>를 추가해주고, 디버그 모드로 돌려보면, Memory Leak이
존재할 경우, 사정없이 뱉어준다.

이 녀석을 이용해, 현재 구현중이던 프로그램에 적용해보니, Memory Leak이 발견되었다는 것이 아닌가?!
허거덩..-_- 분명, MS 자체의 디버그 모드로 돌렸을 때는 발견되지 않았었는데..!!!

"뭐야뭐야! 나같은 천재에게 Memory Leak은 어울리지 않아-ㅁ-;; 분명, Visual Leak Detector의 버그 일거
야..-ㅁ-" 같은 헛소리를 하면서.. 차근차근 Memory Leak이 발생할만한 원인을 탐색하던 바... 이르게 된 곳
은 STL의 ifstream이었다.

난 모든 코드를 배제하고, MFC의 Dialog 기반의 프로젝트를 하나 생성했다. 그리고, 단지 2줄의 코드만 추
가했다.

ifstream fin("sample.txt");
fin.close();

그랬음에도.. 우리의 Visual Leak Detector는 Memory Leak을 찾아냈다. 여기에도 또 문제가 있는 것이,
"sample.txt"란 파일이 존재할 경우에만, Memory Leak을 뱉어냈다. 즉, 존재하지 않는 파일의 경우엔 파일
Open을 해도 Memory Leak을 뱉어내지 않았다.

나는 확인을 위해.. 데브피아에서 질문을 올렸는데..

A님: Visual Leak Detector를 사용해보지는 않았으나 바운스체커도 메모리릭이 발견되네요. stl부분에서

B님:

VS6.0에 포함되어 있는 STL 버전이 상당히 구닥다리 입니다.

딩컴웨어의 구닥다리 버전이 포함되어 있어서 6.0에서는 stl을 사용할때

외부 STL을 사용하곤 했지요..

STL_Port 같은것을 사용하세요..

2003 이상 버전에서 포함되어 있는 STL을 그대로 쓰셔도 상관 없습니다.


친절하게 두 분의 답변이 돌아왔다. 결국엔 Visual Studio 6.0에 포함되어 있는 STL에 문제가 있는 것이다.
난 좀 더 확인을 위해 (왜케 집요해졌는지 모르겠다.) 짧은 영어로 MSDN을 헤맸는데, Visual Studio 6.0에서
STL string으로 Multi-Thread 프로그램을 구현할 경우, Memory Corruption이 발생할 수 있다는 MS의 얘기를
발견할 수 있었다.
MS에서 제시하는 해결책 역시 데브피아에서 B님이 답변해준 것과 비슷하게, Visual Studio 2003 이상 버전
을 쓰거나 STL 3rd party 라이브러리를 쓰라는 얘기였다.

난 이제 껏, STL하면, SGI STL이 전부인줄 알았을 정도로 참으로 무지했다.
알고보니, gcc는 SGI STL을 기반으로 gcc 컴파일러에 맞게 구현해놓은 것을 쓰고 있고, MS는
Dinkumware 사의 STL을 쓰고 있었다. 그리고, Borland C++ Builder는 최근까지 Roguewave의
STL을 쓰다가, STL Port로 넘어갔다.

C++ 표준이 되어버린 STL일지라도 각 회사마다 STL은 조금씩 특징이 있었다.
대표적으로 STL Port와 Dinkumware의 STL의 list<> 클래스의 list 크기를 반환하는 size() 함수를 예로 들
면.. (http://crowmaniac.net/crowmania/ 를 참고한 어느 분의 블로그에서 참고했습니다.)

Dinkumware 사의 STL에서 제공하는 list의 size() 함수는 시간 복잡도가 O(1)이었다.
size_type size() const{   return (_MySize);   }

반면에, STL Port에서 제공하는 list의 size() 함수는 시간 복잡도가 O(n)이었다.
size_type size() const
{
       size_type _result = distance(begin(), end());
       return _result;
}

distance() 함수가 Bidirectional iterator기 때문에 O(n)인 것이다.

잉?! 그럼, 두 말 할 나위 없이, Dinkumware 사의 STL이 좋은 것이냐?
꼭, 그런 것은 아니다..^^

size()를 O(1)으로 구현한 Dinkumware 사의 STL은 태생적으로 O(n)의 splice(끼워넣기)를 가지는 반면에,
STL Port는 O(1)의 splice만 가진다.

다시 얘기하면, size()를 자주 호출해야할 코드에서는 Dinkumware의 STL이 낫고, splice를 자주해야 하는
코드에서는 STL Port가 낫다고 볼 수 있다.

뭐, 난 갠적으로 정렬이 필요하지 않은 데이터의 경운 걍 vector를 쓰고, 정렬이 필요한 경우엔 Hashtable을
구현한 map을 쓰기 때문에-ㅁ-;; list를 잘 쓰지 않는다.

암튼.. 이제 STL Port를 깔러 가야겠다-ㅁ-

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.