codeheart 위치로그  |  태그  |  미디어로그  |  방명록
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 트랙백 | 댓글



icon javascript 로 jquery 비슷한 구현
개발/Web | 2009. 7. 1. 20:07

사실 웹 개발에 관심을 두고 있지 않지만, 취미차원에서 다루기에는 괜찮다.
자바스크립트 문법 역시 잘 알고 있지는 않지만, jquery 같은 심플한 예제를 만들어 보기로 했다.
하다보니까 이런 구현도 흥미있다.
주로 사용하는 C++ 에서는 이러한 식의 개발은 컴파일타임/런타임 문법 혼용해서 하지 못하는데,
스크립트 언어를 사용하게 되면 무언가 공중에서 자유를 만끽하는 느낌이랄까?

jquery 처럼 $(id) 로 객체를 갖고 오는 것이 가능하고, 실제로 Node 객체가 아닌 확장성을 위해 추상화한 객체를
반환한다. 또한 $.name(name) 으로 그룹으로 객체를 갖고오는 것도 가능하다.
이런 경우 .attr 메쏘드로 속성을 매길 때 내부 소유 객체에 모두 매겨질 수도 있다.
내가 jquery 를 직접 건들여본일은 몇번 없어서 함수명에 다소 차이는 있다.
라인수를 봐도 알겠지만, .attr, .css, .append(child) 정도밖에 구현을 해놓지 않았다. 기능이 몇개 없다 -_-;;
그리고 Node 생성하는 것은 $.text, $.element 정도만 구현해놓은 상태다.
이벤트 생성 이런 것등에 대한 고려는 되어있지 않다.
하지만, 다소 일반화를 고려하여 작성해서 확장시에 소스라인이 그다지 증가되지 않을 것이다.



>> 화면 결과


arrow 트랙백 | 댓글



[PREV] [1][···][21][22][23][24][25] [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