STL, 이것이 문제로다.
안녕하세요. 처음으로 글을 올리게 되네요. kldp 산하(?)라서 리눅서 등이 많은 곳에서 윈도우 프로그래밍에 관한 질문 혹은 의견을 수렴하는 것이 조금 어색하기도 하네요. 저는 윈도우 플랫폼(2000+)과 Pocket PC (WinCE 3.0+)에서 프로그램을 개발하고 있는 병특생(-_-)입니다.
제목에서와 같이 제가 질문드리고 싶은 것은 여러분들은 string과 같은 클래스부터해서 여러 자료구조 list, vector 등의 클래스들을 어떻게 조달(?)해서 쓰는지 알고 싶은 겁니다.
Unix기반이나 플랫폼 독립을 꾀한다면 STL이 정답일 것 같습니다. 그러나 솔직히 MFC의 CString이나 collection library에 비해 코드의 가독성이 많이 떨어지고 (물론 STL에 익숙하지 않기 때문이겠지만) 여러 편리한 연산자 오버로딩도 제대로 되지 않아 많은 어려움을 겪었습니다.
지금까진 간편한 대로 CString, CArray, CMap 등의 클래스들을 통해 string 및 자료구조 클래스들을 써 왔습니다. 그런데, non-MFC 기반으로 프로그램을 짜야 하고 혹은 embedded에도 쓸 수 있는 모듈을 만들어야 할 상황에 직면했습니다.
지금 제가 가장 고민하는 부분은 string 및 자료구조 클래스들을 어떻게 처리할 것인가 이거입니다. 이번에 Visual Studio .NET버전이 나오면서 MFC와 ATL의 버전이 7로 업그레이드 되었습니다. 그중에서 눈에 띄는 것은 지금까찌 CString을 쓰려면 무거운 MFC를 필요로 했는데, CAtlString이라는 클래스로 간편하게 스트링을 오버헤드 없이 쓸 수 있게 되었다는 점. 또한, 역시 MFC를 이용해서 쓸 수 밖에 없었던 여러 collection library (CArray, CList, CMap 등)를 대신하여 ATL에서도 쓸 수 있는 CAtlArray, CAtlList 등이 추가되었습니다.
ATL collection library를 살펴보니 가독성이 무척 높으면서도 STL의 less, greater와 같이 trait도 자유롭게 지정해줄 수도 있는 등 상당히 매력적으로 보였습니다. 만약, 제가 유닉스 혹은 리눅서라면 주저없이 STL을 선택하였겠지만, 거의 모든 작업을 윈도우 위에서 VC++로 작업하는 터라 선뜻 STL을 쓰기가 쉽지가 않습니다.
그렇다고 해서 MFC-ATL 7에 포함된 CAtl* 클래스들을 쓰자고 하니 아직까지 많이 쓰는 VC++ 6.0에는 쓰기가 힘들다는 점입니다.
얘기가 길어졌네요. 여러분들은 어떻게 스트링 및 리스트, 해쉬테이블 클래스들을 가져와서 사용합니까? 많은 조언 부탁드립니다.
댓글
STL이라는 제목에 눈을 번뜩이지 않을수가 없군요.아마도 UNIX에서
STL이라는 제목에 눈을 번뜩이지 않을수가 없군요.
아마도 UNIX에서 개발을 하시는 분들이라면, 그동안 대부분 C로 코딩을 하셨을겁니다.
저두 얼마전까지는 C로 했지요... 수많은 포인터를 다루는 작업이었습니다. 말두 마세요.
이중포인터의 멤버에 다시 포인터가 달라붙고, 어디에서 해제되는지 따라갈려문 날새더군요. 몸버립니다.
그러나, 이제는 그런일들이 현저히 줄고 있습니다. 지금의 거의 모든 자료처리는
STL의 컨테이너클래스에게 맏깁니다... 이러다 보니 프로그램이 좀더 객체지향적으로 변하더군요.
예전에 C나 STL을 이용하지 않았던 C++코드의 번잡함이 많이 사라졌습니다. 몸 좋아졌습니다. :)
STL을 사용하다보면, 그 설계철학에 놀라지 않을 수 없습니다. 효과적인 처리를 위한
배려가 감동입니다. 만약 그동안 C++에 질리셨던 분들이나, STL을 전혀 접해보지
못하신분들이라면, 꼬~~옥 STL을 이용하시라고 권하고 싶습니다.
이상은 UNIX계열에 대한이야기입니다... WIN에서는 굳이 UNIX로 포팅하실 계획이 없으시다면
STL보다는 MFC,ATL계열의 클래스를 사용하시라고 권해드립니다.
M$가 누군가요? 당연히, 표준보다는 자기네 클래스에 심열을 기울였을게 뻔하지 않을까요 :)
매우매우 동감합니다.^^;
매우매우 동감합니다.^^;
역시 여기는 반 MS 프로그래머들이 많으시군요 ^^갠적으론 MS의 프
역시 여기는 반 MS 프로그래머들이 많으시군요 ^^
갠적으론 MS의 프로그래머에 대한 배려는 대단하다고 봅니다만..
뭐 그게 또 자기네들 툴 아니면 모쓰게한다고도 볼 수 있지만,
적어도 productivity 측면에선 MS가 많이 앞서지 않을까요?
템플릿 조차 제대로 지원못하는 것은 분명한 suck입니다.
템플릿 조차 제대로 지원못하는 것은 분명한 suck입니다.
단순히 반MS인걸로 치부해버리면 곤란합니다...http://www.k
단순히 반MS인걸로 치부해버리면 곤란합니다...
http://www.kr.freebsd.org/~cjh/freetime/oss/halloween/
그넘들은 실제로 '표준을 왜곡하는 짓'을 정책적으로 추친하고 있으니까요.
그것이 소비자를 위한다기보다는, 순전히 자기들의 시장지배력을 강화하기 위해서...
> M$가 누군가요? 당연히, 표준보다는 자기네 클래스에 심열을 기울였을
> M$가 누군가요? 당연히, 표준보다는 자기네 클래스에 심열을 기울였을게 뻔하지 않을까요 :)
바로 정답입니다!! 놀라운 통찰력이십니다-_-;
GCC에서의 STL이 멀티쓰레드 환경에서 safe 하지 않다고알고 있
GCC에서의 STL이 멀티쓰레드 환경에서 safe 하지 않다고
알고 있습니다. 이거 어떻게 해결할 방법 없나요?
Bookworm
gcc에서의 stl이라하면 SGI STL로 알고 있는데요.. 이거 MT
gcc에서의 stl이라하면 SGI STL로 알고 있는데요.. 이거 MT safe 한걸로 알고 있는데요.
_REENTRANT였던가, 플래그를 주면 MT safe한 allocator를 사용하는 것으로 알고 있습니다.
제가 잘못 안 거라면 누군가 고쳐주세요..
에구에구, 실수로 글을 날렸어요. T_T 진호입니다. STL 꼭
에구에구, 실수로 글을 날렸어요. T_T
진호입니다. STL 꼭 쓰십시오. 왜?
만약에 10의 시간을 투자해서 가독성이 뛰어나고 버그잡기
쉬운 코드를 만드시렵니까 아니면 성능은 뛰어난데 도저히
읽기 어려운 코드입니까?(어셈이 대표적이지요?)
저는 실제 후자를 원하던 사람이었습니다. 그러나 후자는
머신의 성능을 향상시키는데 따라잡히기 쉽습니다. 이것은
이미 전산학에서 오랬동안 증명된 결과입니다.
STL은 전자를 가능하게 합니다. 원래 STL이 시작된 것은
일반화된 알고리즘을 다양화된 자료구조에 사용할 수 있게
하자는 것에서 출발했습니다. 물론 작업하는 Platformd의
STL이 엉뚱하게 구현이 되어있으면 문제가 됩니다. 그러나
이것은 손쉽게 머신의 성능향상으로 가능하다고 생각합니다.
알고리즘을 효과적으로 만드는 것은 중요합니다. 그러나
진정 내가 컴퓨터를 이용해서 뭔가 일을 하려고 라는데
효과적인 알고리즘만 만드는데 목숨걸 수 있나요?
만약에 효과적인 Optimization을 통해 모델의 파라메터를
찾으려고 한다면, 저는 과감히 Numerical recipies in C나
MATLAB으로 값을 얻습니다. 왜 효과적으로 C프로그래밍을
해서 Optimization을 짜지 않나고요? 한달안에 논문 써야
되는데 언제 이거 짜고 있겠습니까? 있는 코드 이용해야죠.
^_^
================================================진호 씀
가독성면은 주관적인 면이 있다고 생각되는군요. 저 같은 경우는 CStri
가독성면은 주관적인 면이 있다고 생각되는군요. 저 같은 경우는 CString 보다는 STL Container인 string이 더 가독성이 있게 느껴졌습니다.
그리고, STL이 컨테이너만이 있는 것이 아니지요. STL의 진정한 힘은 알고리즘과의 결합이 아니었던가요?
아참... 가독성면에 하나 더...
operator overloading 보다는 이름이 있는 메소드 형태가 더 가독성이 좋지 않나요? 최근 자바를 많이 써서 그런지는 모르겠지만, operator는 어떤 경우에 혼동을 주기도 합니다. (물론 모든 경우는 아니지만요;;)
적고 보니 저도 상당히 주관적인 내용을 적은것 같군요.
--
Seo, Hee-Seung.
http://anitype.net/anitype/
http://anitype.net/hirenn/
--
http://renn.sapzilla.org/
만약 윈도우 플랫폼에서 dll를 만든다고 하면 STL을 못쓰는 치명적인
만약 윈도우 플랫폼에서 dll를 만든다고 하면 STL을 못쓰는 치명적인 문제점(?)을 발견한적이 있었습니다.
예를 들어 어떤 dll의 클래스 A를 export합니다.
그리고 그 클래스 안에 멤버 변수로 string m_strName;
를 선언합니다.
dll을 불러다 쓰는 곳에서 클래스 A를 만들고
A a;
a.m_strName = "AAAAAABBBBBBBCCCCCCDDDDDD";
이렇게 스트링을 만들어지게 하면 클래스 A가 나중에 소멸되면서 뻗어버리는 문제점이 발생합니다.
왜 그런지 조사를 해보니깐 m_strName의 클래스에 스트링을 대입하는 곳은 호출자 쪽인데, 소멸자가 불려서 string 내부 버퍼를 delete해 주는 곳은 dll안이기 때문에 런타임 에러가 나더군요.
.NET에 추가된 CAtlString이나 MFC의 예전 CString은 dll사이에서 안전한 것 같았습니다.
마찬가지로 dll에서 익스포트된 list나 다른 자료구조도 이런 문제점이 있을지도 모르겠네요.
혹시 이런 문제점을 해결할 수는 없는지요?
new, delete가 implicit하게 다른 주소공간에서 일어나서 벌어지는 문제점인 듯 합니다.
그런데 CString은 왜 끄떡없을까요? -_-
저도 비슷한 문제를 많이 겪어 본적이 있습니다만, 모두 STL 자체의 문
저도 비슷한 문제를 많이 겪어 본적이 있습니다만, 모두 STL 자체의 문제가 아닌 컴파일러나 해당 STL implementation의 버그였습니다.
VC++의 예를 들어보자면
dll과 exe 또는 dll 사이에서 map을 주고 받게 되면 메모리 문제로 프로그램이 중단되는 문제 (이 경우는 run-time library를 맞추더라도 해결이 되지 않습니다) -> VC++에 포함된 dinkumware STL implementation의 버그
return type이 void인 member function을 mem_fun의 argument로 사용할 경우 컴파일 에러가 나는 문제
template function의 function declaration 부분에 template argument가 사용되지 않으면 type에 맞지 않는 엉뚱한 function이 호출되는 문제
특정 상황에서 namespace 안에 정의된 class의 static member를 호출할 경우 static member가 아닌 것으로 생각하여 컴파일 에러가 나는 문제
등등 -> VC++의 template에 관련된 버그
아예 C++ standard의 몇몇 section들을 지원조차 하지 않는 문제 (partial template specialization이 가장 대표적인 예입니다.)
C++이라는 언어에 상당한 매력을 느끼고 있는 저로서는
기존제품들에서 당연히 지원해야 할 표준들 조차 제대로 구현하지 못했고, 그렇다고 사후 service pack 등을 통해서 제대로 지원도하지 못한 상황에서
C#이라는 새로운 언어를 만들어서 홍보하고 다니는 MS의 모습을 볼때마다 아쉬움을 많이 느끼고 있습니다.
그리고 MFC에 있는 C++ 표준에 대해 이질적인 요소들 (string <-> CString, stream <-> CArchive, 기타 쓸다리 없는 매크로들)도 정말 맘에 안들구요.
EXE와 DLL 사이에 run-time library 가 다르면 그런 문
EXE와 DLL 사이에 run-time library 가 다르면 그런 문제가 발생할 수 있습니다(제가 이것 때문에 3일을 고생한 적이 있습니다. -_-).
VC++ 에서 run-time library가
1. Single-Threaded
2. Multithreaded
3. Multithreaded DLL
3가지가 있는데(물론 각각 Debug 는 따로 존재합니다)
3번의 경우 MSVCRT.dll 을 사용하게 되고, 나머지 경우는 library가 static link 되어 버립니다.
감사합니다.. Multithreaded DLL로 하니 말짱하군요!! 이런
감사합니다.. Multithreaded DLL로 하니 말짱하군요!! 이런맙소사 ㅠㅠ..
ps. CString은 new, delete를 안쓰고 바로 Head* API를 쓴것같더군요.
ps2. 윈도우 프로그래머에게도 좋은 공간인 듯 하네요. 긱포럼만세!!
STL은 모든 플랫폼상의 C++ 에서 소스코드 수정없이 사용할수 있게
STL은 모든 플랫폼상의 C++ 에서 소스코드 수정없이 사용할
수 있게 해줍니다.
그러나 이런 portability가 있는 모든 라이브러리가 그렇듯이 같은 소스 코드로 플랫폼 마다 기대했던 performance가 똑같이 나오게 하기는 힘듭니다.
그러나 STL은 C++의 template의 힘을 빌어 쓰는 사람마다
customize를 할수 있게 해놓았습니다. 즉 쓰는 사람에 따라서 high-level의 알고리즘의 변화 없이 손 쉽게 customize하여 performance를 극대화 시킬수 있습니다.
(여기에 쓰이는 기능중에는 template의 (partial)specialization 등이 쓰일것입니다.)
여담으로 C++ community에서도 C++을 VM위에서 수행하기
노력이 있어왔고 진행 중인 것으로 앞니다.
가장 가시적인 현상으로는 .NET의 C++버전에 Herb Sutter,
Stan Lippman 등이 참여 하였다니 기대 해도 좋을것 같습니다.(관련 URL http://www.codeproject.com/interview/herbsutter3032002.asp)
아 그리고 각종 compiler마다 지원하는 STL의 비 호환성을 극복하시려면 다음 사이트의 STL library를 사용하시는게 좋을 겁니다.
http://stlport.org
저도 STLport 사용을 적극 추천합니다!저는 Borland C
저도 STLport 사용을 적극 추천합니다!
저는 Borland C++Builder 사용자인데요,
확실히 전에 쓰던 RougeWave 구현보다 훨씬 낫군요.
ANSI C++ 표준은 아니지만,
해쉬테이블(hash_set, hash_map)이나 rope등을 써보니 정말 빠르더군요.
STLport만의 디버그 모드도 편리하고요.
BCB 5.0버전에서도 간단히 설치되고요.
최근 나온 BCB 6.0버전에서는 아예 디폴트 STL 라이브러리가
STLport로 바뀌어 있더군요.
정말 편리하다는...
어떤 플랫폼에 지나치게 의존하는 것은좋지 않다고 봅니다.저는 MF
어떤 플랫폼에 지나치게 의존하는 것은
좋지 않다고 봅니다.
저는 MFC를 4년 정도 사용했었습니다.
하지만 다른 플랫폼으로 소스를 이식해야 될 경우가 생겼었습니다.
하지만 포기하고 대부분을 새로 작성하였습니다.
정말 기가 막힐 노릇이었습니다.
제가 아는 오픈 소스의 경우를 보니까
거의 대부분이 플랫폼 독립적 성향이 강하더군요.
머 반 M$진영이라고 그냥 생각하기에는 무리가 있는듯 합니다.
윈도상에서만 계속 머무시는 경우가 아니라면
MFC를 배제한 코딩 습관도 좋을듯 합니다만....
결정은 개인의 취향이나 성향에 따른 개인의 몫이라고 봅니다.
팀 차원의 개발이라면 운신의 폭이 더 좁을수도 있겠군요. ^^
아래에서 말씀드린 Kernighan씨가 지은 The practiceo
아래에서 말씀드린 Kernighan씨가 지은 The practice
of programming에 나와있는 Markov알고리즘을
C, C++/STL, JAVA, Awk, Perl로 구현했을때의 성능
비교표입니다.
250Mhz 400Mhz Lines of
MIPS R10000 Pentium II source code
-----+-----------+------------+-------------
C | 0.36 sec | 0.30 sec | 150
-----+-----------+------------+-------------
C++/ | | |
STL/ | 2.6 | 11.2 | 70
deque| | |
-----+-----------+------------+-------------
C++/ | | |
STL/ | 1.7 | 1.5 | 70
list | | |
-----+-----------+------------+-------------
JAVA | 4.9 | 9.2 | 105
-----+-----------+------------+-------------
AWK | 2.2 | 2.1 | 20
-----+-----------+------------+-------------
Perl | 1.8 | 1.0 | 18
-----+-----------+------------+-------------
STL/deque 버젼은 STL/list 버젼에 비해 내부 구현
방식에 있어 성능이 떨어지는 버젼이라는군요
조금 이견을 붙이자면...STL Container의 경우 제작사마다
조금 이견을 붙이자면...
STL Container의 경우 제작사마다 알고리즘이나 구조 기타 등등에서 차이가 있다는 것이 변수가 될 수 있다는 점입니다. STL과 관련된 책을 조금 보면 어떻게 만들어져있냐에 따라 성능이 획기적으로 바뀔 수 있다는 점이 기억나더군요.
물론 해당 알고리즘에 따라 달라지겠지만, deque와 list는 다른 구조이고 다른 용도이며 이에 따라 성능도 틀립니다. 이 것 하나만으로 비교하는것은 무리라는 이야기지요.
그나저나 Perl이 이렇게 뛰어날 속도를 낼 수 있었다는 것입니다. 과연 대단한 언어군요. :)
--
Seo, Hee-Seung.
http://anitype.net/anitype/
http://anitype.net/hirenn/
--
http://renn.sapzilla.org/
펄이 소스코드의 길이에 비해 가히 놀라운 퍼포먼스를 보이네요.단순한
펄이 소스코드의 길이에 비해 가히 놀라운 퍼포먼스를 보이네요.
단순한 스크립트 언어로 봤는데 그게 아니었던 모양입니다;;;
The practice of programming은 1999년에 출간되었
The practice of programming은 1999년에 출간되었습니다.
위에 있는 실험은 윈도에서 했다고 했으니까
아마 M$ VC++로 실험했겠지요.
M$ VC++에 있는 STL은 Dinkumware사에서 개발했던 건데요.
M$의 사정상(라이센스관련 법적 소송인 걸로 압니다.)
STL은 VC++ 4이후로 업그레이드가 되지 않았습니다.
즉, M$ VC++의 STL은 95년판의 구닥다리죠.
ANSI/ISO C++ Standard가 나온게 1997년이니까
C++ 표준도 지키지 못하는 저급한 버전입니다.
성능이 떨어지는 것도 당연하죠.
PS. VC++.NET에서는 Dinkumware의 새버전이 들어갔다고 하더군요.
근데 awk는 뭔가요?무지 빠르네요?
근데 awk는 뭔가요?
무지 빠르네요?
awk란 Line기반 텍스트 처리 언어 입니다.리눅스에도 GNU aw
awk란 Line기반 텍스트 처리 언어 입니다.
리눅스에도 GNU awk인 gawk가 있지요
http://cm.bell-labs.com/cm/cs/awkbook/
헉, 느린거 였네요.암튼 궁금하네요
헉, 느린거 였네요.
암튼 궁금하네요
저는 MFC Class 를 UI 를 만들때 외에는 안씁니다.대신 필요
저는 MFC Class 를 UI 를 만들때 외에는 안씁니다.
대신 필요한 Class 는 유사 Library 를 자체 구축하는데요.
필요 MFC Class 의 소스를 찾아가서 복사해서 대충 고치는거죠
요는 내 입맛에 맞추는거죠.
DOS 쓸때는 하나하나 만들어 쓰는게 당연한거였는데, 어느새 MFC, 또는 Control 이 지원하지 않으면 플밍을 못한다는 생각이 내 머리를 점유한다는게 나두 무쟈게 싫어여
그런가요? 학부시절 프로그래밍 숙제시간에같은 알고리즘을 java, c
그런가요? 학부시절 프로그래밍 숙제시간에
같은 알고리즘을 java, c++로 해서 돌려보면
c++이 몇배이상 빨랐었는데...
STL이 들어가서 그렇게 느려진다는 소리인지요?
ATL, MFC는 STL보다 더 느리죠.게다가. VC++에 포함된 S
ATL, MFC는 STL보다 더 느리죠.
게다가. VC++에 포함된 STL은 98년도껍니다. 표준과 다른 점이 여러 군데 있으니 조심하셔야죠.
저같은 경운 개발 속도와 퍼포먼스 둘 다를 위해서 VC++에 STL port를 설치해서 썼습니다.
STL이 개념상으로 깔끔하고 좋다(?)고 하지만 실제 유명한오픈소스
STL이 개념상으로 깔끔하고 좋다(?)고 하지만 실제 유명한
오픈소스 프로젝트나 여타 프로젝트에 적극적으로 쓰인예는
거의 보지 못한것 같네요.
UNIX계통 프로그래머들은 C++에 대해 그다지 우호적인것
같지도 않고 ...
C언어 개발자인Kernighan씨가 지은 The practice of
programming이란 책을 보면 markov알고리즘이란걸 여러
가지 언어로 구현해놓은것에 대한 벤치마크 결과가 있는데
C++/STL 을 썼을경우 Perl보다 속도가 더 떨어지는것
으로 나와있더군요 순수 C는 perl속도의 5배정도 되고
STL이란 말을 듣고 생각나서 잡담 해봤습니다.
제가 본 각종 자료들도 ..C++를 이제 Java보다도 퍼포먼스가
제가 본 각종 자료들도 ..
C++를 이제 Java보다도 퍼포먼스가 떨어진다고 보더군요 ..
C > Java > C++ 라고 적힌 걸 보고 처음에 참 놀랬죠 .. --;
저도 도저히 믿기 어려웠는데, MEC++책을 보고,C++차원에서의 완
저도 도저히 믿기 어려웠는데, MEC++책을 보고,
C++차원에서의 완벽한 메모리 관리의 공통 표준 사향을 만들기는 불가능하다고 느끼고,
Java의 퍼포먼스 향상을 최신 VM들이 행하는 최적화들을 보고 이제 납득이 가네요.
이제 Java에게 남은건 더 빠른 HCI-GUI 환경일것 같은데요.
.Net에서 구현되는 GUI가 얼마나 빠른 반응일지 궁금합니다.
1.5의 generic Java와 OS와 동시에 시작되는 VM들.. 정말 기대되네요.
.........
.........
글쎄요.. 솔직히 놀랍군요..c++ 클래스 설계가 잘못되었을경우 정말 말
글쎄요.. 솔직히 놀랍군요..c++ 클래스 설계가 잘못되었을경우 정말 말아먹긴하죠..
c++을 사용할때 아주 잘 설계하였을 경우 c의 90%의 성능을 낼수 있단말은 있읍니다만..
요새 자바가 많이 발전하였나 보군요..
C++은 compile-time에 최적화가 끝나는데 반해 ..Java
C++은 compile-time에 최적화가 끝나는데 반해 ..
Java의 경우는 run-time에도 최적화를 하게 되는데 ..
이게 꽤나 유연해서 퍼포먼스 향상이 크다네요 ..
물론 소규모의 프로그램같은 경우에는 ..
C++가 빠르다고 하고요 ..
( 사실 제가 코딩해선 C++이 늘 빠른 느낌이던데 --;.. )
제가 제대로 아는 건진 잘 모르겠습니다만 .. --;
에에..STL 이 뭐지요?ATL 은 또 무었인지....ㅡ,.ㅡ ;
에에..STL 이 뭐지요?
ATL 은 또 무었인지....ㅡ,.ㅡ ;
무슨 약자인지?...흠...무식하다고 구박하지 마시고 알려주세요. ^^;
STL은 Standard Template Libray입니다.ATL은
STL은 Standard Template Libray입니다.
ATL은 Microsoft에서 만든 Active Template Library입니다.
ATL은 MFC에 비해 가볍고 구조가 깔끔하여 컴포넌트 제작에 많이 쓰입니다.
댓글 달기