STL(Standard Template Library)의 궁금한점...

책은 다른 분들이 소개 많이 해 주실테고
실제 쓰느냐...

사실 전 쌩초보라서 제대로 알지도 못하고
회사의 고수분이 쓰신 코드를 보면서 공부했슴다.
그 분도 STL 을 제대로 공부하고 쓰신건 아니고
어디서 슬쩍 보신걸 사용하신 것이었는데...

첨 봤을 때 정말 충격적이었습니다.
뭔가 족쇄를 차고 있다가 그걸 풀어버린 기분이랄까?

다른 건 몰라도
map 은 정말 유용하게 쓸 수 있을것 같습니다.
Associative array 라는 개념으로 사용할 수 있는데
임의의 값( 아무 숫자나 string, class 까지 가능 )을
index 로 사용하여 배열처럼 쓸 수 있을 뿐만 아니라
iteration, insertion, deletion 등도 아주 간단하게 이루어집니다.
아주 편리하게 쓸모가 많지요. 흐흐

STL을 조금씩 써 보시면 알겠지만 편리하기 때문에
실제 프로젝트에서도 많이 사용합니다.

저같은 경우는 unix 와 windows 에서 동시에 실행되는 데몬들을 주로 제작하는데 STL만큼 좋은 대안이 없었습니다...
저는 주로stlport 것을 씁니다.
http://www.stlport.org

개인적일 수도 있고 뻔~한 얘기 일 수 있지만, 성능에 영향을 미치는 P/G라면

절대 STL을 쓸 수 없습니다. 또한 한정된 메모리를 갖고 코딩을 해야 하는

상황이라면 더더욱이겠죠.

예전 프로그래밍 게시판을 보시면 포인터와 STL 속도 구현한 소스가 있을

껍니다. 함 보시길...

실제 회사에서도 많이 쓰더군요. 학교 다닐 땐 말로만 들었지, 회사 들어와서

첨 써봤습니다. ㅡ,.ㅡ; 윗분 말씀대로 정말 충격이였죠. 후후후

일일히 linked-list 구현할려고 겔겔 거리느니, 정말 한줄이면 되는 STL을

쓰죠. 다만, 위에서도 말했듯이 속도에선 좀 그런거 같더군요.

이부분에 대해선 여러 의견들이 있는것 같습니다. ㅡ,.ㅡ;

제가 STL을 직접 써보진 못해습니다만, STL 컴파일 타임에 적용되는것 같은데 실행시간에 나쁜 영향을 준다는 것은 언뜻 이해가 안됩니다. 속도가 어느정도 느려지길래... 경험해보신분들의 의견을...

글쎄요, STL은 수년간에 걸쳐 많은 고수들의 손길을 거쳐서 만들어진 라이브러리입니다. STL의 각 컨테이너와 알고리듬의 특징을 완전하게 이해하고 제대로 사용한다면 평범한 프로그래머가 고생해서 만든 코드보다 훨씬 세련되고 효율적인 코드가 만들어집니다.
물론 STL은 일반적인(generic) 상황에 모두 적용되도록 만들어진 것이므로, 특수한 상황에서는 느릴 수 있습니다. 템플릿 라이브러리는 유사한 코드를 여러번 찍어내는(inlining) 역할을 하므로, 코드가 중복되어 프로그램 크기가 지나치게 커져버리는 코드 비대화(code bloat) 문제가 발생합니다. 즉, STL은 크기 최적화는 거의 무시하고, 속도 최적화에만 신경쓰는 특징을 가지고 있습니다.
프로그램 크기가 지나치게 커지면, 최초 로딩시간이 느려지고 캐쉬의 적중률(hit ratio)이 낮아지므로 속도가 오히려 낮아질 수 있죠.
이러한 문제점은 함수 객체 대신 함수 포인터를 사용하여 인라이닝(inlining)을 피하는 방법(속도 최적화와는 반대로)으로 어느 정도 해결할 수 있습니다.
임베디드 환경과 같이 메모리가 한정된 환경에서는 컴파일러가 ANSI C++을 지원한다 하더라도 STL을 사용하지 않는 것이 일반적입니다.

그리고 문자열 타입인 std::string은 원래 STL이 아니었다가 C++ 표준 제정 과정에서 STL에 포함된 것입니다. 견고성(robustness)보다 효율성(effectiveness)만을 추구하는 다른 STL 컨테이너와는 달리, 견고성을 보장하는 특징이 있기 때문에, 견고성을 거의 고려하지 않는 ANSI C의 문자열 처리 함수보다 느립니다.
고속의 문자열 처리를 위해서는 C 방식으로 char 포인터를 직접 다루시던가, 아예 인라인 어셈블리를 사용하실 것을 권합니다.

STL 을 사용하지 않으면, 제가 하는 프로젝트는 아마 1/3 쯤 더 연장되었을 것입니다.

수시로 바뀌는 정책 포맷들을 처리하기위해, 핸들링 하는 구조를 이미 정형화된 STL을 사용하지 않았다면, 아마 처음 구현한 뒤로 구조를 바꾸지 않으려고
필사적으로 노력하거나, 아마 괴물이 나왔을 것입니다.

하지만, vector로 했다가 set으로 했다가, vector 두개를 썼다가 map을 썼다가 하는 일들은 생각의 자유도를 한층 높여주지요.

제 생각에 STL 책 중에 가장 좋은 책은 C++ Standard Library 입니다.
조슈티스가 쓴 겁니다. 번역서도 나왔으니 한번 보시면 될 겁니다.
아 번역은 걱정 안하셔도 될 겁니다. 꽤나 잘 번역했습니다. ^^

바이너리 사이즈에 민감한 프로그램의 경우라면 절대로 STL은 쓰지 마세요!

개인적인 경우지만 어느정도의 성능이 필요한 or portablility 가 중요한 서버나 엔진류는 STL을 사용하지 않습니다. 사실은 C++도 거의 사용하지 않는 편이지요. 덕분에 회사에서 쓰는 엔진을 작업하면서 STL과 최대한 비슷해지도록 C로 기본 자료구조들을 만들어놓느라고 한동안 애썼던 적이 있습니다.

단 UI의 성격이 강한 프로그램들 - 속도에 신경을 덜 써도 상관없고, 바이너리가 좀 커도 관계없는 녀석들이라면 STL을 쓰면 굉장히 편리하지요. 웬만한 프로그램을 만들다보면 기본 자료구조를 만드느라고 드는 시간이 꽤 많은데, 이런 문제를 단번에 해결해 줄수 있는 좋은 방법이 되잖아요.
오래전 이야기지만 foreach() 를 처음 알게 되었을때의 충격은 아직도 잊을 수가 없습니다.

다 좋습니다만..주의해야 할 것은 크기도 크기지만 STL 도 사람이 만든 이상 반드시 버그가 있기 마련입니다. 이것을 주의하라는 겁니다. 제가 아는 분도 STL 버그 떄문에(좀 예전이긴 했습니다만.) 프로젝트까지 망친 일이 있었다고 하니 약간의 경계를 해야할 필요는 있을 것 같습니다.( STL 버그인 줄도 모르고 있다가...끝나고 나서 알았다는 군요)

snaiper 이기탁님이신가요? ^^;

맞다면??? 반갑습니다 ㅎㅎ

사실 STL에서 버그났다 치더라도 디버깅으로 추적하면 다 들어나지 않는지요?

어째튼 자기가 STL 같은 자료구조를 세워놓은 것보다

벤더들이 많들어 놓은 STL이 더 믿을 만하고 버그가 없다고 생각되는건

사실입듯 보입니다 , 얼마전 gcc에서 new로 동적 메모리 할당하는데

컴파일러에서 최적화?에러가 난듯 보이는게 얼마전에 발생했었습니다만은

이런식으로~~~~.........

STL를 못믿는다면 -_-; 윈도우 운영체제나 리눅스 유닉스 운영체제에서 제공해주는 API 환경도 역시 믿을만한게 되지 못하는가 싶습니다 --;

일단 믿고 쓰고 최악인 상황일때는 한번 , 의심은 해봐야겠죠 ....

그래도
자기가 만든 클래스나 라이브러리보단 안전할거라고는 봅니다
--;
[각 OS에 맞는 컴파일러벤더가 각각의 OS에 맞겠끔 최적화및 안정성 테스트를
다했을테니까요, 이들 보다 프로가 아닌 이상,혹은 시간이 남아돌지 않는 이상
STL은 절대 선입니다 ㅎㅎ]

옙... 이건 절대적인 진실입니다. :D
제가 STL을 꺼리게 된 가장 큰 이유가 VC++ 이라는 녀석이지요. 요놈이 쓰는 STL이야 원체 다들 꺼리기로 유명하니 어쩔 수 없지요. VC++에서 컴파일한 바이너리가 10메가가 된 것을 보고 한번 기겁했던 적이 있습니다. :shock:
덕분에 크로스 컴파일이 되는 코드를 만들어야 하는 입장에서는 현실적으로 STL을 도입하는 것이 <불가능>하다는 뜻이지요.

하지만 STL은 역시 편리하지요. MFC의 어설픈 리스트따위와 비교나 할 수 있을까요.

M$ VC++에 기본 설치된 STL보다는,
STLport를 설치해서 쓰실 것을 권합니다.
호환성도 이쪽이 더 높고, 표준 STL에서 지원하지 않는 SGI STL 특유의 편리한 기능을 쓸 수 있습니다. 반복자의 디버깅 모드도 디버깅시 상당히 편리하지요.

vector<bool> 에 대한 문제는 유명한 문제이죠.
표준화 위원회의 실패가 표준에서 제거되지 못하고 남아버렸다나요?

STL 의 요구사항을 모두 만족하지 못한다고 합니다.
Effective STL 에서는 vector<bool> 보기를 돌같이 하라 라는 항목이 있죠.
bool 의 배열이 필요하다면 deque<bool> 을 쓰셔야 합니다.

또다른 방법으로는 bitset 이 있는데 이것도 STL 의 요구사항은 만족시키지 않습니다만 그 자체로 유용한 library 로 보입니다. 적어도 vector<bool> 의 문제를 일으키지 않는 것으로 압니다.

이 문제를 빼 놓고는 STL 자체의 문제로 보이는 점은 아직 없는 것으로 압니다.
나머지는 platform 의 문제일 겁니다.

Visual C++ 6 의 STL 은 악명이 높죠. 하지만 .NET 으로 오면서 많이 좋아진 것으로 알며 특히 .NET 2003 에서는 거의 완벽한 것으로 보입니다.

platform 의 호환성을 보실려면 boost 에 http://boost.sourceforge.net/regression-logs/ compiler test summary 를 보시는 것이 좋습니다.
사실 boost 와 platform 과의 호환성을 보기위한 test 입니다만 거의 compiler 의 호환성 test 에 가깝죠. boost 를 제작하는데에는 STL 이 내부에 쓰이는 것으로 압니다.

현재 제가 지금까지 읽은 책은 Accelerated C++, STL Tutorial & Reference Guide, Effective STL이고, C++ 기초플러스 3판(가장 처음에 읽었던 책인데... -_- )은 읽다 말았었습니다.

모두 번역서를 읽었는데 Accelerated C++ 의 번역서는 오자가 많은 편입니다. 그리고 용어대역, 문장번역의 매끄러움에서 맘에 안드는 것도 곧잘 보이고요. 용어가 일관성있게 번역이 안 된 부분도 보이곤 합니다.

곽용재씨가 감수를 봤다고 해서 잔뜩 기대를 했는데 기대에 영 못 미쳤죠...
Accelerated C++ 는 기본입문서인데다 구성방식도 기존의 문법흐름으로 하는 방식과는 다른데 번역이 이래서 정말 맘에 안 들었습니다.
이런 책이야 말로 편역도 필요하는 등 번역이 중요한데 말이죠.
하지만 C++ 책을 이미 한권이상 읽으셔서 C++ programming 익숙하시다면 문제는 없으리라고 봅니다. C++ 는 익혔지만 좀더 C++ 로 하는 programming 이란 것이 무엇인지를 알려주기에 이미 아는 사람도 쓸모가 있거든요.

STL Tutorial & Reference Guide 는 딱딱하다는 평이 많은데 개인적으로는 잘 정리되어 있는 책이라고 생각합니다. Reference 는 후반부에 개제되어 있는데 Tutorial 역시 Reference 식 Tutorial 이라....
저자들이 STL 제작진이라... 그들이 STL 을 잘 알기 때문인지... 그런 식이라... 용어도 좀더 학술적인 용어가 많구요. 전산학을 들었고(혹은 듣고 있고), C++ 기본언어도 아는 사람들에게 적절합니다.

Effective STL 은 어찌보면 당연한 소리를 합니다만 또한 기억해둬야 할 만한 항목이 많습니다. 정말 쓸만한 technic 도 있죠. 특히 vector(string 도 됩니다) 의 swap 을 사용한 memory 할당해제는 잘 배워서 써먹었죠. 입문서는 아니기에 C++ 기본언어, STL 둘다 어느정도 알고 있어야 합니다.

C++ 기초플러스는 2000년에 샀건만 아직도 다 안 읽었습니다. 이것은 제 게으름 외에 핑계댈 것이 없는데 하여간... STL 은 후반부에 조금 다루는 정도입니다. 이번에 출간된 번역 4판은 STL, string 을 좀더 보강했다고 들었습니다.
역시 C++ 입문서이다보니 전면적으로는 다루지 않는 것 같습니다.

cedar 님 감사합니다.

혹시나 했는데 역시나 였군요.

역시 잘 모르는 거 아는 척 하면 안된다니까... -_-..

설명 감사합니다.
proxy 기반 container 는 아직 공부가 미숙해서 모르겠습니다만(이름만 들어봤습니다...) vector<bool> 이 모범적이라고 할 만한 것이었는지는 처음 알았네요..

사실 위의 STL 에 문제가 있을 수 있다는 소리는 STL implementation 을 말하는 것인가 보군요... 그렇다면 충분히 문제가 있을 수 있겠죠.

auto_ptr 은 스마트 포인터와는 별개로 취급해야 한다고 생각합니다. 위말을 그대로 받아들였다가는... (말 자체가 틀렸다는 것이 아니라 오해해서 남용할 소지가 있다는 것)

그리고 vector<bool> 을 프록시의 전형이라고 할만큼 auto_ptr 이 스마트 포인터와 유사한 것인가는 조금... :wink:

하.. 오늘에야 처음으로 글을 쓰는군요..;;

어쨋든.. 저는 게임개발자 이구요. STL에 대해서는 Meyers의 EffectiveC++을
보고 처음 접하게 되었어요. 참 좋더군요. 후훗^^; 여러 컨테이너들을 포함해서
알고리즘에.. 오토포인터에.. 안쓰시는분들도 한번 써보는게 좋을꺼 같더군요.
J모 언어에나 있는 줄 알았던 것들이 C++에 있으니 얼마나 좋던지..

윗글 중에 보니.. 엄청 느리다고 하시는데 혹시 어느 제품을 사용하시는지..
VC++에 기본적으로 깔려있는 STL은 꽤나 문제점이 많구요.(딩컴웨어라는 회
사 껀데 홈페이지에 가면 최신 STL을 받을 수 있다고 합니다.) sgi사의 STL 깔으
시면 만족하면서 사용하실껍니다. 그리고 그렇게 느린 라이브러리를 누가 만드
는지 참 의심스럽군요. 사용방법을 잘 모르시는건 아닌지.. Effective STL 같은
책을 보면 도움이 되실듯.

그럼.

평범한 (기준이나 표준이 없어서 딱히 표현할 단어가...) 스마트 포인터라면 가져야 할 특징이 (인터페이스 말고 행동) auto_ptr 에 없기 때문에 혹시라도 STL 에 진입하시는 분들이 오해하실까봐 말씀드린것입니다.

정확한 문구는 찾아봐야겠는데요... (표준위원회에서 금지한 걸로 기억합니다.)auto_ptr 를 컨테이너에 담지 못하는 문제 때문이라도 둘은 구분해야만 한다고 알고 있습니다.

Effective C++ 에서는 auto_ptr 같은 것을 스마트 포인터 범주에 넣어서 말을 하지만
Effective STL 에서는 auto_ptr 은 스마트 포인터와 거리가 멀다라고 적혀 있는 걸로 기억합니다.

인터페이스 측면에서는 당연히 그렇지만, 사용하는 사람 입장에서는 그 행동에 유의할 필요도 있지 않을까요?

잘못된 것이 있다면 바로 지적해 주세요~~~

좋은 말씀 감사드립니다. ( 이런 이라는 단어를 기억하지 못했네요. :wink: )
boost::scoped_ptr 도 감사드립니다.

자바쪽에서 template을 적용하면 언어가 C++이 되는것 아니냐는 설이 있어서 적용을 망설인다고 들었습니다.

참고로 STL을 만든 Alexander Stepanov의 인터뷰 기사 링크를 올립니다.

http://my.netian.com/~gilbird/stl/intv1.html

http://my.netian.com/~gilbird/stl/intv2.html