codeheart 위치로그  |  태그  |  미디어로그  |  방명록
icon 개발 에 해당하는 글52 개
2009.11.03   reactor, proactor 패턴
2009.10.22   C++ Decorated 된 함수명 undecorate 하기
2009.10.22   MAPFILE 생성하기
2009.10.21   포스트모템 디버깅
2009.10.20   컴파일/링크/런 타임 최적화 전략
2009.10.16   Sysinternals Suite - 각종 유용한 윈도우 툴들
2009.10.16   코드 상으로 debug break 하기
2009.09.13   내가 코딩할 때 사용하는 폰트..
2009.07.04   ATL/WTL
2009.07.04   Visual Studio 2008 심볼 파일(pdb)로 디버깅을 보다 용이하게 하자!


icon reactor, proactor 패턴
개발/VC++ (네트워크) | 2009. 11. 3. 14:09

reactor 을 통한 dispatch service (message handling)
http://cafe.naver.com/multism.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=3490

reactor vs proactor
http://www.anfamily.net/mcsong/301


arrow 트랙백 | 댓글



icon C++ Decorated 된 함수명 undecorate 하기
개발/Windows 디버깅 | 2009. 10. 22. 12:20

Platform SDK(Windows SDK) 의 undname 유틸 이용하기
>> undname "?MapDLLHappyFunc@@YAPADPAD@Z"

arrow 트랙백 | 댓글



icon MAPFILE 생성하기
개발/Windows 디버깅 | 2009. 10. 22. 12:07

1. LINKER 에서 /MAP 옵션
2. DUMPBIN /EXPORTS <modulename>

arrow 트랙백 | 댓글



icon 포스트모템 디버깅
개발/Windows 디버깅 | 2009. 10. 21. 18:56

자동으로 덤프하게 하여 디버깅하는 기법으로 실전 윈도우 디버깅을 참고
이를 이용하여 보다 신속히 오류나는 상황을 캐치할 수 있다.

알아볼 점
1. 디버깅/릴리즈 배포판에 따른 메모리 덤프의 차이는 발생하지 않는가? 클라이언트 버젼에 따른 차이는 충분히 발생할 수 있다.
2. C9 에 자동 덤프 시스템이 내재되어 있는가?


arrow 트랙백 | 댓글



icon 컴파일/링크/런 타임 최적화 전략
개발/VC++ (윈도우) | 2009. 10. 20. 21:39

컴파일 타임

링크 타임
1. Incremental Link 을 켜자
- /OPT:REF 와 /OPT:ICF 를 꺼야 한다.
- /OPT:REF ; 참조되지 않는 함수를 제거한다. 여기서 OBJ 생성시 오래걸린다. 물론 대신 런타임 성능은 코드 간소화로 인해 개선될 수 있다.
- /OPT:ICF ;
- 요약1 ; 런타임 성능이 중요한 배포버전에는 적용하면 안되며, 개발용 버전(디버그/개발용 릴리즈)에 적용할 만 하다.
- 요약2 ; 물론 디버그 버전에서 기존 것보다 너무 느려진다면 테스트에 지장이 생기므로 고려해야 한다.

런 타임
1. /C7 이 있다면 없애고 PDB 파일 형식으로 디버깅 심볼을 저장하도록 수정한다. 이는 실행파일 크기를 줄여주며 성능 향상으로 이어진다. 물론 릴리즈 버전 실행파일에 디버깅 정보가 전혀 없다면 효과가 없을 수도 있다.

2. WST(Platform SDK 에 있음) 나 SWS(이 것이 더 최신 정보) 와 같은 도구를 이용한다면 자주 사용되는 함수를 바이너리 앞으로 놓게되어 성능향상을 가져다 줄 수 있다.

'개발 > VC++ (윈도우)' 카테고리의 다른 글

windows 계의 apt-get > chocolatey  (0) 2013.09.10
MinGW MSYS ls 컬러링/한글안깨지게  (0) 2013.05.23
Windows SDK 각종 문자열 API  (0) 2010.03.24
ATL/WTL  (0) 2009.07.04

arrow 트랙백 | 댓글



icon Sysinternals Suite - 각종 유용한 윈도우 툴들
개발/Windows 디버깅 | 2009. 10. 16. 02:57

파워유저 / 개발자에게 유용한 툴로 디버깅 시에도 유용할 수 있다.
Process Explorer(procexp) 는 작업관리자를 대체할 수 있는 용도로 매우 쓸모 있다. (FileMon 과 RegMon 을 통합한 기능)
Spy+ 과 비슷한 Process Monitor..

http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx

arrow 트랙백 | 댓글



icon 코드 상으로 debug break 하기
개발/Windows 디버깅 | 2009. 10. 16. 02:45

assert(false) 할 때도 내부적으로 break 가 일어나는데,
이러한 break 는 intrin.h 에 정의된 __debugbreak 함수를 호출한다.
이는 __asm { int 3 } 과 동일하다. intrinsic 헤더인 것을 봐도 동일한 것으로 추측.

http://msdn.microsoft.com/ko-kr/library/f408b4et%28en-us,VS.80%29.aspx


arrow 트랙백 | 댓글



icon 내가 코딩할 때 사용하는 폰트..
개발/기본 | 2009. 9. 13. 14:45

나는 Visual Studio 로 코딩할 때(다른 툴도 거의 마찬가지지만) 꽤 오래전 부터 Courier New 를 사용했다.
아주 초창기 시절에는 bitmap 폰트인 Courier 를 사용했지만, 거의 대부분은 Courier New 와 함께 한 것 가다.

폰트란 생각보다 중요한데 소수의 생각일 수도 있겠지만, Visual Studio 한글판(?)의 기본 폰트인 돋움체는 코딩할 때 멋도 없고 감도 나지 않는다. 진정한 목수는 연장탓을 하지 않는다고 하지만.. 음(?)

본론으로 돌아가서, Courier New 는 벡터 폰트임에도 불구하고 alias 을 안 메기는 것이 훨씬 깔끔하다.
비록 Courier 와 차이가 거의 없어져버리지만..
그렇지만 비스타 시절부터 현재 사용하는 윈도우7 까지 윈도우 폰트 설정은 XP 와 달리 기본적으로 alias 으로 셋팅되어 있다.
이러한 설정은 Visual Studio 에서는 따로 설정할 수 없으므로, 결국 윈도우 셋팅에서 alias 을 제거하거나
Visual Studio 에서 alias 을 한 상태로 사용해야만 한다.
하지만, alias 이 메겨진 Courier New 는 가독성이 그리 높지 않다. 약간 뿌옇기 때문에..
기본적인 폰트인 돋움체로 가는 게 오히려 Courier New 보다 나을지도 모르겠다는 생각이 들었지만 좀 더 찾아보기로 했다.
우선 코딩 폰트는 Fixed-width fonts 여야 한다. 꼭 그럴 필요는 없지만, 편집시 용이하고 깔끔하기 때문이다.
후보는 다음과 같았다.
Fixedsys, Courier, 돋움체, 네이버 코딩 폰트, Consolas, Lucida Console, Lucida Sans Typewriter..
안타깝게도 Fixed-width 폰트임에도 불구하고, 대부분의 Fixed-width 는 한글폭이 영어 폭의 2배랑 같지 않았다.
이는 Visual Studio 개발자가 2바이트 시장을 충분히 고려하지 않아서 생긴 문제점으로 보인다.
누가 좀 피드백 좀 넣어줬으면 하겠는데..
결국, 선택의 폭은 급격히 줄었다. Consolas, Lucida Console 역시 괜찮은 폰트임에도 불구하고 이런 점 때문에
Lucida Sans Typewriter 를 현재까지 사용한 Courier New 의 대체 폰트로 선택했다.
지금까지 몰랐는데, vector 폰트지만 더 진하고 가독성이 좋아보인다. 그리고 폰트 자체도 각이 딱딱 진 것이 아주 마음에 든다. 한 때 네이버 코딩 폰트 등 다른 폰트들도 써봤는데, 결국 Courier New 로 돌아왔었는데.. 과연 이 폰트로 얼만큼 버틸 수 있을지?? ㅎ


arrow 트랙백 | 댓글



icon ATL/WTL
개발/VC++ (윈도우) | 2009. 7. 4. 06:08

WTL 은 Windows Template Library 로,
STL 과 같이 Template 형식의 순수 .h 파일 라이브러리다.
다만 그 목적은 윈도우 어플리케이션 프레임워크인 MFC 와 유사하다.
ATL 과 WTL 사이의 역사는 잘 모르겠지만, 아마도 ATL 이 먼저인 것 같다.
애초에 MFC 개발자들이 구조적으로 MFC 를 일반화하기 위해 내부 코어를 템플릿화시키지 않았을까?
그래서 ATL 이 탄생했고, 과거의 MFC 와 달리 현재의 MFC 는 하위 층에 ATL 을 사용하고 있다.
또한 ATL 을 확장하여 WTL 이 탄생하였는데 ATL 은 MFC 의 베이스를 구성하고 있지만
독립적으로 윈도우 프로그램을 작성할 수는 없다.
(보다 정확히 말하자면 간단한 프로그램을 만들 수 있으나, 고급 수준의 기능을 사용하기에는 다소 부족하다.)
따라서, ATL 의 특성을 바탕으로 MFC 을 대체할 만한 라이브러리인 WTL 가 탄생된 것 같다.

분명히 WTL 은 MFC 에 비해 여러모로 우수하지만, 몇가지 단점으로 인해 MS 가 버린 듯 하다.
버렸다는 얘기는 오픈소스화했다는 것이고, 지금 오픈소스로 명맥이 유지되고 있다.
즉, MS 의 직접적인 지원(개발툴에 포함되는 등의)은 없다.

MFC 에 비해 WTL 이 가지는 장점은, 일단 외부 DLL 이 필요없다.
단순히 API 를 템플릿 차원으로 랩핑했기 때문에 부가적인 오버헤드가 발생하지 않는다.
그리고, 최소한의 가상 메쏘드를 사용하였고 가능한 많은 부분을 제네릭하게 작성하였다.
이러한 점은 많은 이점을 낳는다. 코드의 독립성이 뛰어나게 되며, 재사용성이 증대된다.
또한, 생성되는 실행파일 용량이 훨씬 작고, 성능도 더 우수하다.
게다가 MFC 보다 후에 등장해서 그런지 구조적으로 조금 낫다.
따라서, WTL 은 MFC 에 비해서는 타이핑량이 줄고, 간단한 소스를 만든다.
API 를 아주 추상적으로 랩핑하지 않았음에도 IDE 의존도가 높은 MFC 에 비해서 어느 정도 코드 생산성이 있어 보인다.
(구조적으로 조금 낫다는 것은 WTL 역시 MFC 의 베이스를 깔고 있는 ATL 를 확장한 것이라, 많은 부분 호환적인 소스가 보인다. 만일 이런 부분을 버렸다면, WTL 은 구조적으로 더 발전될 수도 있었을 것 같다.)

그렇지만, WTL 은 MFC 보다 C++ 에 대한 더 높은 이해를 필요로 한다.
그리고 제네릭, 가상함수 등의 지식도 어느 정도 있어야 한다.
사실 MFC 나 ATL/WTL 이나 C++ 을 온전히 모르고 쓸 수 있도록 배려한(?) MS 개발자들의 트릭들이 존재하기
때문에 모든 문법 사항을 필수적으로 알아야 하는 것은 아니다.
그렇지만, 확실히 WTL 코드는 C++ 입문자들이 접하기에는 다소 어려울 듯 싶다.
이 점이 MS 가 WTL 을 포기한 이유인 듯 싶다. (내부적으로 유사한 ATL만을 공유하는듯)

하지만 WTL 에도 어느 정도의 꼼수와 트릭이 제공되는 듯하다.




arrow 트랙백 | 댓글



icon Visual Studio 2008 심볼 파일(pdb)로 디버깅을 보다 용이하게 하자!
개발/Windows 디버깅 | 2009. 7. 4. 00:33

심볼 파일(.pdb)이란?

심볼 파일이란 프로그램의 디버그 정보(함수 이름 등)이 담겨진 파일이다.
Visual Studio 에서는 2.0 부터 이러한 심볼 파일을 도입하였는데, 그 확장자는 .pdb 이다.
pdb 는 program database 의 약자로, 앞으로 심볼 파일이라 함은 .pdb 파일을 지칭한다.

Visual Studio 로 개발을 하다보면 .pdb 란 파일이 생기는 것을 알 수 있다.
이 것은 프로젝트 설정에 따라 생길 수 있다.
Debug / Release 에 상관없이 디버그 정보는 항시 들어가 있으며, 다만 얼마나 자세한 디버그 정보가 들어가나
정도의 차이가 있을 수는 있다. (정확히는 프로젝트 옵션에 의거하여 그 정도가 바뀌게 된다)

우리가 디버깅을 할 때 화면상에 나타나는 수많은 정보(디버깅 창의 함수명, 라인 등등)이 이 파일에 들어가는데,
만일 이 파일을 지우게 되면 그런 정보를 볼 수 없다.
물론, 우리는 우리가 작성한 프로그램은 당연히 소스를 가지고 있고, 이러한 .pdb 파일의 재생산이 가능하기 때문에
심볼 파일의 기능에 대해서 모르고 지나쳤을 수도 있다.

하지만, 우리가 작성한 부분이 아닌 수많은 Windows 기본 dll 내지 MFC dll 등은 이러한 디버깅 정보를 획득할 수가 없다.
당연히, 윈도우를 설치한다고 이러한 .pdb 파일까지 설치해주지는 않는다.
일반 사용자에게 이러한 .pdb 파일은 필요가 없는 것이다.
그렇다면, 왜 Visual Studio 는 이러한 심볼 파일을 설치해주지 않을까?
잘은 모르겠지만, 여러가지 이유가 있다고 본다.

우선, 심볼 파일들의 용량은 생각보다 만만치 않은데, microsoft 에서 일반적으로 사용되는 dll(혹은 개발에 연동되는 모든 모듈들)의 심볼파일들은 상당히 많을 뿐더러, 용량을 다 합치면 800mb 가 넘어버린다.

다음으로, 일반적인 개발에 있어 심볼 파일까지 필요한 경우는 드물다.
사실, 심볼 파일 없이도 충분히 프로그램을 작성할 수 있다.

또한, 윈도우 플랫폼별로 dll 도 형태도 조금씩 다를 수 있고(COM 방식의 경우 API 도 다소간의 차이가 있을 수 있으니까), 이러한 심볼파일을 Visual Studio 배포 CD 에 포함시킨다는 것은 무의미할 수도 있다.


심볼 파일의 필요성

하지만, 확실히 심볼 파일은 어느 정도 이상의 디버깅을 요구하는 개발자라면 심볼 파일은 상당히 필요하다고 본다.
어떤 API 에서 그러한 오류가 발생되었는지, 콜 스택을 확인하는데 무의미한 주소(심볼 파일을 가지고 있지 않다면, 디버깅 정보가 없어서 함수이름 대신 주소만이 나올 뿐이다)만 잔뜩 나온다면 상당히 골치 아플 것이다.

또한, 경험상 함수이름을 떠나서, 기본API 심볼 파일의 부재로 내가 만든 프로그램 자체의 콜스택 정보가 제한되는 현상을 목격하였다. 특히, 예외처리를 F5 로 캐치하였을 때 정확한 소스 위치(무슨 소스 파일의 몇번째 줄)을 알 수가 없었다.
이는 웬지 Visual Studio 버그일 수도 있다는 생각이 들었는데, 왜냐하면 항상 그런 것은 아니기 때문이다. 아주 가끔씩은(셋팅은 건드리지도 않았다) 정확한 소스 위치가 콜스택 상에 보일 때가 있었기 때문이다.


기본API 심볼 파일의 설치

그렇다면, 기본API 심볼 테이블은 어떻게 설치하는가?

두가지 방법이 있다.
하나는 심볼 파일들을 압축하나 파일을 microsoft 홈페이지에서 다운로드 하여 설치하고, 로컬 경로를 설정하는 방법이다.
다음은 Microsoft Symbol Server 사이트 url 을 심볼 파일 경로로 설정하는 방법이다.
후자가 가능하면서 심볼 파일 설치 / 사용이 상당히 간단해졌다.

1. Options 메뉴 - Debugging - Symbols 으로 들어가게 되면 다음과 같은 화면이 나온다.

위 화면에서 Symbol file (.pdb) locations: 밑에 심볼 파일 위치가 올 수 있다.
a. 위치 형식은 로컬(예 : c:\windows\symbols\),
b. 심볼 서버 URL(예 : http://msdl.microsoft.com/download/symbols/),
c. 윈도우 네트워크 경로(예 : //server2/where/symbols/)가 될 수 있다.
참고로, 심볼 서버 URL 중 디폴트 서버(http://msdl.microsoft.com/download/symbols/)는 굳이 입력하지 않아도 상관없다.
또한, 디폴트 서버에서만 심볼 파일을 가져올 생각이라면 어떠한 경로도 따로 지정하지 않아도 된다.

2. 그 밑에 Cache symbols from symbol servers to this directory: 가 보이고
여기에는 심볼을 캐쉬할 디렉토리이다. 아무 디렉토리도 상관없으니, 캐쉬 디렉토리를 지정한다.
지정하게 되면 지금까지 로드된 심볼을 캐쉬할 공간으로 사용되게 된다.
심볼 서버에서 가져오는 경우 인터넷 부하에 의해 개발 속도 저하가 될 수 있으니, 이 기능을 통해
캐쉬하는 것이다.

3. 밑에 체크박스가 있는데, 자세한 설명은 제하고 일단 체크하지 않는다.

4. 밑에 오면 두 버튼이 보인다.
Load symbols using above locations
Load symbols from Microsoft symbol servers
첫번째 버튼은 위 리스트 박스에 입력한 경로에서 심볼을 읽어오는 것이며,
두번째 버튼은 MS 디폴트 심볼 서버들에서 가져오는 것이다.
이 두 버튼은 평소에 활성화 되어 있지 않지만, Visual Studio 프로젝트를 열게 되면 활성화 된다.
따라서 이 버튼들을 누르게 되면, 현재 열린 프로젝트에 관련한 심볼 파일들을 확보하게 된다.
확보된 심볼 파일은 해당 프로젝트 디버깅시 유용하게 쓰일 수 있을 것이다.


실행 예제

다음과 같이 소스를 작성하고 F5 를 눌러보자.
오른쪽 밑에 Call Stack 을 보면 kernel32.dll! 뒤에 숫자(함수 주소)로 나왔던 정보가 이제는 심볼 파일에 의해 해석되어 함수명으로 나오는 것을 알 수 있다.
또한, 심볼 파일 적용 후 throw 부분의 위치를 Visual Studio 에서 더 정확하게 파악했다.
(뭔가 이상하지만, 심볼 파일이 적용되기 전에는 정확한 예외 발생 위치를 파악하지 못했다. 더욱 웃긴것은 10번에 한번 정도 확률적으로 파악될 때도 있었다는 것이다. 여하튼, 심폴 파일 적용 후 더 잘 파악된다는 것은 확실하다)


arrow 트랙백 | 댓글



[PREV] [1][2][3][4][5][6] [NEXT]
관리자  |   글쓰기
BLOG main image
code heart story
분류 전체보기 (74)
생활 (0)
잡담 (8)
컴퓨터 (11)
개발 (52)
Total :
Today :
Yesterday :
rss
위치로그 : 태그 : 방명록 : 관리자
코드하트's Blog is powered by Daum / Designed by plyfly.net