2.GDI+의 구조

가.GDI와 다른 점

GDI는 C수준의 함수 집합인데 비해 GDI+는 클래스의 집합이다. 라이브러리를 구성하는 부품들이 다름으로 해서 코드를 작성하는 방법도 질적으로 다르다. 구체적으로 어떤 점이 다른지 큰 차이점부터 살펴보자.

① 모든 그리기 함수들은 단독으로 존재하는 함수가 아니라 Graphics 클래스의 멤버 함수로 정의되어 있다. 그래서 그리기를 하기 전에 Graphics 객체를 먼저 생성해야 한다. GDI에서 DC를 먼저 발급받아야만 어떤 출력이라도 가능한 것과 마찬가지이다.

② GDI의 DC에는 출력 속성들이 모두 들어 있는데 반해 GDI+의 Graphics 객체는 아주 특수한 몇가지를 제외하고는 그려질 도형에 대한 속성을 가지지 않는다. 그래서 출력 함수들은 그리기에 필요한 값들을 매번 인수로 전달받는다. 예를 들어 GDI에서 파란색 선을 그리려면 파란색 펜을 DC에 선택한 후 그리고 펜을 선택 해제하지만 GDI+에서는 선을 그릴 때 펜 자체를 인수로 전달한다. DC에 GDI 오브젝트를 넣었다 뺐다 할 필요가 없다.

③ 똑같은 도형을 그리는 함수도 인수의 타입에 따라 여러 가지가 준비되어 있다. 예를 들어 선을 긋기 위해 두 개의 점을 전달할 수도 있고 네 개의 정수값을 전달할 수도 있다. C++ 언어의 함수 오버로딩 기능을 십분 활용하여 인수 타입에 따라 함수를 중복 정의하므로 상황에 따라 편리한 함수를 호출하면 된다.

④ 펜, 브러시 등의 GDI 오브젝트들은 모두 C++ 객체이므로 해제 코드를 따로 작성할 필요가 없다. 지역 변수로 생성된 객체들은 함수가 종료될 때 파괴자가 자동으로 호출되어 필요한 뒷정리를 한다. 이것이 바로 C++의 장점이다. 그래서 실수에 의한 리소스 누출의 위험이 GDI보다 훨씬 더 낮다. 물론 new 연산자로 동적으로 생성한 객체는 delete로 직접 삭제해야 한다.

⑤ GDI+에서 사용하는 모든 문자열은 유니코드여야 한다. 문자형은 반드시 WCHAR형으로 선언해야 하며 문자열 상수앞에는 접두 L을 붙여야 한다. 프로젝트 자체가 유니코드가 아닐 경우 문자열을 유니코드로 변환한 후 사용해야 한다.

이런 차이점 외에도 GDI+는 반투명 처리, 텍스트의 안티 알리아싱, 다양한 그리기 옵션, 압축 이미지 출력 등 헤아릴 수 없는 많은 기능들을 추가로 제공한다. 그래서 마이크로소프트는 새로운 응용 프로그램을 작성할 때는 가급적이면 GDI보다는 GDI+를 사용할 것을 권장하고 있다. 그러나 호환성을 위해 GDI도 앞으로 계속 지원될 것이다.

시기적으로 더 늦게 만들어진 GDI+가 GDI에 비해서는 당연히 더 많은 기능을 제공하고 때로는 더 좋은 성능을 보이겠지만 현실적으로는 앞으로도 상당한 기간동안 GDI를 완전 대체하기는 어려울 것으로 예측된다. 일단은 GDI가 프로그래머들에게 너무 익숙해져 있다는 관습적인 문제가 있고 또 속도라는 아주 중요한 차이점이 있기 때문이다.

라이브러리의 기능이 많아지면 단순한 출력에 대해서도 이것 저것 신경써야 할 것이 많아지므로 전체적인 속도가 떨어지기 마련이다. GDI+도 예외가 아니어서 GDI보다는 객관적으로 훨씬 더 느리다. 두 라이브러리의 속도차가 얼마나 나는지 예제를 만들어서 직접 테스트해 보자. 다음 예제는 난수로 선택한 색상으로 타원 만 개를 그리는데 출력과 무관한 코드는 가급적 배제하여 공평하게 속도 측정을 했다.

예 제 : GdiSpeed

#define random(n) (rand()%n)

void SpeedTestGdi()

{

HDC hdc;

HBRUSH hBrush,hOldBrush;

int i;

int x,y,w,h;

hdc=GetDC(hWndMain);

SelectObject(hdc,GetStockObject(NULL_PEN));

for (i=0;i<10000;i++) {

hBrush=CreateSolidBrush(RGB(random(256),random(256),random(256)));

hOldBrush=(HBRUSH)SelectObject(hdc,hBrush);

x=random(640);

y=random(480);

w=random(150)+50;

h=random(150)+50;

Ellipse(hdc,x,y,x+w,y+h);

DeleteObject(SelectObject(hdc,hOldBrush));

}

ReleaseDC(hWndMain,hdc);

}

void SpeedTestGdiPlus()

{

Graphics G(hWndMain);

SolidBrush S(Color(0,0,0));

int i;

int x,y,w,h;

for (i=0;i<10000;i++) {

S.SetColor(Color(random(256),random(256),random(256)));

x=random(640);

y=random(480);

w=random(150)+50;

h=random(150)+50;

G.FillEllipse(&S,x,y,w,h);

}

}

LRESULT CALLBACK WndProc(HWND hWnd,UINT iMessage,WPARAM wParam,LPARAM lParam)

{

HDC hdc;

PAINTSTRUCT ps;

DWORD st;

TCHAR str[128];

TCHAR *Mes=TEXT("왼쪽 클릭 : GDI 그리기, 오른쪽 클릭 : GDI+ 그리기");

switch(iMessage) {

case WM_CREATE:

hWndMain=hWnd;

return 0;

case WM_LBUTTONDOWN:

st=GetTickCount();

SpeedTestGdi();

wsprintf(str,TEXT("소요 시간 = %d틱"),GetTickCount()-st);

SetWindowText(hWnd,str);

return 0;

case WM_RBUTTONDOWN:

st=GetTickCount();

SpeedTestGdiPlus();

wsprintf(str,TEXT("소요 시간 = %d틱"),GetTickCount()-st);

SetWindowText(hWnd,str);

return 0;

case WM_PAINT:

hdc=BeginPaint(hWnd, &ps);

TextOut(hdc,10,700,Mes,lstrlen(Mes));

EndPaint(hWnd, &ps);

return 0;

case WM_DESTROY:

PostQuitMessage(0);

return 0;

}

return(DefWindowProc(hWnd,iMessage,wParam,lParam));

}

마우스 좌우 버튼을 누르면 GDI와 GDI+로 똑같은 타원 만개를 그리는 동작을 각각 수행하며 경과 시간을 타이틀 바에 출력했다.

시스템마다 결과는 조금씩 다르게 나오겠지만 GDI가 GDI+보다 작게는 5배 많게는 10배 정도 더 빠르다. 코드를 다음과 같이 수정하여 브러시의 색상에 알파를 적용하여 반투명으로 출력하도록 수정해 보자. 워낙 느리기 때문에 회수도 1000번으로 줄였다.

void SpeedTestGdiPlus()

{

....

for (i=0;i<1000;i++) {

S.SetColor(128,Color(random(256),random(256),random(256)));

좀 느린 시스템에서는 타원을 그리는 모습이 눈에 보일 정도로 느리다. 계산해 보면 반투명 출력 기능이 없는 GDI보다 대략 700배 정도 더 느린 셈이다. 반투명 처리를 하기 위해서는 화면에 이미 출력된 점을 읽어 논리 연산한 결과를 다시 기록해야 하므로 느릴 수밖에 없다. 이 외에 여러 가지 테스트를 해 보면 GDI+가 GDI보다 적어도 수 배 정도는 더 느리다는 것을 확인할 수 있다.

물론 요즘은 컴퓨터와 그래픽 카드의 성능이 좋아져서 속도는 중요한 고려 대상이 아닌 경우도 많다. 몇 십 %나 두 배 정도의 속도 차이는 하드웨어의 지원으로 무시될 수도 있고 프로그램의 성능이 출력 속도만으로 평가되는 것도 아니므로 중요하지 않을 수도 있다. 그러나 이 두 라이브러리의 경우 속도 차이가 너무 확연하게 드러나기 때문에 속도가 중요한 프로그램에서는 GDI+의 전격 채용을 심각하게 고려해 봐야 할 정도이다.

그렇다고 해서 속도를 위해 GDI+를 일부러 피할 필요까지는 없다. GDI+는 GDI가 할 수 없는 많은 일들을 할 수 있으며 이미지 출력같이 원래부터 시간이 오래 걸리는 작업은 두 라이브러리의 속도차가 심하지 않으므로 출력 품질을 중요시한다면 GDI+를 적극 사용하는 것이 좋다. 다행히 두 라이브러리는 한 프로젝트에서 배타적으로 선택되어야 하는 것이 아니므로 필요할 때만 GDI+를 사용하는 방법도 썩 좋은 선택이라고 할 수 있다. 요약하자면 속도가 필요할 때는 GDI를, 품질이 중요할 때는 GDI+를 사용하면 된다.

나.클래스 계층

GDI+는 C++ 클래스들의 집합인데 최상위의 루트 클래스는 GdiplusBase 클래스이다. MFC 라이브러리에 비유한다면 CObject에 해당하는 클래스라고 할 수 있다. GDI+의 모든 클래스들은 이 클래스로부터 파생된다. 메모리 할당과 해제 기능을 위한 new, delete 연산자만 제공하며 구체적인 동작을 하는 함수는 정의되어 있지 않다. 메모리 관리를 위한 내부적인 클래스에 불과하므로 GdiplusBase형의 객체를 직접 생성할 필요는 없다.

GdiplusBase 루트 클래스 아래에 여러 가지 클래스들이 계층을 이룰 것임은 쉽게 짐작될 것이다. 그러나 대부분의 클래스는 GdiplusBase의 1차 파생 클래스이며 깊어도 2차 이상 파생되는 정도에 불과하기 때문에 GDI+의 클래스 계층 구조는 그리 복잡하지 않다. 게다가 루트 클래스가 그다지 중요한 역할을 하는 것도 아니므로 상속 관계에 대해서는 신경쓰지 않아도 상관없으며 모든 클래스가 단독으로 존재한다고 생각해도 무방한 정도다. MFC에 비하면 훨씬 더 단순한 구조로 되어 있으며 계층이 거의 없는 셈이다.

GDI+의 가장 중요하고도 기본이 되는 클래스는 Graphics 클래스이다. GdiplusBase로부터 파생되며 대부분의 그리기 함수들이 Graphics 클래스의 멤버 함수로 정의되어 있다. 그래서 출력을 하려면 Graphics 클래스의 객체를 먼저 만들어야 한다. 그리기에 관련된 멤버 함수들은 잠시 후부터 순서대로 알아볼 것이고 일단 생성자부터 알아보자. 다음 4가지의 생성자가 정의되어 있다.

Graphics(HDC hdc);

Graphics(HWND hwnd, BOOL icm);

Graphics(HDC hdc, HANDLE hdevice);

Graphics(Image* image);

주로 앞의 두 생성자를 사용하는데 첫 번째 생성자는 hdc를 인수로 전달받아 이 DC의 영역에 그리기를 할 수 있는 객체를 생성한다. DC로부터 Graphics 객체를 구할 수 있으므로 이 생성자가 GDI와 GDI+의 가교 역할을 하는 셈이다. WM_PAINT 메시지에서 GDI+로 출력을 하려면 BeginPaint로 DC 핸들을 얻고 이 DC로 부터 Graphics 객체를 생성한 후 Graphics의 출력 멤버 함수들을 호출하면 된다.

case WM_PAINT:

hdc=BeginPaint(hWnd, &ps);

Graphics G(hdc);

G.선 그리기();

G.동그라미 그리기();

G.비트맵 출력();

...

EndPaint(hWnd, &ps);

return 0;

두 번째 생성자는 윈도우 핸들을 전달받아 이 윈도우의 작업 영역에 그리기를 할 수 있는 Graphics 객체를 생성한다. WM_PAINT가 아닌 임의의 메시지에서 출력해야 한다면 이 생성자를 사용하면 된다. icm 인수는 색상 조정 기능의 사용 유무를 지정하는데 생략할 경우 디폴트인 FALSE가 적용된다. 보통 이 인수는 주지 않는다. 나머지 생성자는 이미지로 더블 버퍼링을 하거나 프린터같은 특정 장치로 출력할 때 사용된다.

일부 몇 가지 함수를 제외하고 GDI+의 모든 함수들은 다음과 같이 정의되어 있는 Status 열거형으로 실행 결과를 리턴한다.

typedef enum {

Ok = 0,

GenericError = 1,

InvalidParameter = 2,

OutOfMemory = 3,

ObjectBusy = 4,

InsufficientBuffer = 5,

NotImplemented = 6,

Win32Error = 7,

WrongState = 8,

Aborted = 9,

FileNotFound = 10,

ValueOverflow = 11,

AccessDenied = 12,

UnknownImageFormat = 13,

FontFamilyNotFound = 14,

FontStyleNotFound = 15,

NotTrueTypeFont = 16,

UnsupportedGdiplusVersion = 17,

GdiplusNotInitialized = 18,

PropertyNotFound = 19,

PropertyNotSupported = 20,

ProfileNotFound = 21

} Status;

수 많은 에러 코드들이 열거 상수로 정의되어 있는데 아무 탈없이 동작을 잘 수행했으면 Ok를 리턴한다. O는 대문자고 k는 소문자이다. OK가 아님을 주의하자. 에러가 발생했으면 에러 원인에 따라 적절한 열거 상수를 리턴하는데 이 리턴값을 읽어 보면 어떤 문제가 있는지 알 수 있다. 열거 상수의 이름이 영문으로 아주 쉽게 작성되어 있으므로 따로 설명은 하지 않아도 의미를 쉽게 알 수 있을 것이다.

응용 프로그램은 함수의 호출 결과를 보고 적절한 에러 메시지를 출력하되 대개의 경우는 Ok인지 아닌지만 점검하여 성공 여부에만 관심을 가질 것이다. 예제 수준에서는 간략함을 위해 Ok인지도 보지 않지만 에러가 발생할 소지가 있는 함수에 대해서는 가급적이면 리턴값을 꼭 점검해 보아야 한다.

함수의 리턴값을 받는 대신 최후의 실패한 에러 코드를 알고 싶을 때는 GetLastStatus 함수를 호출한다. 이 함수는 가장 최근의 에러 코드를 조사하는데 만약 모든 함수 호출이 성공적이었다면 Ok를 리턴한다. 함수의 경우는 호출 즉시 에러 코드를 리턴하므로 굳이 GetLastStatus로 에러 코드를 조사할 필요가 없지만 리턴값의 개념이 없는 생성자의 에러 코드는 반드시 이 함수로 조사해야 한다. 다음 코드는 Image 클래스 생성자의 성공 여부를 조사한다.

Image MyImage(L"prettygirl.jpg");

if (MyImage.GetLastStatus() != Ok) {

MessageBox(hWndMain,TEXT("이미지 파일이 없어 읽을 수가 없다."),

TEXT("공부나 해"),MB_OK);

return;

}

Image 클래스는 읽고자 하는 그림 파일의 경로를 생성자로 입력받는데 파일은 여러 가지 이유(파일 없음, 공유 위반, 배드 섹터)로 읽지 못하는 경우가 많으므로 반드시 에러 처리를 해야 한다. 하지만 자동으로 호출되는 생성자는 성공 여부를 리턴할 수단이 없다. 그래서 일단 객체를 생성한 후 GetLastStatus 함수로 성공 여부를 조사해야 한다.

GDI+는 옵션이나 상태 지정을 위해 상수를 직접 쓰지 않고 열거형을 많이 사용하는데 이 라이브러리의 열거형 전체를 보고 싶으면 GdiPlusEnums.h 헤더 파일을 열어 보면 된다. 열거형은 숫자 대신 열거 상수 이름을 사용하므로 기억하기 쉽고 코드를 읽기 쉽게 하는 장점이 있는데 GDI+는 이런 열거형의 장점을 적극적으로 활용하고 있는 것이다. 다음은 GDI+가 다룰 수 있는 단위에 대한 Unit 열거형이다.

typedef enum {

UnitWorld = 0,

UnitDisplay = 1,

UnitPixel = 2,

UnitPoint = 3,

UnitInch = 4,

UnitDocument = 5,

UnitMillimeter = 6

} Unit;

픽셀, 포인트, 인치, 밀리미터 등등의 단위를 사용할 수 있음을 알 수 있다. 사용하고자 하는 열거형에 대한 도움말은 이 열거형을 사용하는 함수의 도움말에서 링크를 통해 즉시 이동할 수 있도록 되어 있다. 열거형의 이름이 너무 길어 타이프치기 싫다면 필요할 때마다 도움말에서 복사해 오면 된다.

다.기본 타입

GDI+의 함수들은 정수, 실수형에 대해 C언어의 int, float 키워드를 직접 사용하지 않으며 INT, REAL 등의 중간 타입을 사용한다. 이런 식으로 중간 타입을 정의해서 사용하는 이유는 확장성과 이식성을 위한 것임은 두말하면 잔소리다. 헤더 파일을 보면 INT는 int로, REAL은 float로 정의되어 있지만 이 정의는 장래에 바뀔 수도 있다. 그래서 GDI+를 사용할 때 정수형은 INT로 실수형은 REAL로 사용해야 한다.

화면상의 한 지점은 (x, y) 두 축의 조합으로 표현하는데 GDI+는 좌표 표현을 위해 Point 클래스를 사용한다. GDI가 POINT 구조체를 사용하는 것과 개념적으로 유사하지만 Point는 클래스이므로 멤버 함수를 가진다는 점이 다르다. 좌표의 실제값을 가지는 X, Y 멤버들은 public 속성으로 선언되어 있으므로 외부에서도 직접 읽고 쓸 수 있다. Point 클래스의 생성자는 다음 4가지가 정의되어 있다.

Point(VOID);

Point(INT x, INT y);

Point(const Point &point);

Point(const Size &size);

각각 디폴트 생성자, (x, y)좌표를 전달받는 생성자, 복사 생성자, Size 객체의 변환 생성자 등이다. 이 외에 좌표를 관리할 수 있는 몇 가지 멤버 함수들이 더 정의되어 있다. 원형만 봐도 어떤 동작을 하는 함수인지를 쉽게 추측할 수 있다.

BOOL Equals(const Point& point);

Point operator+(const Point &point);

Point operator-(const Point &point);

Equals는 좌표간의 상등 비교를 하며 두 좌표를 가감 연산할 수 있는 +, - 연산자도 정의되어 있다. Point외에 실수형의 좌표를 다룰 수 있는 PointF 클래스도 정의되어 있는데 X, Y 멤버가 REAL 타입이라는 것만 다르다. GDI+는 픽셀 외에도 다양한 논리 좌표를 다룰 수 있기 때문에 실수로 좌표를 지정하기도 한다. 실제 프로젝트에서는 Point보다 PointF를 더 많이 사용하는데 강좌에서는 편의상 Point 타입으로 주로 예제를 만들었다.

Point 클래스는 정의가 무척 간단한 편인데 더 상세한 정보는 도움말에서 얻을 수 있다. 그러나 도움말보다 더 확실한 정보는 헤더 파일을 직접 열어 보는 것이다. GdiPlusTypes.h 헤더 파일에 이 클래스의 선언과 멤버 함수 정의까지 모두 작성되어 있으므로 본체를 직접 구경해 보도록 하자.

Size 클래스는 크기를 표현하는데 공개된(public) Width, Height 멤버와 생성자, 상등 연산을 하는 Equal, 가감 연산자 등의 정의되어 있다. 실수형의 크기를 표현하는 SizeF라는 클래스도 같이 정의되어 있다. 이런 식으로 GDI+는 클래스, 함수 각각에 대해 정수형 버전과 실수형 버전이 두 벌씩 제공된다. 멤버의 타입이 정수가 아닌 실수라는 것외에 기능적인 차이점은 없으므로 한쪽만 알면 나머지 한쪽은 따로 공부할 필요가 없다.

Rect 클래스는 사각 영역을 표현하는 클래스인데 GDI의 RECT 구조체에 대응된다. 그러나 사각영역을 표현하는 방법이 RECT 구조체와는 상당히 다르므로 주의할 필요가 있다. RECT 구조체는 LTRB 형식으로 좌상단, 우하단 좌표로 영역을 지정하지만 Rect 클래스는 X, Y 좌상단 좌표와 폭, 높이인 Width, Height를 멤버로 가진다. 그래서 똑같은 (10,20)-(150,100)의 영역을 표현하는 방식이 다르다.

RECT는 표현하고 싶은 영역의 대각선 꼭지점 좌표를 지정(LTRB 방식)하지만 Rect는 좌상단만 좌표를 지정하고 폭과 높이로 우하단 점을 나타낸다(XYWH 방식). 아주 단순한 차이이지만 실무 프로젝트에서는 이 두 방식이 엄청나게 헷갈리므로 주의하기 바란다. 실수 공간에서의 사각 영역을 표현하는 RectF 클래스도 물론 제공된다. 생성자는 다음 세 가지가 준비되어 있다.

Rect(VOID);

Rect(const Point &location, const Size &size);

Rect(INT x, INT y, INT width, INT height);

디폴트 생성자는 모든 멤버를 0으로 초기화하여 빈 사각 영역을 생성한다. 두 번째 생성자는 좌상단 좌표 Point와 크기 Size를 인수로 전달받아 사각 영역을 초기화하며 세 번째 생성자는 좌표와 크기를 모두 INT형으로 전달받는다. 사각영역을 LTRB 방식으로 표현하지 않으므로 두 점을 전달받는 Rect(Point, Point) 생성자가 정의되어 있지 않음을 유의하도록 하자.

사각 영역을 표현하는 Rect 클래스는 Point나 Size에 비해서는 훨씬 더 복잡한 정보를 표현한다. 또한 사각 영역에 대한 정보를 요구하는 많은 함수들이 있고 다양한 연산이 필요하다. 그래서 Rect 클래스는 Point나 Size에 비해서는 훨씬 더 많은 멤버 함수들을 거느리고 있다. 다음은 Rect 클래스의 전체 멤버 함수 목록과 간단한 설명이다. MFC의 CRect 클래스의 멤버와도 거의 유사하다.

멤버 함수	설명
Rect *Clone(VOID) const;	새로운 사본을 생성한다.
BOOL Equals(const Rect& rect) const;	두 사각 영역이 같은지 검사한다.
INT GetLeft(VOID) const;	return X;
INT GetTop(VOID) const;	return Y;
INT GetRight(VOID) const;	return X+Width;
INT GetBottom(VOID) const;	return Y+Height;
VOID GetBounds(Rect* rect) const;	인수로 전달한 Rect에 이 객체를 대입한다.
VOID GetLocation(Point* point) const;	좌상단 좌표를 조사한다.
VOID GetSize(Size* size) const;	크기를 조사한다.
VOID Offset(INT dx, INT dy);	dx, dy만큼 사각 영역을 이동시킨다.
VOID Offset(const Point& point);
VOID Inflate(INT dx, INT dy);	dx, dy만큼 사각 영역을 확대한다.
VOID Inflate(const Point& point);
BOOL Contains(const Point& pt);	지정한 좌표나 사각 영역이 현재 사각 영역에 완전히 포함되는지 조사한다.
BOOL Contains(Rect& rect);
BOOL Contains(INT x, INT y);
BOOL Intersect(Rect& c, const Rect& a, const Rect& b);	두 사각 영역의 교집합 영역을 구한다.
BOOL Intersect(const Rect& rect);
BOOL IntersectsWith(const Rect& rect) const;	두 사각 영역의 교집합이 있는지 조사한다.
BOOL IsEmptyArea(VOID) const;	빈 영역인지 조사한다.
BOOL Union(Rect& c, const Rect& a, const Rect& b);	두 사각 영역의 합집합 영역을 구한다.

대부분의 멤버 함수들은 GDI에도 이미 존재하는 것들이고 이 중 일부는 사용해 본 경험도 있을 것이다. 이 함수들에 대한 더 상세한 정보는 도움말에도 기록되어 있지만 그보다 더 확실하고도 쉬운 정보는 역시 헤더 파일(GdiplusTypes.h)에서 찾을 수 있다. C++ 언어에 익숙한 사람에게는 문서화된 설명보다 코드가 더 좋은 정보가 된다. 다음에 몇가지 멤버의 코드예이다.

BOOL IsEmptyArea() const

{

return (Width <= 0) || (Height <= 0);

}

BOOL Equals(IN const Rect & rect) const

{

return X == rect.X && Y == rect.Y &&

Width == rect.Width && Height == rect.Height;

}

BOOL Contains(IN INT x,IN INT y) const

{

return x >= X && x < X+Width && y >= Y && y < Y+Height;

}

VOID Inflate(IN INT dx,IN INT dy)

{

X -= dx;

Y -= dy;

Width += 2*dx;

Height += 2*dy;

}

코드를 읽는 것이 설명을 읽는 것보다 훨씬 더 빠르고 정학하게 함수의 동작을 이해하는 방법이다. 이 예에서 보다시피 모든 멤버 함수의 목록을 일일이 나열하면서 설명하는 것은 지면을 낭비하는 것 이상의 의미를 찾기 어렵다. 어차피 도움말이나 헤더 파일에서 얻을 수 있는 정보들이며 함수의 이름으로부터 동작의 90% 이상을 유추해낼 수 있다. 그래서 이후부터는 본문에서 함수의 중복 정의된 원형을 모두 설명한다든가 멤버 함수를 나열하는 비효율적인 방법을 자제하고 핵심적인 내용에 대해서만 다루기로 한다.

따라서 독자들은 본문에서 소개하지 않는 함수에 대해서도 도움말에서 적극적으로 찾아 활용하는 자세를 가져야 한다. 약간의 영어 독해 능력만 있으면 도움말에서 방대한 정보를 얻을 수 있으며 필요할 때 언제든지 참조할 수 있으므로 일일이 암기할 필요도 없는 셈이다. 사람이 기억해야 할 것을 최소화시키는 것이 바로 OOP의 목적 중 하나라고 할 수 있다. 현대의 라이브러리들은 사용자들이 조금이라도 필요를 느낄만한 함수들을 모두 제공한다고 보면 틀림 없으므로 필요할 때 검색해도 늦지 않다.