시스템/윈도우

문자열 테이블

cyanhe_wh 2019. 9. 12. 23:22
반응형

윈도우즈에서는 문자열들도 리소스의 일종으로 취급된다.

 

대량의 문자열을 사용하는 프로그램은 리소스에 문자열을 정의해 놓고 필요할 때마다 리소스의 문자열을 읽어와 사용한다.

 

[그림 1-1] 문자열 테이블 리소스

TCHAR *str = TEXT("String Test");

switch(iMessage)

{

case WM_PAINT:

    hdc = BeginPaint(hWnd, &ps);

    TextOut(hdc, 10, 10, str, lstrlen(str));

}

문자 배열 또는 문자형 포인터에 바로 문자열을 초기화하여 이 문자열을 화면으로 출력하면 그만이다.

물론 단순한 문자열 출력이 목적이라면 이런 방법이 더 편하겠지만 문자열 리소스는 여러 가지면에서 이점을 준다.

 

첫째로 문자열 자체가 코드와 분리됨으로써 문자열만 따로 관리할 수 있으며 프로젝트를 유지하는데 큰 도움을 준다.

이것은 매크로의 장점과 유사하다. 프로그램은 실행 중에 사용자가 조작을 잘못하면 에러 메시지를 보여주면 간단한 안내문이나 도움말을 출력하기도 하는데 이런 메시지 문자열들을 많을 경우 수백 개가 될 수도 있다. 이 많은 문자열들이 몽땅 소스코드에 다 들어가 있다면 정말 끔찍하다.

 

문자열들이 리소스로 분리되어 있다면 전문 디자이너가 메시지들을 한꺼번에 모아 작성할 수 있을 것이다.

많은 문자열을 다루는 대형 프로젝트에는 메시지만을 전문적으로 관리하는 사람도 따로 있다.

 

문자열을 리소스로 정의하면 일괄되게 관리할 수 있는 이점이 있고 수정하기도 편리하다.

만약 어떤 이유로 메시지들을 전부 수정해야 한다고 해 보자. 이때 코드의 여기저기에 박혀있는 메시지를 찾아 고치는 경우와 리소스 편집기에서 메시지를 일괄적으로 고치는 것 중 어떤 것이 더 빠르고 정확할 것인가는 쉽게 알 수 있다.

 

두 번째 이점은 다국어 버전을 쉽게 만들 수 있다는 점이다. 리소스는 조건에 따라 교체할 수 있기 때문에 경우에 따라 다른 문자열 집합을 사용할 수 있다. 논리를 다루는 코드와 무관한 데이터를 분리해 두었기 때문에 이런 것이 가능하다.

또한 문자열이 소스와 분리되어 있으면 문자열을 고쳐도 소스를 다시 컴파일할 필요가 없어 개발속도도 빨라진다.

 

여러 가지 장점이 있기 때문에 아주 간단한 문자열인 경우를 제외하고 좀 길다 싶은 문자열은 웬만하면 문자열 리소스로 만들어 쓰는 것이 좋다.

 

문자열이 필요할 때마다 버퍼를 준비하고 LoadString으로 읽어서 사용한다는 것은 분명 번거로운 일이다.

그러나 소스코드에 박힌 문자열을 일일이 찾아 고치는 것은 더 번거롭고 어렵다.

반응형

'시스템 > 윈도우' 카테고리의 다른 글

Distributed CommonObject Model 및 DCE-RPC의 천재와 공용  (0) 2021.01.13
Threading  (0) 2021.01.13