|
1. 클래스 객체에 추가된 STL string에다 뭐를 쓰기만 하면 자꾸만 seg fault가 난다. 문제 없이 돌아가던 통계 모듈에서 이상한 점이 발견된다. 클래스 멤버 변수에 있었던 각종 int 형의 통계 값들이 서로 뒤죽박죽이 되고 있었다. 프로그램을 좀 이것 저것 고친터라 그 부분에 문제가 있는 줄 알고 한 참을 들여다 봤다... 그냥 make clean하고 make all하니까 문제 없이 돌아가더라. 역시 리눅스 이 바닥에서도 한번 씩 Rebuild all을 정기적으로 한 번 해줘야 한다. 뭔가 이상하다 싶으면 리빌드 올 하던 습관을 여기서도 가져야할 듯. 2. 미우나 고우나 이클립스를 꽤나 쓰고 있다. 느려터진 속도는 일단 뒤로하고 있으나마나한 인텔리센스와 디버깅 기능은 안습이다. 조금만 프로젝트가 복잡해도 정의 찾는 건 거의 포기해야 한다. 특히 3rd party 소프트웨어를 가져다 쓸 경우엔 완전 좌절이다. 매번 다큐먼트 보고 해당 함수 프로토타입 확인해야한다. STL관련된 소스도 헤매는 건 마찬가지. Full Indexer 모드로 해도 별반 나아지는 것이 없다. VC++ 2003까지는 인텔리센스가 좀 멍청했는데 2005/2008은 아주 잘 돌아간다. 복잡한 네임스페이스, 매크로에 매크로로 복잡하게 치환된 것도 훌륭히 파싱한다. 지금 내 프로젝트도 VC++에 올리면 3rd party 소프트웨어 헤더파일까지 다 잘 파싱한다. 3. 디버거로서의 이클립스는 완전 낙제점이다. 그저 브레이크 포인트가 걸렸을 때 소스코드와 한 눈에 볼 수 있다는 점, call stack 손 쉽게 왔다갔다 할 수 있다는 점 말곤 거의 기능이 없다. 특히 이클립스 CDT 개발자들은 무슨 생각으로 expression 창을 만들었는지 도저히 이해할 수 없다. 변수 값 하나 확인하려면 이건 그냥 이클립스의 콘솔 gdb 창에서 바로 print 하는 것이 더 편하다. 디버깅에서 가장 빈번한 일이 변수 값 확인하는 일인데 이 기본적인 일이 너무나 불편하다. 4. 그렇다고 이클립스가 항상 멍청한 건 아니다. CVS와의 연동은 매우 편안하다. 만약 컨플릭트가 났을 때도 멋지게 인터페이스를 만들어주면 좋았을텐데.. 옵션 창이나 여러 다이얼로그 박스에는 바로 검색창이 있어 몇 단어 치면 바로 해당하는 항목을 찾아갈 수 있다. 코딩 스타일도 나름 설정할 수 있는데 완벽하진 않지만 그럭저럭 쓸만 하다. 이클립스 자체가 완벽한 그래픽 껍데기다 보니 상당히 유여한 구석이 많이 보인다. 대표적으로 툴체인을 간단히 바꿀 수 있다. VC++은 그러한 점에서 많이 아쉬운데, 딱 하나 예외가 있긴 하다. Intel C/C++ 컴파일러는 비주얼 스튜디오 IDE에 잘 붙는다. 그러나 cygwin이나 다른 컴파일러 툴체인은 쓰기가 매우 힘들다. 5. STL을 사실 많이 쓰지 않았다. 그 이유는 단순한데 STL을 써야할 필요성을 별로 느끼지 못했다. ATL-MFC 컬렉션만 해도 상당히 쓰기 편리했고 높은 수준의 커스터마이제이션도 가능했다 (CArray같은 것 말고 CAtlArray 같은 것들). MFC 컬렉션에는 없었던 Red-Black Tree가 ATLMFC에 도입되고 나서 상당히 좋았다. 알고리즘 적용이 좀 거시기 했지만 끽해봐야 소팅 정도였기 때문에 큰 문제 없었다. STL에 이제 꽤 적응이 되었는데 역시 사람들 말대로 STL은 훌륭하다. 그런데 너무 훌륭한 나머지 그 철학을 이해하기가 벅차다. ATLMFC 컬렉션은 소스 코드 까보면 금방금방 이해가 되는데 STL은 이해하기 힘들다. 또, 메소드 이름이 너무 맘에 안든다. 대표적으로 empty()라는 것이 한 마디로 IsEmpty()와 같은 뜻인데, empty에는 비우다라는 동사 뜻도 있다. Bitset에 하나라도 bit이 있는지는 any() 메소드로 체크 가능하다. 뭐 짧고 좋은데 너무 짧다보니 좀 쌩뚱 맞다는 느낌이 많이든다. 아무래도 프로그래밍 시작을 긴 함수 이름과 긴 변수 명이 있는 윈도우쪽에서 하다보니 이질감이 많다. 6. C++을 쓸 때도 난 거의 cout, cerr 같은 걸 잘 안쓴다. 로깅할 때, 화면으로 할지 파일로 할지를 iostream을 쓰면 쉽게 해결이 될 것 같지만 이것도 fprintf를 쓰면 충분하다. 특히 cout에 <<을 주렁주렁 붙여서 쓰는 거 별로 안 좋아한다. 10진수/16진수 바꾸려면 << hex <<, << dec << 를 추가해야하고, 폭을 조절하는 것도 setw 같은 메소드로 되는데 이런 것이 쌓이다보면 길이가 엄청 길어진다. 특히나 긴 << 연결 고리에서 실수로 뭐 하나 빼먹었을 때 나오는 에러 코드는 예술이다. 물론, printf나 sprintf계열 함수들은 버퍼오버플로우에 취약하다. 그러나 대응되는 안전한 함수 군을 쓰고 %s나 %n같은 것에 특별한 주의만 기울이면 충분하다. 암튼 난 <<, >> 연산자 오버로딩은 영 맘에 들 않는다. 꼭 억지로 뭔가 있어보이게 하려고 만든 느낌이 강하다. cout의 경우 컴파일러가 번역한 기계어도 엄청나다. 아래 코드는 <<로 주렁주렁 달린 출력문을 최적화 옵션으로 컴파일한 코드. 도대체 몇 번의 함수 콜이 있는지 가슴이 철렁. os << setw(width) << dec << "0x" << hex << addr << ": " << rtnname << 이걸 대응되는 fprintf로 바꾸면?? 55010133 push eax
최근 등록된 덧글
개발자 입장에서의 수많은 ..
by Jiyoon at 02/04 저도 아들 돌잔치때 돌잡이 .. by 박상욱 at 01/18 미국 대학원 원서 작성중에 p.. by 태클사이야 at 01/13 TO: 박PD 로그인 하지 않아.. by 박응용 at 01/10 http://gigglehd.com/zbx.. by dhunter at 12/28 우와.. 좋네요. 태반이 .. by 윤광배 at 12/17 항상 좋은 글 잘 보고 있습니.. by y2k at 11/23 글이 좋아서 제 블로그에 담.. by 쏭섭 at 11/23 최근 등록된 트랙백
메뉴릿
이글루 파인더
|