MFC 내부구조 #1 MFC Internals - 대충 읽어볼 글
|
MFC 내부구조 #1
 MFC Internals 2004/06/22 21:03
|
간단히 정리하자.
MFC는 MS의 천재들이 기어나와서 (MS가 아닌사람도있다) Application Framework 라는 팀을
개설하고 진정한 객체지향 프로그레밍을 위해 힘썼다.
근데 AFX가 된이유는 AF만 쓰면 뭔가 약자같아보여서 X를 붙였다고한다.(진짜로)
아무튼 MFC 1.0의 경우 엄청난 비난과 찬사를 받았지만 궁극적으로 운영체제와너무
동떨어진 프레임웍이 나왔다. 그래서 완전 폐기해버리고 전격적인 윈도우즈 프로그레밍
전용 객체지향 프레임웍을 내놓은것이 지금의 MFC이다.MFC는 COM으로 만들어졌다.
그래서 디테일한 code가 숨겨져있다(제기랄). 뭐 그대신 COM의 특성대로 버전이 올라가
더래도 그전 버전의 코드를 그대로 쓸 수있다. (재사용성) 뭐 사실 MFC 4.0과 6.0, .NET의
7.0도 별 차이가 없다.(근데 닷넷 C++의 MFC가 7.0이었던가? c# 손땐지 너무 오래되서
확신못함..)아 맞군! (조사했다.) 7.0이다!
잠소린 그만하고 이제 MFC을 벌려보자.
MFC 훓기
1.CObject: 대부분의 MFC 클래스의 엄마
MFC관련 서적 사면 가끔씩 MFC 지도를 준다. Class Tree라구하지..
그녀석의 왼쪽 꼭대기는 보통 CObject 클레스이지.이녀석은 꽤 좋은기능
들로 똘똘 뭉처져있고 최적화되있다. 이런 편리한 기능들을 이용하기위해
MFC의 class는 CObject의 다양한 기능을 사용한다.
-CArchive는 CObject와 함께 영속성을 처리한다.(겜으로치면 save)
-CDumpContext는 진단함수(Diagnostic function:디버그용 함수들)에서 사용된다.
-CRuntimeClass는 CObject에서 파생된 모든 Class 와 관계되며, 그 class 에대한
정보를 가지고있다.
2.예외 처리 class
익셉션은 app가 제어권을 잃었을때 발생하지.MFC는 프로그렘을 보호하기위해
예외상황을 exception handler에게 던진다.(throw)
-CException - 예외처리 class
-CArchiveException - serialization 시 발생하는 예외 (save할때 -_-)
-CFileException - file 연산이 수행되는 동안 ~
기타등등.
3.Memory Diagnostic
메모리 leak을 추적하게 해준다.<- 이거 왠만한 강의나 책을 보면 포인터쪽에서
항상 강조되지.메모리누수 무시무시하다거... 이거 사실 당해본사람이아니면
그 절망감을 공감하기힘들다.(진짜 에니메이션볼때 "두둥" 하며 끝판왕이 등장했을때의
갓츠의 모습이다.끝판왕=그리피스)
4.Collection Class
CByteArray,CWordArray, 등등...(솔직히 클레스로 왜만들었는 지모르겠다)
List Class로는...
CObject에서 주는 list 클레스도있고 CPtrList,CStringList(CString용)
그리고 map (자료구조 순서대로다.. array-list-map-hash 근대 해쉬나 멥이나 그게그거)
CMapPtrToWord , CMapPtrToPtr , CMapStringToOb , CMapWordToPtr 등..
MFC만든놈들은 미친놈이 맞다.
5. 동적 String
CString은 말안해도 최강.(특히 유니코드까지지원한다는 점에서 - 쑹의 생각)
6. File Class
CFile , CStdioFile CMemFile class 등등..
7. Time class들
시간관리
8.기타
음 사실 MFC라는 놈은 API를 Wrap한것들을 모아놓은것이라고 치부할 수도 있다.
-=따지고보면 그렇게 틀린건아니니까=-
대강 훓어보았다.
자 이제 MFC API를 어떤식으로 포장했는지
뒤집어 까보자
(지금 책을 보면서 복습하고있는데 전에 공부했던 흔적을 보고 갑자기 떠올랐다.
원래 참견과 비밀을 파해치는걸 좋아했던지라.. 이공부가 꽤나 재밌었던 과거)
MFC 포장 까기
MFC가 해낸 중요한 한 가지는 매우 복잡한 API를 잘 포장 했다는점이다.
Window API class는 Windows에서 사용되는 Windows Object를 Encapsulation 하고
있다. 이럿은 매우 어렵지만 MFC는 해냈다.
1. Application 안의 class: CCmdTarget. CCmdUI, CWinThread , CWinApp Class
일반 C/SDK app 에서는 message queue에서 message를 가져오고 이를 window procedure
로 다시 보내기 위해서 Winmain()을 사용한다. 사용자에 의해 만들어진 message handler
는 message를 처리하는 case 문이있다. (winProc이되겠지) 이때 걸러져서 WinProc에
없는 경우들은 DefWindowProc()에서 처리한다.
MFC는 이런 과정이 없다.
대신에 message mapping이란 개념을 사용했다. (내가 어떤강사에게 배울때
사실대로말하면 이방법이 훨씬느린 방법이라고 한다.-=당연하다=-)
이 mapping은 CCmdTarget과 CWnd 내에 구현되있다. message mapping 이란
어떤 이밴트가 발생할때 그 이벤트를 처리해주는 어떤 class 내의 어떤 func으로
연계해준다. 윗줄에 썼듯, 이기능은 CCmdTarget class에 구현되있다.
따라서 이놈을 상속받는 클레스는 mapping 기능을 수행할 수이따!.
CCmdUI class는 UI(menu check box 따위)의 상태를 변경시켜주는 여러가지 방법들을
제공한다.
C/SDK 에서 메세지 큐 처리하는 구문이다.
while( GetMessage(LPMSG)&msg, NULL,0,0)){
if(!TranslateAccelerator(hWnd,hAccel,&msg)){
{TranslateMessage((LPMSG)&msg));
DispacheMessage((LPMSG)&msg);
}
}
CWinThread는 이러한 loop를 켑슐화 시킨다. 그래서 MFC에서 WinMain()을
절대 찾을 수 없는 이유이다.
CWinThread로 부터 파생된 CWinApp는 사용자맘대로 init때와 end 때
override 할 수있다.
CWinApp는 CWinThread의 맴버인 Run()을 사용할 수 있다.
2. 동기화 클래스
멀티스레드 프로그렘을 단순화하기위해 MFC에는 다양한 종류의 Win32
synchronization의 기능을 제공하는 class 들이있다.
모든 동기화 클래스는 CSyncObject를 상속 받는다.
CCriticalSection - API 배울때 잴처음나오는놈. 한개 스레드작동하면 딴놈들 묶는거지.
CSemaphore - 한개 객체에 한개이상의 Thread를 접구ㅡㄴ가능 하게 해주지
CMutex 하나의 객체에 [한번에] 하나의 thread가 동시접근 가능하도록 해준다.
CEvent - 어떤 ecent가 발생했을때 app에게 알려주는 동기화.왠지 ATL/COM이 떠오르지
않는가?
CSingleLock - 리소스접근 막을라고 lock 하는짓껄이. 이번엔 DirectX의 백버퍼에
그림 뿌리는게 떠올랐다.
CMultiLock - 여러게 잠그는거지.
3. 그외에 class
CCommandLineInfo - 응용 프로그렘이 시작될때 command line을 분석한다.(파서기능)
CWaitCursor - 화면상에 wait cusor (모래시계)를 보여준다.
4. CWnd: 모든 window의 어머니
CWnd는 CCmdTarget으로부터 파생됬다. 따라서 메시지처리능력이있고 모든 window는
CWnd에서 파생된다. 그것은곧~ window handler가 있단 소리고 이것은 또다시 HWND가
있다는소리다. *.h 를 열어보면 m_hWnd가있다. 가끔 코딩때 쓰인다.
이놈은 UI의 요람이다.모든 UI의 house라는 표현이 맞을까?
보통 커멘드가 들어오면 가장먼저 감지하는것은 Frame! CFrameWnd나(SDI)
CMultiFrameWnd 역시 CWnd 상속물들!그리고 각종 Control 들과 버튼 체크박스
리스트등의 모든 표즌 Control외에 CWnd 에 owner-draw기능을 포함시켜서
개발자가 쉽게 owner-draw control을 만들 수 있도록 했다.
참고:오너 드로우란? control의 스타일을 OWNERDRAW로 설정하면,
윈도우는 여러가지 정보가 담긴 구조체를 넘겨준다. 이구조체를 에디트하면
윈도 크기 버튼 리스트박스등등을 구현할 수있는데 edit box는 불가능.
5. GDI 지원과 Drawing 객체
MFC는 다양한 class 를 통하여 windows Graphics Device Interface를 지원한다.
GDI의 핵심은 DC이다. MFC는 CDC이지.API 때는 HDC쓸때 설정, 다쓸때 release
해주지. 근데 CDC는 소멸자에 릴리즈가 구현되잇다.
Application Framework Class
MFC가 인정을 받는이유는 Framework때문이라고 생각한다.실지로 MFC 2.0부터는 MFC로
체계적이고 견고하며 안정성있는 프로그렘을 빠른속도로 제작할 수 있게되었기 때문이다.
Framework의 Architecture를 알아보자.
1. Document/View Architecture
이구조의 아이디어는 실제 데이터부분과 그 데이터를 보여주는 부분을 구분하자는것이었다.
하나의 데이터 집합이있다면 여러 개의 view를 이용해서 보여줄 수 있다. 이 D/V 구조의
클레스들을 살펴보자.
CDocTemplate , CSingleDocTemplate, 그리고 CMutiDocTemplate – document template는
Document와 view를 연결시켜주는 역할을 한다. 즉 MFC의 대두 세가지 view doc frame사
이에 연결고리와도 같은것이다.
CDocument – Cdocument는 응용프로그렘 내에서 데이터를 다루는 Class이다.
CView – 이놈은 WM_PAINT와 같은놈.
2. Context – Sensitive Help
이건 MSDN -_-
오늘 인터널 끝!
[출처] MFC 내부구조 #1|작성자 쑹