준형's 블로그

제목 :  전병선의 Component Development with Visual C++ & ATL
출판사 : 영진.COM
저자 : 전병선

내가 이 책을 구입한 것이 2005년 10월쯤 이었던 것으로 기억된다.
당시에 VC++ 경력 1년 정도의 풋내기였고,
그것도 중간에 수술로 두달이나 쉬어서 정말 엉망진창의 신입이었다.

이 책을 구입하게 된 계기는 ActiveX 업로드 컴퍼넌트 개발 때문이었다.
다음카페에서 글을 쓸 때 하단에 보이거나
데브피아에서 '덱스트 업로드'라고 판매하는 그런 류의 물건 말이다.

그 당시 나는 MFC도 많이 서툴렀고,
COM/ActiveX는 문외한이었으며,
웹이라면 끔찍히 싫어하던 그런 시절이었다.
그런 본인이 이 책을 길잡이 삼아 한 달 동안 미친듯이 공부해서 결국 완성을 시켰고,
그 뒤로 본인은 회사의 ActiveX 전담 개발자가 되었다.
그리고 후에 Mozilla Plugin까지 전담하게 되었다.

뭐, 어쨌든지 당시 이 책이 없었더라면
나는 그 프로젝트를 성공하지도 못했을 것이고,
지금과 같은 실력과 자신감을 얻지도 못했을 것이다.

COM을 공부하려고 마음 먹었다면,
꼭 이 책을 한 번 보기를 권유하는 바이다.
단, 이 책을 보며 실무에 적용할 때
책에서 알려주지 않았던 아쉬운 내용들이 조금 있기에
평가는 별 네개로 결정하였다.

우리는 윈도우 프로그래밍을 할 때, 엄청난 빈도로 파일을 열거나 저장한다.
일반적인 워드프로세서나 포토샵, 뮤직플레이어 등을 볼 때,
오히려 파일을 열고 닫는 작업이 없는 프로그램을 찾는 것이 더 힘들 정도이다.

일반적으로 파일을 열 경우 우리는 아래와 같은 다이얼로그를 접하게 된다.

이 다이얼로그를 여는 방법에서 당연히 MFC와 API는 차이가 있다.
아래는 MFC 코드이다.


아래는 API 코드이다.


MFC는 3줄인데 반해 API는 11줄이나 된다.
두 코드는 정확이 똑같은 모양과 특성의 다이얼로그를 만든다.

물론 그렇다고 위의 상황으로 MFC가 무조건 우월하다는 것은 아니다.
개인적으로 프로젝트 상에서는 후자인 API를 자주 쓴다.
그 이유는 본인의 주 업무가 ATL/COM 관련 프로그래밍이기 때문에
MFC를 쓸 기회가 매우 적기 때문이다.

그러나 MFC를 이용해 테스트 코드를 짜는 빈도는 엄청나게 많다.
새로운 API나 클래스를 쓰거나 라이브러리의 기능 중 의심나는 부분이 있으면
테스트를 위해 어김없이 콘솔 프로젝트 또는 MFC 다이얼로그 프로젝트를 생성한다고 보면 된다.
이 때, 단순 테스트를 위해 후자와 같이 긴 코드를 만드는 것은 상당한 낭비라고 생각한다.
그래서 요즘에는 전자인 MFC 다이얼로그 코드를 많이 쓰게 되었다.

결국 MFC와 API는 우월성 관계 보다는
필요와 효율의 문제라는 것을 알 수 있다.

< about >

작년 12월 6일 STLport Ver. 5.1.0 이 Release 되면서
설치방법이 조금 변경 되었다.
새로운 설치방법을 포스팅한다고 글을 적은게 1달 전이었는데
이제서야 실행하게 되었다.
설마 이 글을 기다린 사람은 없겠지만,
만약 있다면 죄송스럽게 생각하면서 글을 시작하려고 한다.

또한, 이 글을 읽는 모든 분들께 다시 한 번 당부한다.
퍼가는 것은 자유지만 출처는 분명히 해줬으면 좋겠다.


< intro >

먼 옛날 STL은 한낱 문서상의 표준이었고,
내가 C++에 입문하던 때만 해도 STL은 아는 사람들 끼리의 물건이었다.
그러나 지금은 STL을 모르고 C++을 한다고 말할 수 없게 되었다.
그리고 STLport는 현존하는 STL 라이브리 중 가장 사랑받는 놈이다.

물론 VC++에도 내장 STL이 존재한다.
그래나 현재는 인식이 많이 바뀌었다 해도 많은 사람들이 내장 STL의 사용을 만류하고 있다.
그리고 본인도 그 생각에 동감하는 바이다.
개인적인 이유는 다음과 같다.
MSVC 내장 STL은 딩컴웨어에서 판매하는 상용 라이브러리인데,
VC 구매시에는 이미 이 라이브러리의 버전은 구버전이 되어버린다.
그리고 그에 대한 업그레이드에는 추가 비용이 들게 된다.
그에 비하면 STLport는 무료로 지속적인 업데이트를 해 나가고 있다.

현재 배포되는 STL 라이브러리들에 대한 이야기를 보려면
'Effective STL'의 50장과 부록B를 보기 바란다.


< download >

STLport는 http://sourceforge.net/projects/stlport 에서 받는다.
www.STLPort.org 라는 공식 홈페이지가 있으나
현재 업데이트가 중지된 상태이며
최신 버전은 sourceforge 에서 관리된다.
이 글이 작성되는 시점에서 배포되는 최신 버전은 5.1.0 Release 이다.


< uncompress >

STLport-5.1.0.zip 파일을 받아 압축을 풀자.
본인은 라이브러리들의 관리를 편하게 하기 위하여
VC 관련 라이브러리는 모두 F:\MSVC\Library\ 경로에 모아 놓는다.

압축이 해제되면 STLport-5.1.0 폴더가 생성된다.

< before compile >

컴파일에 앞서 옵션을 설정해 주어야 한다.
옵션 파일의 위치와 이름이 \STLport-5.0.1\stlport\stl_user_config.h 에서
\STLport-5.1.0\stlport\stl\config\user_config.h 로 바뀌었다.
해당 파일을 열어 보자.

먼저 Platform SDK를 사용한다면, 다음의 주석을 제거한다.

또한 다음의 선언문의 주석도 해제하자.

이 선언은 컴파일 결과 자체에는 영향이 없지만
컴파일 중 현재 링크되고 있는 라이브러리를 빌드 창에 표시 하겠음을 나타낸다.
따라서 프로그램이 STLPort 라이브러리를 연결하고 있는지
컴파일 중 확인할 수 있다.


< compile >

컴파일을 위해서는 반드시 콘솔에서 작업해야 한다.
그러므로 아래의 설명은
전부 콘솔에서 이루어 진다는 것을 명심하자.

먼저 콘솔 창을 연다.
모르겠으면 'Windows Key' + R 하면 나타나는 창에 cmd 라고 적는다.

만약 VC++.NET 2003을 깔았다면
아래와 같은 패스가 있을 것이다.

C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin

위 폴더에 vcvars32.bat 파일이 있다.
이 파일을 콘솔에서 실행시킨다.
그러면 환경이 준비 됐다는 의미 비슷한 말이 나온다.
(영어라 장담 못하겠다. -_-a)

이제 커맨드 창에서 F:\MSVC\Library\STLport-5.1.0\build\lib 폴더로 들어간다.
다음과 같이 입력한다.

이제 STLport는 VC++ .NET 2003 컴파일러를 사용하게 된다.
마지막으로 인스톨 명령을 친다.
이제 컴파일 끝날 때까지 기다리도록 하자.

컴파일이 완료되면 아래와 같이 새로운 두 개의 폴더가 생긴다.
이 중 \STLport-5.1.0\bin\ 폴더에 생긴 세 개의 *.dll 파일을 system32 폴더에 복사한다.

< after compile >

컴파일이 다 끝나면,
VC++.NET 2003에서 경로 지정을 해줘야 한다.
VC++.NET 2003을 열고 도구에 가서 옵션을 선택하면 창이 열린다.
그럼 좌측 목록에 Projects 를 선택하고
하위의 VC++ 폴더를 선택한다.
우측 창의 우측 상단 콤보박스에서 포함 파일을 선택한 후
리스트에 D:\Library\STLport-5.0.1\stlport 를 추가로 적어
리스트 맨 위에 놓는다.




< finale >

이제 마음놓고 사용하시라~!!
(@,.@)>

제목 :  초보자를 위한 한글 Visual C++.NET 21일 완성
원서 : Teach Yourself Visual C++.NET in 21 Days (SAMS)
출판사 : 인포북
저자 : Davis Chapman
번역 : 김동현
감수 : 곽용재

이 책은 완벽하게 초보자를 위한 책이다.
초보자가 아니면 읽을 필요도 가치도 없다.

그러나 당신이 C++도 잘 모르면서 윈도우 프로그래밍에 대한 경험도 없고
프로그래밍의 세계에 처음 발을 딛으려는 사람이라면
이 책은 당신의 구원자가 될 것이다.
이 책은 그 이유만으로 별 네개의 자격을 갖추었다.

이 책은 내가 맨 처음 VC++에 입문할 당시 본 책이다.
이 책의 목적은 단 한가지...
최대한 빠르고 신속하게 Visual Studio와 MFC, 그리고 MFC Wizard에 친숙하게 만드는 것이다.
이 책에는 C++의 심오한 세계나 API와 MFC의 강력함은 그림자도 보이지 않는다.
어짜피 그것은 당신이 컴파일러로 "Hello World"를 컴파일할 수 있게 된 뒤의 일이니까...

실제로 이 책이 말하는 대로 21일이나 필요하지도 않다.
하루 분량은 평균적으로 대략 2시간 전후이며,
실제로 눈여겨 볼 사항은 댈략 10여개 전후의 챕터 뿐이다.

본인은 다음과 같은 커리큘럼을 추천한다.
먼저, 첫주인 1~7일을 주의깊게 읽고 따라하라.
그리고는 '찰스 페졸드의 Programming Windows' 같은 책을 읽는다.
2주째의 폰트, GDI, 파일과 같은 주제는 API와 함께 그 원리를 알아야만 한다.
API와 기본 원리를 어느 정도 익힌 후 2주째 이야기를 참고하라.
3주째는 좀 더 높은 차원의 이야기이며
MFC로는 그저그런 테스트 프로그램 이상의 퀄리티를 얻을 수 없다.
이 주제를 다루는 다른 책을 보는 것이 낫다.

다시 한 번 강조 하지만,
이 책은 윈도우 프로그래밍을 위한 첫발로는 더 없이 훌륭한 책이다.
그 이유로 나는 별넷을 부여했다.
그러나 그 이상 앞으로 전진하기 위한 파트너로는 0점이다.
그것이 별다섯이 되지 못하는 이유이다.

만약 당신이 한달 이상 이 책을 곁에 둔다면,
당신은 정말 게으르거나 프로그래밍 자체에 소질이 없는 것이다.

앞서 보인 Compile 문제 이외에
런타임 에러 처리에서도 차이를 볼 수 있다.
이것은 유효하지 않은 윈도우 핸들에 대한 런타임 처리에 관한
API와 MFC의 차이 점을 보여 준다.

아래는 MFC 코드이다.

아래 코드는 위 함수의 내부 구현이다.


윈도우 핸들을 'ASSERT()'로 검사를 하고 있다.
이는 윈도우 핸들이 유효하지 않으면 디버깅 시에 프로그램을 강제 중단 하며,
릴리즈 모드에서는 아무런 검사 없이
API 함수인 'InvalidateRect()'를 호출한다는 것을 의미한다.

여기서 판단해야 할 것은
위 지점에서 반드시 유효한 윈도우 핸들이 존재해야만 하는가에 있다.
위의 코드에서는 선택권이 없으며,
디버깅에서 운 나쁘게 유효하지 않은 'ASSERT()'에 걸린 적 없이 릴리즈가 배포된다면,
사용자는 심각한 시각적 문제를 보게될 수 있다.

그렇다면 우리는 어떤 성택을 해야 할까?
API에서는 두 가지 선택을 할 수 있다.

첫째, 핸들이 유효할 경우에만 'InvalidateRect()'를 호출한려 한다면,



위와 같은 검사를 해야할 것이다.
반면에 절대로 핸들은 유효해야하며,
디버깅시 반드시 윈도우 핸들이 유효하지 않은 상황을 모두 제거해야 한다면,


위와 같은 MFC와 유사한 구현을 해야할 것이다.

물론, 확실히 안전한 코드를 위해서라면 둘을 혼합할 수도 있다.

우리가 생성한 차일드 윈도우 또는 다이얼로그의 컨트롤들은
각각의 우리가 지정한 고유한 아이디를 갖는다.
그리고 이 아이디를 통해 우리는 윈도우를 얻을 수 있다.
이 때 존재하지 않는 ID에 대한 컴파일 에러에서 다음과 같은 차이를 보인다.

아래는 MFC 코드이며 'GetDlgItem()'은 "CWnd*'를 반환한다.

이 때, 'IDC_BTN_TEST'는 존재하지 않는 식별자 이다.
컴파일 에러는 다음과 같다.


'IDC_BTN_TEST'가 존재하지 않음으로써 'GetDlgItem()'역시 유효하지 않은 식별자가 되고
연쇄 에러가 발생한 것이다.

아래는 API 코드이며 'GetDlgItem()'은 HWND를 반환한다.


역시, 'IDC_BTN_TEST'는 존재하지 않는 식별자 이다.
컴파일 에러는 다음과 같다.


위에서는 정확하게 문제점만을 가리키고 있다.

포인터에 대한 좀더 많은 참조라던지 같은 유형의 코드가 여러 곳에 산재해 있을 때,
쓸데 없이 많은 에러 메세지는 디버깅을 어렵게 한다는 점에서
윈도우 핸들을 다루어야 하는 동작에서는 API에 장점이 있다고 하겠다.

윈도우 프로그래밍을 하면
같은 윈도우 개발자들 사이에서도
MFC와 API 사이에 대해 의견이 분분하다.

물론 둘 모두를 골고루 사용하다 보면
둘 사이에 개발속도와 코딩량 등에 크게 차이가 없다는 것을 알게 될 것이다.
그리고 둘 사이에 균형을 이루어 빠르고 안전한 코드를 이루는 방법을 얻을 수 있을 것이다.

그러나 둘 사이에 차이점이 있다는 것은
C와 C++ 이라는 기본적인 차이만큼이나 명확하며,
어느 쪽을 사용하느냐에 따라 이점과 단점이 있다는 것도 사실이다.

개인적인 성향으로는 API를 분명히 선호한다.
그러나 나 개인의 기호와 선입견에 사로잡혀 아둔한 코드를 만들고 싶은 생각은 없다.
이전에도 API와 MFC의 장단점을 느낄 수 있는 경험이 많이 있었다.
머리가 나빠 그 상황을 기억하지는 못하지만,
그 경험이 지금의 균형감을 유지하는데 상당한 기여를 해 주었다.
뭐, 그래서 이러저러한 이유로
나의 기억을 환기시키고
API와 MFC의 중도를 찾기 위한 앞으로의 경험을
이 글을 보게 될 누군가와 공유하고자 한다.

제목 :  IT EXPERT 3D 게임 프로그래밍
출판사 : 한빛미디어
저자 : 김용준

나는 이책을 지난 주부터 시작한 Direct3D 프로젝트를 진행하기 위해
사장님으로부터 직접 받았다.
이 책을 훝어본 결과
개인적으로 생각하기에 최악의 DirectX 도서라고 생각한다.
절대 보지 말기를...

이 책은 어떤 독자층을 노리고 쓴 책인지 알 수 없다.
만일 초보자를 위한 책이라면
COM 과 같은 기반 기술에 좀 더 중점을 두어야 했고,
각각의 챕터에 쓰인 DirectX 함수들에 대한 설명과 코드에 대한 설명이 적절한 수준이 되어야 했다.

반대로 독자가 윈도우 프로그램과 COM을 알고 있다는 가정 하에
책을 진행 했다고 한다면,
책을 그렇게 소스코드로 도배해서 두께를 부풀릴 필요가 전혀 없었다.
함께 배포한 CD의 샘플을 열어 보는 것으로 충분하니까 말이다.

결국 두께는 두꺼운 반면
DirectX 기술에 대한 이야기도 거의 없고
3D에 대한 기술적 이야기도 초 기초적인 것들 뿐이고
소스코드는 눈이 돌아가게 많이 프린트 했는데
실제로 소스코드에 대한 설명 자체도 거의 없을 뿐더러
예제에 쓰인 함수도 이름만 덩그러니 있을 뿐이다.
아마 MSDN을 참고하라는 의미인 것 같은데...
그럼 설명도 안해 줄 소스를 왜 통채로 프린트 해 놓았을까?

마지막으로 샘플 코드의 품질이 최악이다.
개인적으로 4부 8장의 샘플을 참고했는데,
XML 파서는 눈뜨고 볼 수 없어 통째로 새로 만들어 넣었다.
네이밍이나 스타일의 문제가 아니다.
기술의 문제도 아니고 라이브러리 적용의 문제가 아니다.
그냥 순수하게 코드를 쓰는 습관에 기본이 안되어 있다는 느낌이다.
CD를 여는 순간 아는 사람은 알 것이다.
필요 없이 그득한 주석과 정리 안된 소스의 흔적들...
정의와 구현의 분리가 모호해지게 만드는 헤더와 파일들...
국내 서적의 샘플코드가 조악한 것은 알고 있지만,
직설적으로 말해 참혹했다.

< about >

이 문서 역시 STL 문서와 같은 역사를 갖고 있다.
단, Naver 등을 참고한 이전 버전에서 오류가 있었기 때문에
이번에 다시 검토하여 boost의 문서를 토대로 상당히 수정을 가했다.

다시 말하지만, 퍼가는 것은 자유로우나 출처는 분명히 해주길 바란다.


< intro >

boost Library는 오픈소스로 진행되는 C++ 라이브러리 그룹으로
이에 대해 'Effective STL'의 50장에서 간단히 소개하고 있다.

간단히 말해 boost 는 다음 STL표준 채택을 위해 준비된
C++ 라이브러리의 확장판이다.
boost 가 갖는 라이브러리는 상상 이상으로 엄청나다.
(사실 겪어봐야지 말로는 표현이 안된다. ^^)
이미 이 중 일부는 다음  STL 표준으로 내정된 것들도 있다.
다음 표준안이 발표되면 'boost::' namespace 가 아닌
'std::' namespace 로 쓰게 된다는 의미다.

이미 STL 서적은 넘쳐나지만,
boost 관련 서적이 보이지 않는 것으로 봐서
아직 국내에 boost 가 보편화 되기까지 시간이 좀 걸리지 않을까 한다.
뭐, boost 자체를 책 한권으로 묶는 것도 불가능 하다고 생각하지만 말이다.
boost의 Graph 라이브러리에 관한 번역서를 한권 보기는 한 것 같은데...

음 잡설이 너무 길었다.
이만 설치로 넘어가자.


< download >

boost Library의 공식 홈페이지는 www.boost.org 이다.
다운로드는 http://sourceforge.net/project/showfiles.php?group_id=7586 에서 받는다.
현재 정식 버젼은 1.33.1 이며,
다운 받을 파일은 boost_1_33_1.exe 와 boost-jam-3.1.12-1-ntx86.zip 두 가지이다.


< uncompress >

boost_1_33_1.exe 실행시키면 압축 해제할 경로를 묻는다.
본인은 D:\Library 에 압축을 푸는데, 그러면 D:\Library\boost_1_33_1 이 생긴다.

이제 boost-jam-3.1.12-1-ntx86.zip 의 압축을 풀면
bjam.exe 라는 실행 파일이 생긴다.
이 파일을 D:\Library\boost_1_33_1 에 복사한다.


< before compile >

boost 는 라이브러리의 집합이므로
STLPort 에서 iostream 사용을 위해 컴파일 했던 것처럼
컴파일을 필요로 하는 라이브러리에 대해 컴파일 해주어야 한다.
단, STLPort와 같은 일괄 적용이 아니라
개별 라이브러리 마다 필요로 하는 옵션이 다르므로
해당 라이브러리의 문서의 Installation 항목을 잘 읽고
그에 맞추어 컴파일 해주어야 한다.


< compile >

이 부분은 Compile 이 필요한 사람만 하면 된다.
컴파일이 필요 없는 라이브러리를 사용하는 사람은 다음으로 넘어가도 된다.

업무상 프로젝트에 적용한 컴파일 필요 라이브러리는
iostreams, regex, thread 정도이다.
여기에서 regex 는 Adobe 사의 제품에서도 DLL 형태로 쉽게 찾아볼 수 있다.
컴파일 방법은 거의 같으며 약간의 옵션 차이만 있으니
세 가지를 따로 컴파일 한다고 해서 긴장할 필요는 없다.

boost 역시 콘솔창에서 컴파일을 진행하도록 하게 되어있다.
만약 STLport를 설치할 때 사용한 콘솔창을 닫지 않았다면 그 창에서 그대로 진행하도록 하고,
콘솔창을 새로 열었다면 vcvars32.bat 를 다시 실행하도록 한다.

먼저 regex 와 thread 는 특별한 옵션이 필요 없어 명령행 인자가 같다.
콘솔에서 직접 명령을 적어 주어도 좋지만,
편의성과 유지보수를 위해 개인적으로는 '*.bat' 파일로 컴파일 옵션을 저장해 놓기를 권장한다.
batch 파일의 내부는 다음과 같다.
콘솔에서 각 줄을 순서대로 쳐도 같은 효과가 있다.

위 옵션은 STLPort-5.0.1 을 연결하여 컴파일 하는 것이며,
앞서 쓴 'STLPort-5.0.1 설치' 문서의 결과물에 맞추어져 있다.
경로 등이 다른 사람은 문서를 보고 조정해 주기 바란다.

다음은 iostreams 컴파일용 batch 파일이다.

문서를 보면 알겠지만, iostreams 는 공개 압축 라이브러리인 zlib 와 bzip2 를 포함할 수 있다.
iostreams 는 이 두 라이브러리를 이용해 압축 스트림 필터를 생성한다.
iostreams 와 iostreams 필터의 사용법은 boost 문서에 친절하게 나와있다.

컴파일 결과물은 일단 D:\Library\boost_1_33_1\bin\boost\libs 경로에 만들어지며,
D:\Library\boost_1_33_1\stage\lib 로 복사가 되는데,
일부는 자동으로 복사가 이루어지지 않으므로
첫번째 위치에서 직접 두번째 위치로 결과 파일들을 복사해 주어야 한다.

< after compile >

컴파일이 다 끝나면, VC++.NET 2003에서 경로 지정을 해줘야 한다.
방법은 STLPort 와 동일하다.

포함 파일에는 D:\Library\boost_1_33_1 를 추가해주며,
라이브러리 파일에는 E:\Library\VC\boost_1_33_1\libs 를 추가하도록 한다.
단, 일부 라이브러리를 컴파일 했다면,
라이브러리 파일에 D:\Library\VC\boost_1_33_1\stage\lib 도 추가로 등록한다.
우선순위는 STLPort 바로 아래 놓도록 한다.
그리고 D:\Library\VC\boost_1_33_1\stage\lib 에 생성된 '*.dll' 파일들을
'C:\windows\system32' 폴더에 복사한다.


< finale >

이제부터는boost를 사용하면 된다.
사용법은 boost 문서를 참고하기 바란다.

< about >

이 문서는 2004년 본인의 작업용 문서로 시작되었다.
첫 게시물은 2005년 10월  STLPort 4.6.2를 기준으로 싸이월드에 게시 했으며,
2006년 3월 다음의 스터디 카페(지금은 버려져 있다. ㅠ.,ㅠ)에 게시한 것을
버전업 하여 이곳에 옮기는 것이다.
퍼가는 것은 자유지만 출처는 분명히 해줬으면 좋겠다.


< intro >

STLPort는 현존하는 STL 라이브리 중 가장 사랑받는 놈이다.
내가 C++을 본격적으로 입문하던 때만 해도
STL은 아는 사람들 끼리의 물건이었다.
STL의 존재를 알게 된 것도 지금 다니는 곳의 면접을 준비 하면서 였고,
STL을  공부할 당시만 해도 한국어로 된 레퍼런스 서적은 단 두 권 뿐이었다.
하나는 'C++ Standard Library 튜터리얼.레퍼런스 (원서 : C++ Standard Library)'이고,
다른 하나는 'STL 튜터리얼.레퍼런스 가이드 (원서 : STL Tutorial and Reference Guide)'이다.
나는 당시 전자를 선택했고, 몇 달 전 불가피하게 후자를 구입하게 되었으나
개인적으로 'C++ Standard Library 튜터리얼.레퍼런스'를 추천한다.

VC++ 상에서 많은 사람들이 MSVC 내장 STL의 사용을 만류하고 있으며,
본인도 가능하면 STLPort로 대체를 권한다.
여러가지 이유가 있지만,
MSVC 내장 STL은 딩컴웨어에서 판매하는 라이브러리인데
이는 제품 판매 초기에 내장되므로 사용하다보면 너무 뒤쳐진 버전이 된다는 말이며,
라이브러리를 업그레이드를 위해서는 추가 비용을 지불해야 한다는 것이 문제이다.
실제로 아직도 MSVC 6.0 이 상상 이상으로 많이 사용되는데,
MSVC 6.0 내장 STL은 형편없는 버그 덩어리로 간주되기도 한다.

현재 배포되는 STL 라이브러리들에 대한 이야기를 보려면
'Effective STL'의 50장과 부록B를 보기 바란다.


< download >

STLport는 http://sourceforge.net/projects/stlport 에서 받는다.
www.STLPort.org 라는 공식 홈페이지가 있으나
현재 업데이트가 중지된 상태이며
최신 버전은 sourceforge 에서 관리되는 듯 하다.
이 글이 작성되는 시점에서 정식 버전은 5.0.2 이며,
버전 5.1.0 이 RC2까지 진행된 상태이다.
개인적으로 5.0.2 RC2 를 설치한 적이 있으나,
뭔가 이상하여 현재 5.0.1 을 사용하면서 5.1.0 을 기다리는 중이다.


< uncompress >

STLport-5.0.1.tar.gz 파일을 받아 압축을 풀자
본인은 추가 라이브러리들의 관리를 편하게 하기 위하여
D:\Library\ 경로에 모든 라이브러리들을 모아 놓는다.
이는 개발 플랫폼이 변동이 없는 한
재 컴파일 없이 저장된 라이브러리를 컴파일러에 등록하기만 하면 된다는 장점이 있다.

압축이 해제되면 STLPort 폴더가 생성된다.
후에 Boost 라이브러리의 설치를 위해서는
이 폴더의 이름을 STLPort-5.0.1로 변경하는 것이 좋다.

< before compile >

STLport의 iostream을 사용하고자 한다면,
반드시 컴파일을 해주어야 한다.
그렇지 않다면 컴파일 과정은 생략해도 된다.

먼저 Platform SDK를 사용한다면,
설정해 주어야 할 옵션이 있다.
압축을 해제한 D:\Library\STLport-5.0.1\stlport\ 폴더에 보면,
stl_user_config.h 라는 파일이 있다.
이 파일을 열어보면,

#define _STLP_NEW_PLATFORM_SDK 1

에 주석처리가 된 것을 볼 수 있다.
이 주석처리를 해제하여 활성화 시킨다.

또한 다음의 선언문의 주석도 해제하자.

#define _STLP_VERBOSE_AUTO_LINK 1

이 선언은 컴파일 결과 자체에는 영향이 없지만
컴파일 중 현재 링크되고 있는 라이브러리를 명령 창에 표시 하겠음을 나타낸다.
따라서 프로그램이 STLPort 라이브러리를 연결하고 있는지
컴파일 중 확인할 수 있다.


< compile >

컴파일을 위해서는 반드시 콘솔에서 작업해야 한다.
그러므로 아래의 설명은
전부 콘솔에서 이루어 진다는 것을 명심하자.

먼저 콘솔 창을 연다.
모르겠으면 'Windows Key' + R 하면 나타나는 창에 cmd 라고 적는다.

만약 VC++.NET 2003을 깔았다면
아래와 같은 패스가 있을 것이다.

C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin

위 폴더에 vcvars32.bat 파일이 있다.
이 파일을 콘솔에서 실행시킨다.
그러면 환경이 준비 됐다는 의미 비슷한 말이 나온다.
(영어라 장담 못하겠다. -_-a)

이제 STLport의 압축을 해제한 폴더로 돌아간다.
본인은 D:\Library\STLport-5.0.1 이다.

이제 D:\Library\STLport-5.0.1\build\lib 로 이동하자.
여기에 보면 확장자가 *.mak 인 확장자가 무수히 많은데,
이 파일들이 가리키는 컴파일러를
STLport가 몽땅 지원한다는 얘기가 되겠다.
잠시 놀라움에 한 번 감탄해주고 넘어가자.

본인은 VC++.NET 2003을 쓰므로
버전으로는 VC++ 7.1에 해당한다.
그러므로 nmake-vc71.mak 파일을 사용하겠다.

nmake -f nmake-vc71.mak install


위 명령을 치자.
컴파일 끝날 때까지 기다리도록 하자.



< after compile >

컴파일이 다 끝나면,
VC++.NET 2003에서 경로 지정을 해줘야 한다.
VC++.NET 2003을 열고 도구에 가서 옵션을 선택하면 창이 열린다.
그럼 좌측 목록에 Projects 를 선택하고
하위의 VC++ 폴더를 선택한다.
우측 창의 우측 상단 콤보박스에서 포함 파일을 선택한 후
리스트에 D:\Library\STLport-5.0.1\stlport 를 추가로 적어
리스트 맨 위에 놓는다.

< finale >

이제 마음놓고 사용하시라~!!
(@,.@)>