본문 바로가기
C & C++/C & C++

문자열 관련 자료형 정리

by izen8 2011. 4. 7.

문자열 관련 자료형 정리

 

 

LPSTR : char *

 

LPCSTR : const char *

 

LPCTSTR : const char * 또는 const WCHAR *


WORD : 보통 2바이트의 부호없는 정수형   (*.word형을 string형으로 바꾸기 string := IntToStr(word); )

 

DWORD : 4바이트의 부호없는 정수형    DWORD unsigned long

 

그럼, WORD와, int의 차이점은...

 

WORD는 4글자 int는 3글자
typedef unsigned short         WORD;    //WORD는 예약어가 아니죠  (typedef는 변수부분)

 

                                                                                               (cf.define은 전처리 부분)

 

*.단순참고

 

char, unsigned char, signed char : 1 byte
short, unsigned short : 2 bytes
int, unsigned int : 4 bytes
long, unsigned long : 4 bytes
float : 4 bytes
double : 8 bytes
long double : 10 bytes

 

=================================================================================


1. C 자료형
   char(1), short(2), int(4), long(4), float(4), double(8), bool
   문자: char

 


 

2. Win32 API 자료형


   BYTE(1, unsigned char), WORD(2, unsigned short), UINT(4, unsigned int)
   DWORD(4, unsigned long), LONG(4,long), BOOL
   문자: UCHAR(unsigned char)
   Handle: 대상을 구분하는 4바이트 정수(HWND,HDC...)
  
   MBCS문자(열)  유니코드문자(열)  자동매크로문자(열)
   ------------         -----------------        ------------------
   char   wchar_t    TCHAR
   LPSTR(char*)         LPWSTR(wchar_t*)         LPTSTR
   LPCSTR(const char*)  LPCWSTR(const wchar_t *) LPCTSTR
 
   .LPTSTR과 LPCTSTR를 사용하는 것이 좋음.
   .OLECHAR(wchar_t), LPOLESTR(LPWSTR), LPCOLESTR(LPCWSTR), OLESTR(x) = _T(x)



3. COM 스트링
   BSTR : 문자열 길이를 시작전에 저장하고, 이어서 유티코드문자열을 저장하는 방식
   LPCWSTR -> BSTR : 생성안됨. 생성함수를 이용해야 함.
                     BSTR bstr = sysAllocString(L"HELLO HI"); // 메모리 할당
                                 sysFreeString(bstr);         // 메모리 제거

 


   VARIANT: 문자열이 들어올때 BSTR과 동일

 

VARIANT 자료형은 각 개발 환경의 자료형의 차이를 해결하기위하여 제공되는 공용체 이다.

 

예제) INT nIndex 와 CString strItem이 있다고 가정하고...

 

// VARIANT 형 선언

 

VARIANT varIndex, varItem;

 

// VARIANT type 지정
varIndex.vt = VT_INT;
varItem.vt = VT_BSTR;

 

// VARIANT 값 할당.
varIndex.intVal = nIndex;
varItem.bstrVal = strItem.AllocSysString();// CString을 bstr로 변환하는 함수

 

// VARIANT 인자를 사용하여 함수 호출



 

 

4. CRT(c runtime library)지원 스트링 클래스 (#include "comdef.h")
   4-1. _bstr_t
        :BSTR 랩퍼 클래스, 메모리 할당/제거를 자동으로 수행
      
        . LPCSTR, LPCWSTR  -> _bstr_t
          :_bstr bstr = "hello hi";
        . _bstr_t -> LPCSTR, LPCWSTR
          : LPCSTR psz1 = (LPCSTR)bs1;
        . _bstr_t -> BSTR
          : 형변환 안됨. 함수이용
            BSTR bstr = bs1.copy();
            sysFreeString(bstr); // BSTR은 사용후 메모리 해제를 해야함.

 

   4-2. _variant_t
        :VARIANT 랩퍼 클래스, 메모리 할당/제거 자동 수행
       
        . LPCSTR, LPCWSTR -> _variant_t
          : _variant_t v1 = "hello hi";
        . _variant_t -> _bstr_t -> LPCSTR,LPCWSTR
          : LPCSTR psz1 = (LPCSTR)(_bstr_t)v1;



5. ATL 지원 스트링클래스


   5-1 CComBSTR : BSTR랩퍼클래스, 메모리할당/제거 자동 수행
      . LPCSTR, LPCWSTR -> CComBSTR
        CComBSTR bs1 = "hello hi";
      . CComBSTR -> BSTR -> LPCWSTR
        BSTR bs = (BSTR)bs1;
      . BSTR -> CComBSTR
        CComBSTR bs2; bs2.Attach(W2BSTR(L"hello hi");

 

   5-2 CComVariant: VARIANT랩퍼클래스, 메모리할당/제거 자동 수행
      . LPCSTR, LPCWSTR -> CComVariant
        CComVariant bs1 = "hello hi";
      . CComVariant -> CComBSTR -> BSTR -> LPCWSTR
        CComBSTR bs = bs1.bstrVal;


6. STL 스트링


   6-1 string
       . LPCSTR -> string
         string str = "hello hi";
       . string -> LPCSTR (형변환 안됨. 함수 이용)
         LPCSTR psz = str.c_str();
   6-2 wstring
       . LPCWSTR -> wstring
         wstring str = "hello hi";
       . wstring -> LPCWSTR
         LPCWSTR psz = str.c_str();


7. MFC 스트링


   . LPCSTR, LPCWSTR -> CString
     CString str = "hello hi";
   . CString -> LPCTSTR
     1. LPCTSTR lpsz = (LPCTSTR)str;
     2. LPTSTR lptsz = str.getBuffer(0), str.ReleaseBuffer(); (올바른 사용)
     3. LPTSTR lptsz = (LPTSTR)(LPCTSTR)str; (잘못된 표현)
     4. CString -> BSTR
        BSTR bstr = str.AllocSysString(); sysFreeString(bstr);


8. VC7 스트링


   String: .Net에서 새로 정의한 스트링 클래스
          String* s1 = S"hello hi";
          CString s2(s1);
    

 

9. ETC

 

   1. BSTR --> LPCSTR
      USES_CONVERSION;
      LPCSTR lpaszTemp = OLE2CA(bstrValue);

 

   2. LPCSTR --> BSTR
      USES_CONVERSION;
      BSTR bstrTemp = ::SysAllocString(A2COLE(lpaszValue));

 

   3. CString --> LPCSTR
      1) ANSI 버전
          LPCSTR lpaszTemp = (LPCSTR) strValue;
      2) UNICODE 버전
          USES_CONVERSION;
          LPCSTR lpaszTemp = T2CA((LPCTSTR) strValue);

 

   4. LPCSTR --> CString
      1) ANSI 버전
         CString strTemp = lpaszValue;
      2) UNICODE 버전
          USES_CONVERSION;
          CString strTemp = A2CT(lpaszValue);

 

--------------------------------------------------------------------------------

 

Windows Data Types

 

 

The data types supported by Microsoft® Windows® are used to define function return values, function and message parameters, and structure members. They define the size and meaning of these elements.

 

The following table contains the following types: character, integer, Boolean, pointer, and handle. The character, integer, and Boolean types are common to most C compilers. Most of the pointer-type names begin with a prefix of P or LP. Handles refer to a resource that has been loaded into memory. For more information about handling 64-bit integers, see Large Integers.

 

Data Types

 

 

 

Value Meaning
ATOM Atom. For more information, see Atoms.
BOOL Boolean variable (should be TRUE or FALSE).
BOOLEAN Boolean variable (should be TRUE or FALSE).
BYTE Byte (8 bits).
CALLBACK Calling convention for callback functions.
CHAR 8-bit Windows (ANSI) character. For more information, see Character Sets Used By Fonts.
COLORREF Red, green, blue (RGB) color value (32 bits). See COLORREF for information on this type.
CONST Variable whose value is to remain constant during execution.
CRITICAL_SECTION Critical-section object. For more information, see Critical Section Objects.
DWORD 32-bit unsigned integer.
DWORD_PTR Unsigned long type for pointer precision. Use when casting a pointer to a long type to perform pointer arithmetic. (Also commonly used for general 32-bit parameters that have been extended to 64 bits in 64-bit Windows. )
DWORD32 32-bit unsigned integer.
DWORD64 64-bit unsigned integer.
FLOAT Floating-point variable.
HACCEL Handle to an accelerator table.
HANDLE Handle to an object.
HBITMAP Handle to a bitmap .
HBRUSH Handle to a brush.
HCONV Handle to a dynamic data exchange (DDE) conversation.
HCONVLIST Handle to a DDE conversation list.
HCURSOR Handle to a cursor.
HDC Handle to a device context (DC).
HDDEDATA Handle to DDE data.
HDESK Handle to a desktop.
HDROP Handle to an internal drop structure.
HDWP Handle to a deferred window position structure.
HENHMETAFILE Handle to an enhanced metafile.
HFILE Handle to a file opened by OpenFile, not CreateFile.
HFONT Handle to a font.
HGDIOBJ Handle to a GDI object.
HGLOBAL Handle to a global memory block.
HHOOK Handle to a hook.
HICON Handle to an icon.
HIMAGELIST Handle to an image list.
HIMC Handle to input context.
HINSTANCE Handle to an instance.
HKEY Handle to a registry key.
HKL Input locale identifier.
HLOCAL Handle to a local memory block.
HMENU Handle to a menu.
HMETAFILE Handle to a metafile.
HMODULE Handle to a module. The value is the base address of the module.
HMONITOR Handle to a display monitor.
HPALETTE Handle to a palette.
HPEN Handle to a pen .
HRGN Handle to a region.
HRSRC Handle to a resource.
HSZ Handle to a DDE string.
HWINSTA Handle to a window station.
HWND Handle to a window.
INT 32-bit signed integer.
INT_PTR Signed integral type for pointer precision. Use when casting a pointer to an integer to perform pointer arithmetic.
INT32 32-bit signed integer.
INT64 64-bit signed integer.
LANGID Language identifier. For more information, see Locales.
LCID Locale identifier. For more information, see Locales.
LCTYPE Locale information type. For a list, see Locale and Language Information.
LONG 32-bit signed integer.
LONG_PTR Signed long type for pointer precision. Use when casting a pointer to a long to perform pointer arithmetic.
LONG32 32-bit signed integer.
LONG64 64-bit signed integer.
LONGLONG 64-bit signed integer.
LPARAM Message parameter.
LPBOOL Pointer to a BOOL.
LPBYTE Pointer to a BYTE.
LPCOLORREF Pointer to a COLORREF value.
LPCRITICAL_SECTION Pointer to a CRITICAL_SECTION.
LPCSTR Pointer to a constant null-terminated string of 8-bit Windows (ANSI) characters. For more information, see Character Sets Used By Fonts.
LPCTSTR An LPCWSTR if UNICODE is defined, an LPCTSTR otherwise.
LPCVOID Pointer to a constant of any type.
LPCWSTR Pointer to a constant null-terminated string of 16-bit Unicode characters. For more information, see Character Sets Used By Fonts.
LPDWORD Pointer to a DWORD.
LPHANDLE Pointer to a HANDLE.
LPINT Pointer to an INT.
LPLONG Pointer to a LONG.
LPSTR Pointer to a null-terminated string of 8-bit Windows (ANSI) characters. For more information, see Character Sets Used By Fonts.
LPTSTR An LPWSTR if UNICODE is defined, an LPSTR otherwise.
LPVOID Pointer to any type.
LPWORD Pointer to a WORD.
LPWSTR Pointer to a null-terminated string of 16-bit Unicode characters. For more information, see Character Sets Used By Fonts.
LRESULT Signed result of message processing.
LUID Locally unique identifier.
PBOOL Pointer to a BOOL.
PBOOLEAN Pointer to a BOOL.
PBYTE Pointer to a BYTE.
PCHAR Pointer to a CHAR.
PCRITICAL_SECTION Pointer to a CRITICAL_SECTION.
PCSTR Pointer to a constant null-terminated string of 8-bit Windows (ANSI) characters. For more information, see Character Sets Used By Fonts.
PCTSTR A PCWSTR if UNICODE is defined, a PCSTR otherwise.
PCWCH Pointer to a constant WCHAR.
PCWSTR Pointer to a constant null-terminated string of 16-bit Unicode characters. For more information, see Character Sets Used By Fonts .
PDWORD Pointer to a DWORD.
PFLOAT Pointer to a FLOAT.
PHANDLE Pointer to a HANDLE.
PHKEY Pointer to an HKEY.
PINT Pointer to an INT.
PLCID Pointer to an LCID.
PLONG Pointer to a LONG.
PLUID Pointer to a LUID.
POINTER_32 32-bit pointer. On a 32-bit system, this is a native pointer. On a 64-bit system, this is a truncated 64-bit pointer.
POINTER_64 64-bit pointer. On a 64-bit system, this is a native pointer. On a 32-bit system, this is a sign-extended 32-bit pointer.
PSHORT Pointer to a SHORT.
PSTR Pointer to a null-terminated string of 8-bit Windows (ANSI) characters. For more information, see Character Sets Used By Fonts.
PTBYTE Pointer to a TBYTE.
PTCHAR Pointer to a TCHAR.
PTSTR PWSTR if UNICODE is defined, a PSTR otherwise.
PTBYTE Pointer to a TBYTE.
PTCHAR Pointer to a TCHAR.
PTSTR A PWSTR if UNICODE is defined, a PSTR otherwise.
PUCHAR Pointer to a UCHAR.
PUINT Pointer to a UINT.
PULONG Pointer to a ULONG.
PUSHORT Pointer to a USHORT.
PVOID Pointer to any type.
PWCHAR Pointer to a WCHAR.
PWORD Pointer to a WORD.
PWSTR Pointer to a null-terminated string of 16-bit Unicode characters. For more information, see Character Sets Used By Fonts.
REGSAM Security access mask for registry key.
SC_HANDLE Handle to a service control manager database. For more information, see SCM Handles.
SC_LOCK Handle to a service control manager database lock. For more information, see SCM Handles.
SERVICE_STATUS_HANDLE Handle to a service status value. For more information, see SCM Handles.
SHORT Short integer (16 bits).
SIZE_T The maximum number of bytes to which a pointer can point. Use for a count that must span the full range of a pointer.
SSIZE_ T Signed SIZE_T.
TBYTE A WCHAR if UNICODE is defined, a CHAR otherwise.
TCHAR A WCHAR if UNICODE is defined, a CHAR otherwise.
UCHAR Unsigned CHAR.
UINT Unsigned INT.
UINT_PTR Unsigned INT_PTR.
UINT32 Unsigned INT32.
UINT64 Unsigned INT64.
ULONG Unsigned LONG.
ULONG_PTR Unsigned LONG_PTR.
ULONG32 Unsigned LONG32.
ULONG64 Unsigned LONG64.
ULONGLONG 64-bit unsigned integer.
UNSIGNED Unsigned attribute.
USHORT Unsigned SHORT.
VOID Any type.
WCHAR 16-bit Unicode character. For more information, see Character Sets Used By Fonts.
WINAPI Calling convention for system functions.
WORD 16-bit unsigned integer.
WPARAM Message parameter.

<!-- Info Task Footer -->

 

 

Platform SDK Release: February 2003


*.

 

기존 데이터형으로 조합이 가능한 형을 새로운 데이터형으로 선언하여 사용하는 이유는 단순히 편하게 사용하자는 의도만 있는 것은 아니다. 윈도우즈가 항상 IBM 컴퓨터에서만 실행되라는 법은 없으며 언젠가는 다른 시스템으로 이식될 가능성도 있을 수 있는데 그럴 경우 소스 차원의 호환성을 확보하기 위해 이런 데이터형을 사용한다. 알기 쉽게 예를 든다면 WORD형이 현재는 2바이트의 부호없는 정수형이지만 팬티엄 이후 686이나 786쯤에는 4바이트로 확장될지도 모른다. 설사 그렇더라도 소스는 수정할 필요없이 헤더 파일에서 WORD형의 형 정의만 바꾸어 주고 소스를 다시 컴파일하면 호환성에 문제가 없다.

 

 

문자열과 관련된 VC++의 데이터형을 정리해봤습니다.

 

LPSTR A 32-bit pointer to a character string.
ANSI C 스타일의 char * 와 같다. 단, LPSTR는 유니코드를 지원하지 않기 때문에 각각의 문자는 1바이트를 가진다.
LPCSTR A 32-bit pointer to a constant character string.
ANSI C 스타일의 const char * 와 같다. LPCSTR 역시 유니코드를 지원하지 않기 때문에 각각의 문자는 1바이트를 가진다.  
LPTSTR A 32-bit pointer to a character string that is portable for Unicode and DBCS.
유니코드를 지원하기 위한 문자열포인터인 TCHAR * 와 같다. LPTSTR은 유니코드를 지원하기 때문에 각 문자가 2바이트를 가지게 된다. 만약, 애플리케이션이 유니코드를 지원하지 않는 경우에는 LPSTR과 같게된다. 유니코드를 지원하는 프로그램을 작성할 경우에 사용한다.
LPCTSTR A 32-bit pointer to a constant character string that is portable for Unicode and DBCS.
유니코드를 지원하기 위한 문자열상수 포인터인 const TCHAR * 와 같다. LPTSTR은 유니코드를 지원하기 때문에 각 문자가 2바이트를 가지게 된다. 만약, 애플리케이션이 유니코드를 지원하지 않는 경우에는 LPSTR과 같게된다. 유니코드를 지원하는 프로그램을 작성할 경우에 사용한다.


====================================================================================

 

LPSTR ANSI 코드에서만 사용 가능하며, CHAR * 와 같다. CHAR = char 이므로 결국 LPSTR = char * 인 셈이다. 따라서, 1캐릭터는 1바이트를 차지함
LPCSTR ANSI 코드에서만 사용 가능하며, const CHAR *와 같다.  const 인점을 제외하곤 LPSTR과 같으므로, LPCSTR = const char * 인 셈이다.
LPTSTR ANSI와 UNICODE에서 모두 사용 가능. ANSI 코드에서는 LPSTR과 동일하므로 LPTSR = char *가 된다. 이 때, 1캐릭터는 1바이트를 차지한다. 한편, UNICODE로 구현될 경우 LPWSTR과 동일하며 LPWSTR = WCHAR * 이고 WCHAR는 unsigned short *와 같다. 따라서, LPTSTR = unsigned short *가 성립하며, 이 때 1캐릭터는 2바이트가 된다.
LPCTSTR CONST 인점을 제외하면 LPTSTR과 동일하다. 따라서, LPCTSTR = const unsigned short * 가 성립하므로 1캐릭터는 2바이트가 된다.

 

 

앞의 글에서 문자열을 나타내는 데이터형에는 다음과 같은 것이 있다고 정리했다.LPSTR = char *LPCSTR = const char *LPTSTR = tchar *LPCTSTR = const tchar *여기서 LP는 Long Pointer, C는 Constant, STR는 NULL로 끝나는 문자열을 의미한다. C에서 문자열 데이터의 경우 NULL로써 문자열의 종료를 알 수 있기 때문에 흔히 문자열을 스트링이라고도 한다.그러면, 위에서 T는 TCHAR를 의미하는데 도대체 TCHAR란 무슨 의미인가?문자를 표시할 때 흔히ASCII코드를 사용한다는 사실은 누구나 알 수 있다. ASCII 코드는 1바이트의 캐릭터 문자 테이블이다. 그렇다면, 한국어, 일본어, 중국어와 같이 영어가 아닌 문자는 어떻게 표시해야 할까? 일단 1바이트의 ASCII코드를 이용해서는 전세계의 다양한 문자를 표시할 방법이 없다. "1바이트 = 8비트"이기 때문에 현실적으로 256개의 캐릭터밖에 구현할수가 없기 때문이다.만약, 문자표시를 위해 2바이트를 사용하면 어떻게 될까? "2바이트 = 16비트"이므로 약 65,536개의 캐릭터표시가 가능하다. 따라서, 세계각국의 문자들은 2바이트의 코드를 통해 저마다의 캐릭터를 구별한다. 이러한 2바이트의 문자코드를 흔히 유니코드라고 부르는데, 이를 위해 등장한 데이터 형이 WCHAR타입이다. WCHAR는 기존의 CHAR타입보다 메모리는 2배를 차지하지만, 다양한 문자를 표현할 수 있는 장점이 있는 것이다.그렇다면, ASCII문자 'A'를 WCHAR타입과 혼용해서 사용한다고 가정해보자. 'A'는 ASCII 코드로서 1바이트지만, 다른문자는 2바이트를 구성하기 때문에 관리상 어려움이 있다. 그래서, WCHAR문자와 혼용시에는 'A'라는 ASCII문자도 2바이트로서 표현해야 할 필요가 생기게 되었는데, 그거이 바로 TCHAR타입인 것이다.즉, TCHAR는 ASCII코드의 WCHAR로의 변환툴인 셈이다.

ASCII코드를 TCHAR타입으로 사용하면, 문자열의 타입에 따라 WCHAR 또는 CHAR 으로 자동변환된다.TCHAR tch = _T('A');  ⇔  char ch = 'A';TCHAR tch = _T('B');  ⇔  wchar wch = 'B';여기서, 한가지 집고 넘어가볼 것이 있다. 도대체, 프로젝트(컴파일러)는 TCHAR가 CHAR타입인지 WCHAR인지 어떻게 구분하는 것일까? 정답은 간단하다. Project ⇒ Settings ⇒ C/C++ 탭의 Preprocession Definition항목에 "_UNICODE" 라고 정의를 해주면 컴파일러는 소스중의 TCHAR부분을 만나면 자동으로 WCHAR 타입으로 변환해준다.(참고 : 위의 _T()매크로는 _UNICODE 정의가 있는 경우 해당 캐릭터/스트링을 유니코드값으로 변환해주는 매크로이다. 만약, _UNICODE 정의가 없는 경우 _T()는 아무것도 하지 않는다.)

Unicode/MBCS(DBCS)/ANSI/TCHAR



1.요약 

각각의 차이점을 짧게 소개하고, 사용시 주의점을 살펴봅니다.

2.본문

 

문자열 세트를 나타내는 각각의 용어에는 다음과 같은 뜻이 있습니다.

[Unicode]

2바이트가 하나의 문자를 나타내며, 세계 각국의 언어를 동일한 코드로 표현할 수 있습니다. Windows NT/2000 운영체제는 내부적으로 Unicode를 사용하고 있습니다. 그렇기 때문에 API 호출시에 Unicode 를 사용한다면 보다 효율적입니다. C++에서는 wchar_t 타입을 사용합니다.

[MBCS/DBCS]

하나의 문자를 나타내기 위해서 한 바이트 이상이 사용됩니다. DBCS(Double Byte Character Set)는 한 바이트 혹은 두 바이트가 하나의 문자를 나타내는 MBCS(Multi Byte Character Set)의 특수한 경우입니다. C++ 에서는 unsigned char 타입을 사용합니다.( 보통은 char를 사용하는 것 같습니다 .

[ANSI]

한 바이트로 하나의 문자를 나타내는 코드입니다. C++ 에서는 char 타입을 사용합니다.

[TCHAR]

char 혹은 wchar_t가 될 수 있는 매크로 입니다. 

-----------------------------------------------------------------------------------

Unicode를 사용해서 프로그램을 작성하는 것은 다음과 같은 장단점이 있습니다. 

장점 - Windows NT/2000에서, 보다 효율적이다.

단점 - Windows 9X 에서 실행되지 않는다.

MBCS/ANSI를 사용해서 프로그램을 작성하는 것은 다음과 같은 장단점이 있습니다.

장점 - Windows 9X/NT/2000 에서 다 돌아간다.

단점 - Windows NT/2000 에서, 보다 비효율적이다.

------------------------------------------------------------------------------------
즉, 상황에 맞는 선택이 필요한 것인데, 그렇다고 상황이 변할때 마다 코드를 재작성 할 수는 없는 일이기에 TCHAR 라는 매크로를 사용하기에 이르렀습니다.

TCHAR는 평소에는 char로 활약하다가 유사시에는 wchar_t가 되는 매크로입니다. 관련된 내용은 훌륭한 서적/참고 자료가 많이 있으므로 생략하고 간단한 참고 자료를 제시하겠습니다. 

------------------------------------------------------------------------------------

 

프로젝트에서 UNICODE 혹은 _UNICODE라는 심볼이 미리 정의되는 경우 TCHAR는 wchar_t로 돌변합니다. 물론 이는 아주 단적인 예이고, 올바르게 표현하자면 다음과 같이 될 것입니다. 

UNICODE 가 미리 정의된 경우 winnt.h에서 다음의 매크로는 화살표에 이끌려 다음과 같이 정의됩니다.

TCHAR --> wchar_t

TEXT,__TEXT --> L

_UNICODE가 미리 정의된 경우 tchar.h에서 다음의 매크로는 화살표에 이끌려 다음과 같이 정의됩니다.

TCHAR --> wchar_t

_T,__T,_Text --> L 

쉽게 얘기해서 UNICODE는 SDK에서 쓰는 것이고 _UNICODE는 CRT에서 사용하는 것입니다. 우리가 알아야 할 것은 두 가지 모두 정의해야 한다는 점입니다. 

------------------------------------------------------------------------------------

_MBCS가 미리 정의된 경우 다음의 매크로는 화살표에 이끌려 다음과 같이 정의됩니다.

 

TCHAR --> char

_T,__TEXT --> 사라짐

위에서 언급한 무엇도 정의되지 않은 경우 다음의 매크로는 화살표에 이끌려 다음과 같이 정의됩니다.

TCHAR --> char

_T, __TEXT --> 사라짐

------------------------------------------------------------------------------------

 

물론 위의 내용은 타입이나 리터럴의 경우만 언급한 것이고, 함수들 예를 들어, _tcscat 이 _strcat 또는 wcscat 또는 _mbscat 등으로 바뀌는 일도 발생합니다.

 

문자열(스트링) 전격 분석1강

본강좌는 코드 프로젝트에 제가 좋아하는 프로그래머인 Michael Dunn의 강좌 The Complete Guide to C++ Strings, Part I 과 II 를 번역한 글입니다. 최대한 의역을 하려고 노력했지만, 이런쪽의 경험이 부족하다 보니 많이 모자란 강좌가 되겠지만, 많은 도움이 되셨으면 합니다. 기타 문의 사항이나 질문은 쪽지나 메일을 이용해 주셨으면 합니다. 본강좌는 제 홈페이지(위의 링크)를 통해서도 보실수 있습니다.

사실 이글은 Part I/II 두 강의로 구성이 되있지만 제 역량이 모자라는 관계로 더 잘게 쪼개 여러강좌로 재구성하겠습니다.
　

소개

프로그래밍 작업을 하면서 TCHAR, std::string, BSTR등과 같은 많은 문자열관련 데이터 타입을 보셨을 겁니다. 또한 _tcs로 시작하는 마크로들도 많이 보셨을 겁니다. 아마 특히 초보분들은 많이들 어려워 하셨을겁니다. 이 강좌는 각각의 문자열 타입을 정리해 보고, 각각의 목적을 소개할 겁니다. 더 나아가 간단한 사용법과 각각의 데이터 타입으로 어떻게 변환할수 있는지도 살펴보겠습니다.

먼저 세가지 종류의 케릭터 인코딩 타입에 대해 구체적으로 알아 보겠습니다. 여러분들은 그 각각의 문자열들이 내부적으로 어떻게 처리되는지 반드시 알아야 할것입니다. 스트링은 캐릭터들의 배열이라는 사실을 이미 알고 계실지라고, 이번강좌는 여러분께 도움이 많이 될것입니다. 또한 이번 강좌를 통해 스트링과 관련된 많은 자료구조(클래스, 구조체)에 대해서도 더 확실히 아시게 될겁니다.

그다음, 스트링 클래스들에 대해 다룰것입니다. 언제 어떤 클래스를 쓰는게 좋은지, 또 각각 어떻게 변환할수 있는지 살펴 볼것입니다.

캐릭터들의 기본 - ASCII, DBCS, Unicode

모든 스트링 클래스들은 사실상 그 근간을 C-스타일 스트링에 두고 있습니다. 다들 아시다 시피 C-스타일 스트링은 캐릭터의 배열로 구성되어 있습니다. 그럼 먼저 캐릭터 타입에 대해 다루도록 하겠습니다. 현재 우리가 쓰고있는 인코딩방법에는 세가지가 있습니다. 그 중 첫째로 single-byte character set, 혹은 SBCS 는 모든 케릭터가 정확히 한바이트를 차지합니다. C의 데이타 타입인 char형을 생각하시면 됩니다. 많이들 알고계실 ASCII 는 SBCS의 가장 대표적인 예입니다. 제로 바이트 즉 '\0' 값이 마지막에 반드시 존재하며, 그것은 문자열의 끝을 나타내게 냅니다.

둘째로는 multi-byte character set, 혹은 MBCS를 들수 있겠습니다. MBCS는 2바이트가 필요한 캐릭터(한글, 일본어, 중국어같은것들)은 2바이트로 1바이트만 써도 되는것들(영어 같은것들)은 1바이트로 표현을 합니다. 사실상 3바이트가 필요한 문자열은 3바이트로 표현을 하겠지만, 그런 문자열들이 지구상에 현재 없죠? 아마도. 윈도우즈에서는 single-byte characters 와 double-byte characters 이렇게 두가지 MBCS 인코딩방식이 쓰입니다. 따라서 윈도우즈에서 지원하는 가장긴 바이트의 캐릭터는 2바이트가 됩니다. 그래서 MBCS는 종종 double-byte character set, 혹은 DBCS 와 같은 의미로 사용되기도 합니다.

DBCS 인코딩방식에서는, 어떤 특정한 값이 2바이트인지를 나타내게 됩니다. 왜냐하면 어떻 케릭터가 1바이트인지 2바이트인지를 구별할수 있는 방법이 필요하기 때문입니다. 예를 들면 Shift-JIS 인코딩에서는 (일본에서 가장 많이 사용되는 인코딩 방식) 0x81-0x9F 와 0xE0-0xFC 사이의 값은 캐릭터가 2바이트라는것을 나타냅니다. 이런 값들을 "lead bytes" 라고 부르고 그 값은 항상 0x7F 보다 큽니다. "lead bytes" 다음에 나오는 바이트는 "trail byte"라고 부릅니다.DBCS에서는 trail byte는 0이 아닌 어떤값을 가질 수 있습니다. SBCS에서와 같이 DBCS방식에서도 '\0' 값을 가지는 한 바이트가 문자열의 마지막을 나타냅니다.

마지막은 Unicode 입니다. Unicode는 모든 캐릭터를 2바이트로 나타내자는 표준 인코딩방식입니다. 유니코드 캐릭터는 종종 wide characters라고도 불리는데요, 이는 1바이트 캐릭터들 즉, SBCS방식보다 더 많은(넓은) 공간을 차지하기 때문입니다. 유니코드는 MBCS와는 다르다는것을 주의 하세요. 가장 큰 차이점을 MBCS방식에서는 한 캐릭터가 1바이트 일수도 2바이트일수도 심지어 3바이트일수도 있습니다. 하지만 유니코드에서는 모든 캐릭터들이 2바이트를 차지하게 됩니다. 또하나의 차이점은 유니코드는 MBCS, SBCS에서와는 다르게 문자열의 끝은 "\0\0" 이런식으로 제로바이트 두개로 표시합니다.

SBCS는 주로 서유럽언어, 대표적으로 영어, 에서 주로 사용됩니고 ASCII표준으로 정의되어있습니다. MBCS는 동아시아 중동지역 언어를 나타내기위해 주로 사용됩니다. (한국, 일본, 중국이 대표적이죠) 유니코드는 COM과 윈도우즈NT에서 내부적으로 사용하고 있습니다.

아마 여러분들은 SBCS 즉, single-byte 캐릭터에는 이미 익숙하실 겁니다. char 타입으로 영문을 사용하실때 이미 여러분은 SBCS를 사용하고 계신겁니다. char타입으로 한글을 사용하신다면 Double-byte 타입 즉, DBCS를 사용하시는 겁니다. 하지만 그와는 다르게 유니코드에서는 wchar_t 타입을 사용합니다. 유니코드 문자열은 C/C++에서 L이라는 문자로 SBCS나 MBCS와는 다르다는 것을 표시해 줍니다.

  wchar_t  wch = L'1';      // 2 bytes, 0x0031

  wchar_t* wsz = L"Hello";  // 12 bytes, 6 wide characters

캐릭터들이 메모리에 저장되는 방식

1바이트 스트링은 차례차례 1바이트씩 저장이 됩니다. 마지막은 제로바이트 '\0'으로 문자열의 끝을 말해줍니다. 따라서 예를 들어보면"Bob" 이라는 문자열은 이와 같은 방식으로 저장됩니다.

 42  6F  62  00
B o b 문자열의 끝

유니코드 방식에서, L"Bob"은 이렇게 저장이 됩니다.

 42 00  6F 00  62 00  00 00
B o b 문자열끝 두개의 제로 바이트

위에서 보시다 시피 캐릭터 0x0000 이 문자열 끝을 나타냅니다.

DBCS 스트링은 겉보기에 SBCS방식과 흡사하지만 그 차이점이 있습니다. 그에 대해서는 뒤로 미루기로 하죠. 문자열 "스트링" 은 아래와 같은 방식으로 저장됩니다.(여기서 LB는 Lead Byte 그리고 TB는 Trail Byte를 뜻합니다.):

 93 FA  96 7B  8C EA  00
 LB TB  LB TB  LB TB  EOS
스 트 링  문자열 끝

"스"라는 캐릭터는 WORD 값 0xFA93 이런식으로 생각하시면 안됩니다. 두 개의 1바이트값 93 과 FA 의 순서로 "스"라는 캐릭터를 나타내는 겁니다. 따라서 intel계열이 아닌 big-endian 방식이 CPU에서도 그 순서는 같습니다.

스트링 처리함수의 사용

strcpy(), sprintf(), atol()등과 같은 C문자열 처리함수들은 이미 많이 보셨을 겁니다. 중요한 점은 이러한 함수들은 반드시 1바이트 스트링에서만 사용되어져야 한다는 겁니다. 표준라이브러리는 또한가지의 다른 함수셋을 가지고 있습니다. 이 함수들은 유니코드 용인데요, wcscpy(), swprintf(), _wtol() 등의 함수들이 있습니다. 대략 함수중간에 자주보이는 w 는 유니코드를 뜻하죠, wider 캐릭터에서 w를 땃겠죠?MS는 또한 DBCS를 지원하는 표준라이브러리를 추가했습니다. strXXX()류의 함수는 _mbsXXX()의 함수와 대응됩니다. 만약 여러분의 프로그램이 2바이트 언어권에서 사용된다면 반드시 _mbs로 시작하는 문자열 함수를 사용해야 합니다. 사실 우리 한국사람은 반드시 _mbs류의 함수를 쓰는게 정신건강에 좋겠죠? 왜냐, _mbs함수는 SBCS방식의 문자열도 정확히 처리해 주기 때문입니다. 왜냐하면 MBCS방식에서는 1바이트 캐릭터도 존재하기 때문에 SBCS방식의 문자열이 정확히 처리될수 있는겁니다.

그럼 전형적인 유니코드 스트링을 보면서 왜 여러종류의 스트링 처리함수들이 필요한지 얘기해보겠습니다. 전에 살펴보았던 유니코드 스트링 L"Bob" 입니다.

 42 00  6F 00  62 00  00 00
B o b EOS

만약 위의 문자열을 strlen() 함수에 사용하면 어떤 문제가 있을까요? strlen()함수에서는 처음 42값을 가지는 한바이트를 읽고 그 다음 00값의 한바이트를 읽겠죠? 하지만 이 00값의 바이트는 문자열의 끝을 나타냅니다. 따라서 리턴값은 1을 돌려줄 겁니다. 분명 잘못된 결과죠? 음. 반대의 상황은 더욱 치명적입니다. "Bob" 이라는 SBCS방식의 문자열을 wcslen() 함수(유니코드용)에 넘겨준다고 생각해 봅시다. "Bob"는 메모리에 42 6F 62 00 이렇게 저장이 됩니다. 하지만 wcslen() 함수에서는 두바이트씩 읽어 가면서 "0000"이렇게 두바이트가 모두 0인 값을 찾아값니다. "Bob"에 경우 먼저 42 6F를 읽겠죠? 그다음 62 00 을 읽을 것이고 이런식으로 00 00을 찾을때까지 여기저기 들쑤시면서 찾아 나갈 겁니다. 예상과 다른 결과가 나올것은 자명하죠.

strxxx() 와 wcsxxx() 통해 스트링처리함수들에 대해 간략히 얘기해 보았습니다. 그럼 strxxx() 와 _mbsxxx() 의 경우는 어떠할가요? 이 둘의 차이도 정말 중요합니다. 반드시 적절한 방식으로 사용되어 져야 합니다. 이에 대해서는 뒤에서 다루기로 하겠습니다.문자열(스트링) 전격 분석 2강

스트링을 조작하기^^

우리는 처음 C를 배울때 부터 SBCS 스트링을 사용하는데 익숙해져 있습니다. strlen() 같은 함수는 아마 처음 C공부하실때 누구나 써보셨을 것이고 아직도 쓰시고 계실겁니다. 또한 초보티를 막 벗을때 char* 타입을 이용해 ++, -- 연산자를 이용해 가면서 문자열 조작들을 해봤을겁니다. 또한 [] 식의 배열표현법으로 캐릭터 하나씩 값을 얻어오는 것에도 이미 익숙하실 겁니다. 이런 일련의 작업들은 SBCS 나 Unicode 스트링에서는 훌륭하게 작동합니다. 왜냐하면 모든캐릭터는 같은 길이이기 때문입니다. SBCS에서는 1바이트 유니코드에서는 2바이트 이기 때문이죠.

하지만, 우리는 DBCS 즉, 2바이트이상의 캐릭터들을 사용하게 된다면 이런 습관들을 반드시 버려야 합니다. 만약 DBCS 스트링을 쓸때에는 반드시 따라야 할 두가지의 룰이 있습니다. 이 룰을 어기면 야근이 버그 잡느라 좋아하는 드라마도 못보시고, 야근 하랴, 머리 빠지랴 고생들이 많으실 겁니다. ^^ (너무 장황하게 늘어놓았네요)

첫째, Lead Byte를 채크해지 않을거면 절대 ++ 포인터 연산을 하지말것

둘째. 절대 절대 -- 포인터 연산을 하지 말것

먼저 두번째 룰을 설명하겠습니다. 왜냐하면 설명하기 쉽기때문에^^. 여러분이 설정화일을 사용하는 프로그램을 작성한다고 가정합시다. 실행하면 그 프로그램은 그 설정파일을 읽어서 작업하겟죠? 만약 프로그램의 경로가 

C:\Program Files\MyCoolApp이고, 설정파일은 C:\Program Files\MyCoolApp\config.bin 

에 있습니다.

그럼 설정파일의 경로를 얻어오는 함수를 이렇게 작성했다고 가정합니다.

bool GetConfigFileName ( char* pszName, size_t nBuffSize )
{
char szConfigFilename[MAX_PATH];


    // 인스톨된 디렉토리를 얻어온다.
    // .....
 
    // 만약 마지막 캐릭터가 백슬래시가 아니면 추가해 준다.
    // 우선 마지막 캐릭터를 구한다.
    char* pLastChar = strchr ( szConfigFilename, '\0' );


    // *** 자 한칸 앞으로 가자 ***
    pLastChar--;  
 
    // 백 슬래시 추가
    if ( *pLastChar != '\\' )
        strcat ( szConfigFilename, "\\" );


    // 설정파일 디렉토리 끝에 화일명 추가
    strcat ( szConfigFilename, "config.bin" );


    // 리턴
    if ( strlen ( szConfigFilename ) >= nBuffSize )
        return false;
    else
        {
        strcpy ( pszName, szConfigFilename );
        return true;
        }
}

이 루틴은 잘짜여졌습니다. 그러나 특정한 DBCS캐릭터에서는 제대로 작동하지 않을 것입니다. 이유는 다음과 같습니다. 만약 디렉토리 이름이 "C:\디렉토리" 와 같다고 가정해 보면. 그 메모리 구조는 다음과 같게 됩니다. :

 43  3A  5C  83 88  83 45  83 52  83 5C  00
　 　 　  LB TB  LB TB  LB TB  LB TB 　
 C  :  \ 디 렉 토 리  EOS

GetConfigFileName() 

함수가 마지막 백슬래시를 확인할때 마지막 0이 아닌 바이트를 확인하는걸 볼수가 있으실 겁니다. (--포인터 연산으로) 그리고 같이 '\\' 인지 == 연산자로 확인했지만 결과적으로는 이 루틴은 잘못된 결과를 리턴합니다.

그럼 무엇이 잘못 되었을가요? 위의 메모리 구조에서 파란색으로 표시한 두 바이트를 살펴보면 백슬래시의 값은 0x5C이고 '리'의 값은 83 5C 입니다. (무언가 눈치 채셨겠죠?.. ^^) 위의 루틴은 '리'의 TB즉 Trail Byte만을 읽고 '\\'와 같은 같으로 간주해 버리게 됩니다.

위의 코드를 수정하려면 --포인터 연산을 제거하고 그에 상응하는 DBCS를 지원하는 함수로 대체 하는 것입니다. 수정한 코드는 아래와 같습니다. :

bool FixedGetConfigFileName ( char* pszName, size_t nBuffSize )
{
    char szConfigFilename[MAX_PATH];


    char* pLastChar = _mbschr ( szConfigFilename, '\0' );


    // 자 이제 제대로 된다.
    // 이전 캐릭터로 이동한다. 이것은 1바이트 일수도 있고
    // 2바이트 일수도 있다.
    pLastChar = CharPrev ( szConfigFilename, pLastChar );


    if ( *pLastChar != '\\' )
        _mbscat ( szConfigFilename, "\\" );


    _mbscat ( szConfigFilename, "config.bin" );
 
    if ( _mbslen ( szInstallDir ) >= nBuffSize )
        return false;
    else
        {
        _mbscpy ( pszName, szConfigFilename );
        return true;
        }
}

위의 수정된 루틴은 한 캐릭터 전으로 가기 위해 

CharPrev() API 함수를 이용했습니다. 그 한 캐릭터는 위의 예에서와 같이 2바이트를 차지할 수도 있고, 1바이트 일수도 있으나, CharPrev() 

함수는 이를 스스로 확인하고 제대로 작동할 것입니다. 따라서 위의 함수는 제대로된 결과 값을 리턴할 것입니다..

이제, 여러분은 위의 1번 규칙을 깨게 될때 일어나는 부작용도 쉽게 생각하실수 있으실 겁니다. 예를 들어, 여러분이 유저가 입력한 파일경로에서 캐릭터 ':' 가 중복되서 나타나는지 아닌지를 확인하는 루틴을 짠다고 생각해 보겠습니다. 그 루틴에서 만약 CharNext() API 함수 대신에 ++ 포인터 연산을 사용하셨다면 잘못된 결과를 초래할 것입니다. 특히 2바이트를 차지하는 한글 한 글자의 Trail Byte가 ':' 와 같게 되는 경우는 100% 잘못된 연산을 하게 될겁니다.

위에서 말한 2번 규칙에 하나를 더하자면:

2a. 절대로 배열 인덱스에 마이너스 연산을 하지 말자.

아래의 코드는 2번 규칙의 예와 굉장히 흡사합니다. 예로, 

pLastChar 

값이 이런식으로 할당되었다면 :

char* pLastChar = &szConfigFilename [strlen(szConfigFilename) - 1];

이 루틴의 결과는 위의 설명드린 --포인터 연산의 부작용예와 똑같은 상황이 벌어집니다. 왜냐 사실 배열 인덱스의 연산도 내부적으로는 포인터 연산으로 처리가 되기 때문이죠.. 헥헥, 꽤나 장황하게 설명된 파트지만 실지 내용은 간단하죠?

다시 strxxx() 와 _mbsxxx() 함수로 돌아가서

이제는 왜 

_mbsxxx() 함수시리즈가 필요한지 느끼실 겁니다. strxxx() 계열의 함수는 _mbsxxx() 함수시리즈와는 다르게 DBCS에 대해 전혀 알지 못합니다. 만약 strrchr("C:\\디렉토리", '\\') 이런식으로 호출을 하셨다면 그 결과같은 잘못된 값일겁니다. 반면 _mbsrchr() 

함수는 마지막의 2바이트 캐릭터를 제대로 인식하고 제대로된 리턴값을 넘겨줄겁니다.

마지막으로 한가지 추가하자면 문자열 길이를 매개변수로 받거나 리턴하는 함수들에는 주의 하실 필요가 있습니다. strlen("스트링") 의 함수는 6을 리턴할 것입니다. 하지만 유니코드 함수 wcslen(L"스트링") 이건 3을 리턴할 겁니다. 주의하게요^^.

Win32 API에서의 MBCS 와 Unicode

두 종류의 API들

아마 눈치 채셨을지도 모르고, 아닐지도 모르지만, 모든 문자열을 다루는 API들은 두 종류로 이루어져 있습니다. 한가지 버젼은 MBCS를 다루고 다른 하나는 유니코드를 다룹니다. 예로, 실제로는 

SetWindowText() 라는 함수는 없습니다. 대신 SetWindowTextA() 와 SetWindowTextW() 

라는 두종류의 API가 실제로 존재하는 겁니다. 마지막의 A는 (ANSI의 약어쯤)은 MBCS로 처리하는 함수를 뜻하고, W는 유니코드 버젼을 뜻합니다.

여러분이 프로그램을 빌드 하실때 여러분은 MBCS냐 혹은 유니코드냐를 선택하실 수 있습니다. 만약 VC에서 셋팅을 건드리지 않으셨다면 기본적으로는 MBCS방식으로 빌드될겁니다. 그럼 어떻게 정의되지도 않은 SetWindowText() 라는 함수를 쓸수 있느냐 궁금하시겠죠? winuser.h 헤더파일을 살펴보시면 다음과 같은 일련의 #define문들을 보실 수 있으실 겁니다.:

BOOL WINAPI SetWindowTextA ( HWND hWnd, LPCSTR lpString );
BOOL WINAPI SetWindowTextW ( HWND hWnd, LPCWSTR lpString );


#ifdef UNICODE
#define SetWindowText  SetWindowTextW
#else
#define SetWindowText  SetWindowTextA
#endif

MBCS로 빌드 할때에는 UNICODE 가 정의되 있지 않습니다. 따라서 전처리기는 다음으로 해석하게 됩니다.:

#define SetWindowText  SetWindowTextA

따라서 전처리기는 모든 

SetWindowText() 라는 문자를 SetWindowTextA() 

라고 바꾸게 됩니다. 실제로 SetWindowText() 라는 매크로로 정의된 다른이름의 함수대신 SetWindowTextA 혹은 W 로 끝나는 함수를 쓰실수 있습니다. 물론 그럴일은 거의 없겠지만요..

그럼 기본값으로 유니코드를 사용하는 함수로 싸그리 바꾸고 싶으시다면, VC설정의 preprocessor settings에서 

_MBCS 값을 list of predefined symbols에서 제거해 주시고 UNICODE 와 _UNICODE

를 넣어주시면 끝납니다. 주의하실 것은 두개의 값을 모두 적어주셔야 합니다. 어떤해더는 UNICODE라는 것만 사용하고 어떤건 _UNICODE를 사용하기 때문입니다. 그렇지만, 유니코드를 사용하실때 주의 하실게 있습니다. 다음 코드를 살펴보죠:

HWND hwnd = GetSomeWindowHandle();
char szNewText[] = "we love Bob!";


    SetWindowText ( hwnd, szNewText );

위 코드는 전처리기가 "SetWindowText"를 "SetWindowTextW"로 바꾼후에는 다음과 같습니다.:

HWND hwnd = GetSomeWindowHandle();
char szNewText[] = "we love Bob!";


    SetWindowTextW ( hwnd, szNewText );

무엇이 잘못되었는지 아시겠나요? 여기서 우리는 유니코드를 취하는 함수에 SBCS 즉 1바이트 케릭터를 전달했습니다. 즉 제대로된 결과를 기대할수 없겠죠? 그 첫번째 해결방법은 모든 스트링에 #define문으로 아래와 같이 정의 하는것입니다.:

HWND hwnd = GetSomeWindowHandle();
#ifdef UNICODE
wchar_t szNewText[] = L"we love Bob!";
#else
char szNewText[] = "we love Bob!";
#endif


    SetWindowText ( hwnd, szNewText );

아마 모든 스트링을 이런식으로 정의하다가는 미쳐 버릴겁니다. 다른 직종을 알아보시겠죠? 여기에 대한 진정한 해결책은 

TCHAR 

입니다.

고맙다 TCHAR!

TCHAR MBCS

에서건 유니코드에서건 똑같은 코드를 사용할수 있게하는 캐릭터 타입입니다. 바로 위에서 본 #define 문들의 해결방식을 이미 MS에서는 정의해 TCHAR 라는 방식으로 정의해 놓았습니다. 아래와 같습니다.:

#ifdef UNICODE
typedef wchar_t TCHAR;
#else
typedef char TCHAR;
#endif

따라서 

TCHAR 는 MBCS로 빌드할때는 char 이고, 유니코드로 빌드할때는 wchar_t 타입이 됩니다. 또한 유니코드 스트링앞에 추가해 주는 L이라는 문자를 위해 _T() 

라는 마크로도 있습니다.:

#ifdef UNICODE
#define _T(x) L##x
#else
#define _T(x) x
#endif

## 는 두개의 문자열들을 하나의 문자열로 만들어 주는 전처리기 연산자 입니다. 여러분은 이 글을 보고 나면 이제 스트링을 선언 할때면 언제든지 

_T 

마크로를 사용하셔야 합니다. 이 마크로는 유니코드 문자열 앞에는 L문자를 추가해 줍니다.

TCHAR szNewText[] = _T("we love Bob!");

SetWindowTextA/W 를 편하게 왔다갔다 할수 있게 해주는 정의들이 있는것 처럼, strxxx() 과 _mbsxxx() 류의 스트링 처리 함수들 사이를 편하게 변경시킬수 있는 정의 들도 있습니다. 예를 들면, 여러분은 _tcsrchr 마크로를 strrchr() 이나 _mbsrchr() 혹은 wcsrchr()를 쓰는 대신 쓰실수 있습니다. _tcsrchr 함수는 SetWindowText 

함수가 그러하듯 MBCS환경이냐 혹은 유니코드 환경이냐에 따라서 적절히 치환될 것입니다.

TCHAR 를 취하는 함수는 비단 strxxx() 계열의 함수만은 아닙니다. 예를 들면 _stprintf (sprintf() 와 swprintf()를 치환) 이나 _tfopen (fopen() 과 _wfopen()

를 치환)과 같은 함수들도 있습니다. 이와 관련된 함수들의 전체 리스트는 MSDN의 "Generic-Text Routine Mappings" 부분을 참고하시기 바랍니다.

문자열 그리고 TCHAR 타입들

타입 MBCS환경에서 유니코드 환경에서
WCHAR wchar_t wchar_t
LPSTR 0으로 끝나는 char형의 문자열(char*) 0으로 끝나는 char형의 문자열 (char*)
LPCSTR 0으로 끝나는 const char형의 문자열 (const char*) 0으로 끝나는 const char형의 문자열 (const char*) 
LPWSTR 0으로 끝나는 유니코드형의 문자열 (wchar_t*) 0으로 끝나는 유니코드형의 문자열 (wchar_t*)
LPCWSTR 0으로 끝나는 const 유니코드형의 문자열 (const wchar_t*) 0으로 끝나는 const 유니코드형의 문자열 (const wchar_t*) 
TCHAR char wchar_t
LPTSTR 0으로 끝나는 TCHAR형의 문자열 (TCHAR* -> char*)  0으로 끝나는 TCHAR형의 문자열 (TCHAR*->wchar_t*)
LPCTSTR 0으로 끝나는 const TCHAR형의 문자열 (const TCHAR*) 0으로 끝나는 const TCHAR형의 문자열 (const TCHAR*)

　

언제 TCHAR 와 유니코드를 사용할 것인가

이제 여러분은 유니코드 없이도 잘 살아 왔는데 왜 유니코드를 사용하여야 하는가 의문이 들 것입니다. 유니코드 방식을 쓰면 득이 될 경우는 세가지가 되겠습니다.:

  1. 프로그램이 오직 Windows NT 환경에서만 돌아간다.
  2. 프로그램이 MAX_PATH 보다 긴 파일명의 문자열을 사용한다.
  3. 프로그램이 Window XP등에서 소개된 오직 유니코드만 받는 함수를 사용한다.

대부분의 유니코드함수는 Windows 9x시리즈에는 구현되 있지 않습니다. 프로그램이 9x시리즈에서도 돌아가야 한다면 유니코드는 좋은 선택이 아닐겁니다. (Microsoft Layer for Unicode 라는 9x에서도 유니코드를 지원하는 라이브러리가 있긴 합니다.) 그렇지만, NT는 내부적으로는 모두 유니코드를 사용하기 때문에 유니코드 API가 아마 약간의 성능향상에 도움이 될것입니다. MBCS방식의 스트링을 NT환경에서 사용하면 운영체제는 내부적으로 그 스트링을 유니코드로 변환한 다음 그에 상응하는 유니코드 함수를 호출할 것입니다. 결과가 리턴되면 다시 MBCS방식으로 전환한 다음 리턴해 줄것입니다. 이 절차는 상당히 최적화 되있겠지만, 아마 유니코드를 직접쓸때보다는 성능의 아주 약간일지도 모르지만 감소는 피할수 없을 겁니다.

NT는 또한 아주 긴 파일명을 지원합니다. (

MAX_PATH 

보다 긴 파일명) 그러나 유니코드가 쓰일 때만 입니다. 하지만 무엇보다도 가장 큰 장점은 모든 언어 예를 들면 중국어, 영어 , 일어, 한국어 를 똑같은 방식으로 처리해 줄수 있다는 것일 겁니다.

마지막으로, Windows 9x 시리즈를 마지막으로 MS는 MBCS API방식을 멀리하고 유니코드 방식으로 전향하고 있습니다.  예를들면, 

SetWindowTheme() 

이라는 API 함수는 오직 유니코드 스트링 만을 받습니다. 상응하는 MBCS버젼이 없습니다. 유니코드만을 사용하는 것은 이제 유니코드와 MBCS사이의 왔다갔다 해야하는 귀찮음을 얻에 줄겁니다.^^

그리고 지금 당장 유니코드를 사용하지 않으실 지라고, 여러분은 반드시 

TCHAR 

와 그와 관련된 함수들을 써주셔야 미래를 위해 좋으실 겁니다. DBCS를 보다 안전하게 사용하는것 못지않게 나중에 유니코드로 프로그램을 바꾸실때 단지 셋팅하나 바꿔주면 만사 오케이 이기 때문이죠^^

 

문자열(스트링) 전격 분석 2부 1강

본강좌는 코드 프로젝트에 제가 좋아하는 프로그래머인 Michael Dunn의 강좌
The Complete Guide to C++ Strings, Part I 과 II 를 번역한 글입니다.
최대한 의역을 하려고 노력했지만, 이런쪽의 경험이 부족하다 보니 많이 모자란
강좌가 되겠지만, 많은 도움이 되셨으면 합니다.
기타 문의 사항이나 질문은 쪽지나 메일을 이용해 주셨으면 합니다.
본강좌는 제 홈페이지(위의 링크)를 통해서도 보실수 있습니다.

이번강 까지도 좀 지루하겠네요.
다음강을 마지막으로 실제 클래스들을 다루어 보겠습니다.

소개

C스타일 스트링은 에러를 유발하기 쉽고, 관리하기가 매우 까다로울뿐만 아니라, 해커에게 오버런 버그를 노출하는 타겟이 될 수도 있기 때문에, 수많은 스트링 랩퍼 클래스들이 생겨났다. 하지만 불행히도 어떤 상황에서 어떤 클래스를 써야하고 혹은 C스트링을 어떻게 랩퍼 클래스를 이용해 처리해야 하는지는 가끔씩 우리를 해깔리게 한다.

이번 강좌 2부의 내용은 Win32 API, MFC, STL, WTL과 VC런타임 라이브러리의 모든 스트링 랩퍼 클래스들을 다루고 있다. 각 클래스는 어떻게 생성하고 사용하며, 각각 어떻게 변환할수 있는지 설명할 것이다.

2부의 내용을 제대로 소화하기 위해서는 1부 1,2강에서 설명한 캐릭터 타입들과 인코딩 방식에 대한 충분한 이해가 필요할 것이다.

스트링 클래스의 가장 중요한 규칙

만약 문서화되어 있어 형변환에 문제가 없다는 확신이 없으면 강제 형변환은 피할것.

어떤 스트링랩퍼 클래스 X와 또다른 클래스 Z사이의 형변환에 관한 내용은 특히 초급 프로그래머들이 많이 궁금해 하는 내용이다. 주로 초급 프로그래머들은 강제 형변환을 시도한 후 왜 제대로 동작하지 않는가에 대해 많이 궁금해 하곤 한다. 수많은 스트링 타입들, 특히 BSTR 같은 타입은 명확히 문서화 되어있지 않은 게 현실이다. 따라서 많은 사람들은 쉽게 잘못된 코드를 작성할 가능성이 많았다.

무엇보다 중요한 점은 랩퍼클래스에서 형변환 연산자를 재정의 하지 않았다면 형변환은 사실 스트링 사이에서 아무 일도 하지 않는다. 그래서 만약 아래와 같은 코드를 작성 했다면:

void SomeFunc ( LPCWSTR widestr );

 

main()

{

  SomeFunc ( (LPCWSTR) "C:\\foo.txt" );  // WRONG!

}

위의 코드는 백이면 백 잘못된 결과를 초래할 것이다. 사실 위의 코드는 에러 없이 컴파일 된다. 하지만 컴파일이 된다고 그 코드가 옳바르다고 장담할수는 없는 것이다.

강의를 진행하면서 어떤 형변환이 옳바른 것인지 설명하도록 하겠다.

C-style strings and typedefs

지난 강의에서 살펴 보았듯이, Win API는 TCHAR 방식으로 정의되 있다. 그것은 컴파일 시에 문맥에 따라 MBCS방식으로 전환될수도 있고, 유니코드가 될수도 있다. 편의를 위해 지난 강의에 보여줬던 표를 다시 보여 주도록 하겠다.

타입 MBCS환경에서 유니코드 환경에서
WCHAR wchar_t wchar_t
LPSTR 0으로 끝나는 char형의 문자열(char*) 0으로 끝나는 char형의 문자열 (char*)
LPCSTR 0으로 끝나는 const char형의 문자열 (const char*) 0으로 끝나는 const char형의 문자열 (const char*)
LPWSTR 0으로 끝나는 유니코드형의 문자열 (wchar_t*) 0으로 끝나는 유니코드형의 문자열 (wchar_t*)
LPCWSTR 0으로 끝나는 const 유니코드형의 문자열 (const wchar_t*) 0으로 끝나는 const 유니코드형의 문자열 (const wchar_t*) 
TCHAR char wchar_t
LPTSTR 0으로 끝나는 TCHAR형의 문자열 (TCHAR* -> char*)  0으로 끝나는 TCHAR형의 문자열 (TCHAR*->wchar_t*)
LPCTSTR 0으로 끝나는 const TCHAR형의 문자열 (const TCHAR*) 0으로 끝나는 const TCHAR형의 문자열 (const TCHAR*)

타입을 하나 추가 하자면 OLECHAR을 들수 있겠다. 이 타입은 주로 자동화 인터페이스에서 사용된다. 이 타입은 보통 wchar_t 으로 정의되 있으나, 셋팅을 변경하거나 #define 문으로 OLE2ANSI 를 정의하면 단순 char 타입으로 전환된다. 하지만 사실상 요즘엔 OLE2ANSI 를 적용할 이유는 없다. (사실, MFC3 버젼에서 사용되어졌던 것이다. 구시대의 유물^^), 따라서 지금부터 그냥 단순히 OLECHAR 타입을 유니코드로 간주할 것이다.아래의 표는 OLECHAR 와 관계된 typedef 문으로 정의된 데이터 타입을 보여준다. :

타입 의미
OLECHAR 유니코드 케릭터 (wchar_t)
LPOLESTR 유니코드 스트링 (OLECHAR*)
LPCOLESTR const 형 유니코드 스트링 (const OLECHAR*)

문자열을 다룰 때 유니코드 MBCS 방식에 관계없이 일관된 표현을 할수 있게 해주는 두가지 마크로가 있다. _T 마크로는 지난 강의에서도 다루었던 부분이다. :

마크로 의미
_T(x) L 유니코드빌드일때 L을 앞에 주가해 준다.
OLESTR(x) LPOLESTR 타입으로 만들기 위해 L을 앞에 추가해 준다. 

또한 _T에서 변형된 형태의 하지만 같은 역활을 하는 몇몇 마크로 들이 더 있다. -- TEXT, _TEXT, __TEXT, and __T 이 마크로 들은 모두 같은 일을 한다.COM에서의 스트링 - BSTR

많은 자동화객체 인터페이스나 COM 인터페이스는 스트링으로 BSTR 타입을 사용한다. 하지만 BSTR타입은 다루기 매우 까다롭고, 에러를 유발하기 쉽다. 따라서 BSTR을 이번 파트에 다뤄 보도록 하겠다.

BSTR 타입은 파스칼 스타일의 스트링과 C 스트링 사이의 잡종 즉 서로 짬뽕되서 생긴 타입이다. 파스칼에서는 문자열타입에 그 길이가 내부적으로 저장된다. 하지만 C스트링에서는 마지막 제로바이트를 통해서 그 문자열의 끝을 알수있게끔 되어 있다. 사실 BSTR 타입은 문자일 길이를 문자열 시작 바로 전에 저장하고 이어서 유니코드 스트링을 저장하는 방식의 타입니다. 또한 제로바이트로 그 끝을 표시한다. 아래는 "Bob" 이라는 BSTR 타입의 스트링의 메모리 구조를 보여준다.:

06 00 00 00    42 00   6F 00   62 00   00 00
길이 B o b 스트링끝

눈치채셨다 시피 문자열의 길이가 DWORD타입으로 (즉 4바이트) 실제 문자 앞에 저장된다. 하지만 이는 마지막 00 00의 제로바이트를 포함하지 않은 길이 이다. 위의 경우 "Bob" 문자열은 총 6바이트의 3개의 유니코드 캐릭터를 가지고 있다. 길이 정보를 포함하는 이유는 COM 라이브러리가 다른 곳으로 마샬링 될때 얼마나 많은 바이트를 보내야 하는지 그 정보가 필요하기 때문이다. (사실, BSTR 은 단지 스트링뿐만 아니라 임의의 어떤 데이타가 들어 있어도 상관이 없다.)BSTR 변수는 C++에서 첫번째 캐릭터를 가리키는 포인터 변수 이다. BSTR 타입은 이렇게 정의 되있다. :

  typedef OLECHAR* BSTR;

불행히도 이런방식의 정의는 많은 문제를 유발할수 있다. 위에서도 설명했듯이 실제로는 BSTR은 유니코드 스트링과는 다른 특성을 가진 타입이다. 따라서 BSTR과 LPOLESTR은 마음대로 섞어 써도 컴파일러는 에러를 발생하지 않는다. LPOLESTR을 인자로 받는 함수에 BSTR 타입을 전달하는 것은 안전하다. 그렇지만 그 반대의 경우는 다르다. 따라서 함수가 받는 인자의 타입을 정확히 알고 정확히 전달하는 것이 중요하다.

BSTR 타입을 받는 함수에 LPOLESTR을 전달하는것이 왜 안전하지 못하냐 하면, BSTR이 가리키는 메모리 바로 앞 4바이트는 그 문자열의 길이를 포함하는 정보를 담고 있어여 한다. 아마 BSTR을 받는 함수에서는 그 정보가 포함되 있다는 가정하에 그 정보를 이용할 것이다. 하지만 LPOLESTR 타입에는 그러한 정보는 없다. 이는 안전하지 못한 결과를 낳을 것이다. 위에서 말했다 시피 COM객체에서는 BSTR 의 문자열 앞에 존재하는 문자열길이 정보를 이용해 그 만큼의 데이터를 전송한다고 있다. BSTR대신 LPOLESTR을 전달하면 얼마만큼의 바이트가 전송될지는 아무도 장담할 수가 없게 되는 것이다.따라서 BSTR을 다루기 위한 몇몇 API들이 존재하지만 그중 가장 중요한 것은 두가지 이다. 하나는 BSTR을 생성시키기 위한 것이고, 다른하나는 제거하기 위한 것이다. BSTR을 생성하는 함수는 SysAllocString() 이고 제거하는것은 SysFreeString()이다.  SysAllocString() 은 매개변수로 받은 유니코드 스트링을 BSTR형태로 만들어 주는 역할은 한다. (새로운 메모리를 할당한 후에 아마 문자열 길이를 계산해서 문자열 앞에 그 길이정보를 추가해 주는 정도의 일을 할 것이다.) 반면 SysFreeString() 은 BSTR 을 메모리에서 제거하는 역할을 한다.

BSTR bstr = NULL;

 

  bstr = SysAllocString ( L"Hi Bob!" );

 

  if ( NULL == bstr )

    // 메모리가 부족

 

  // bstr을 마음껏 사용^^

 

  SysFreeString ( bstr );

사실, 스트링 하나 사용하겠다고 이런 일련의 함수를 계속적으로 사용하는 것은 굉장히 피곤하다. 따라서 자연스럽게 메모리 할당, 제거를 자동적으로 해주는 몇몇 랩퍼 클래스들이 생겨나게 됐다. 그에 대해서 뒤에 살펴보기로 하자.

문자열(스트링) 전격 분석 2부 2강(끝)

이제 실제 클래스들을 다룹니다. 사실 원문에는 VARIANT타입과 VC7 CLR 환경에서의 스트링에 관련된 부분까지 포함하고 있으나, 제가 CLR에 대해서는 문외한인 관계로 생략했고, VARIANT부분은 특별히 의미가 있어 보이지 않아 생략했음을 알려드립니다.

본강좌는 코드 프로젝트에 제가 좋아하는 프로그래머인 Michael Dunn의 강좌 The Complete Guide to C++ Strings, Part I 과 II 를 번역한 글입니다. 최대한 의역을 하려고 노력했지만, 이런쪽의 경험이 부족하다 보니 많이 모자란 강좌가 되겠지만, 많은 도움이 되셨으면 합니다. 기타 문의 사항이나 질문은 쪽지나 메일을 이용해 주셨으면 합니다. 본강좌는 제 홈페이지(위의 링크)를 통해서도 보실수 있습니다.
　

스트링 랩퍼 클래스들

지금까지 여러가지의 스트링 타입에 대해 설명했고, 이제 스트링 랩퍼 클래스들에 대해 설명하겠다. 각각 어떻게 생성을 하고 어떻게 C스타일 스트링으로 변환시킬수 있는지 설명하겠다. 왜냐하면 C스타일 스트링 포인터는 API함수를 호출하거나 다른 랩퍼클래스들을 생성하는데 필요하기 때문이다. 나는 그외의 함수들 예를 들자면 정렬, 비교 등의 기능들에 대해서는 생략하도록 하겠다.

다시한번 강조하지만, 확실하지 않다면 절대로 강제 형변환을 하지 않도록 하자.

CRT에서 제공하는 클래스들

_bstr_t

_bstr_t 클래스는 아주 잘 만들진 BSTR 랩퍼 클래스다. 그리고 BSTR

의 내부구현이나 기타 등등의 문제를 랩핑 했다. 이 클래스는 여러가지 연산자를 재정의 했을 뿐만 아니라, 사용자의 편의를 위해 다양한 생성자를 제공한다. 하지만 BSTR자체에 접근하는 연산자들은 없다는 걸 주의해라. 따라서 [out] 파라미터를 갖는 COM 메서드에 직접적으로 전달할수는 없다. 만약 COM메서드에 직접적으로 전달할수 있는 BSTR* 타입이 필요하면 ATL 클래스인 CComBSTR 이 더 좋은 선택일 것이다.

하지만 물론 

_bstr_t 도 BSTR을 받는 함수에 전달할 수 있다. 이는 다음의 세가지 이유 때문이다. 첫째 _bstr_t 은 wchar_t* 으로의 형변환 연산자를 제공한다. 둘째, wchar_t* 과 BSTR 는 컴파일 과정에서는 같은 타입으로 인식된다. 왜냐하면 BSTR은 wchar_t*형으로 정의되 있기 때문이다. 마지막 세번째는 _bstr_t 

는 내부적으로 문자열의 시작부분을 포인터로 가리키고 있기 때문이다. 따라서 명시적으로 형변환 연산자가 없어도 잘 작동되곤 한다.

// 생성
_bstr_t bs1 = "char string";       // LPCSTR로 부터 생성
_bstr_t bs2 = L"wide char string"; // LPCWSTR로 부터 생성
_bstr_t bs3 = bs1;                 // 다른 _bstr_t로 부터 생성
_variant_t v = "Bob";
_bstr_t bs4 = v;                   // 스트링을 포함하는 _variant_t로 부터 생성


// Extracting data
LPCSTR psz1 = bs1;              // 자동으로 MBCS로 형변환
LPCSTR psz2 = (LPCSTR) bs1;     // 위의 경우와 같다.
LPCWSTR pwsz1 = bs1;            // 내부적으로 포함하는 유니코드 스트링 리턴
LPCWSTR pwsz2 = (LPCWSTR) bs1;  // 위의 경우와 같다.
BSTR    bstr = bs1.copy();      // 복사


  // ...
  SysFreeString ( bstr ); //메모리에서 해제해 주어야 한다.

_bstr_t 은 또한 char* 와 wchar_t* 

에 대한 형변환 연산자도 가지고 있다. 하지만 이는 의문스러운 구현이다. 이 연산자들에 의해 리턴되는 포인터는 const 타입이 아니여서 수정될수도 있지만, 만약 수정된다면 내부적인 BSTR 타입이 깨질것이고, 많은 문제를 유발할 것이다.

STL 클래스들

STL은 

basic_string 하나의 스트링 클래스가 있다. basic_string 

은 0으로 끝나는 문자배열 스트링을 관리한다. 어떤 캐릭터 타입이 쓰일지에 대한것은 템플릿 매개변수로 전달이 된다. 일반적으로 이 클래스에서 얻은 포인터를 직접적으로 조작하는 일은 피해야 한다. 대신 이 클래스에서 제공하는 함수나 연산자들을 써서 조작하기를 권장한다.

이 클래스에서 미리정해진 두가지의 형태의 타입이 존재한다. 하나는 char

 를 조작하는 string이고 다른 하나는 wchar_t를 조작하는 wstring 

이다. 사실, TCHAR 형의 스트링 클래스는 정의되 있지 않지만 아래의 코드를 통해 TCHAR타입도 사용할 수가 있다.

// 타입 정의
typedef basic_string<TCHAR> tstring; // TCHAR형 스트링


// 생성자들
string str = "char string";         // LPCSTR로 부터 생성
wstring wstr = L"wide char string"; // LPCWSTR로 부터 생성
tstring tstr = _T("TCHAR string");  // LPCTSTR로 부터 생성


// Extracting data
LPCSTR psz = str.c_str();    // 읽기 전용 즉 const형 버퍼 리턴
LPCWSTR pwsz = wstr.c_str(); // 읽기 전용 즉 const형 버퍼 리턴 LPCWSTR형
LPCTSTR ptsz = tstr.c_str(); // 읽기 전용 즉 const형 버퍼 리턴 LPCTSTR형

_bstr_t형과는 다르게 basic_string 클래스는 다른 캐릭터 타입들끼리 직접적으로 형변환을 할수 없다. 그러나 c_str() 

함수에서 전달되는 포인터를 이용해서 다른 클래스를 생성할 수 있다. 하지만 그 다른 클래스에는 그 포인터를 받는 생성자가 존재해야만 할 것이다. 예를 들면 :

// 예제 basic_string타입을 이용해서 _bstr_t 형 객체 생성
_bstr_t bs1 = str.c_str();  // LPCSTR 로 부터 생성
_bstr_t bs2 = wstr.c_str(); // LPCWSTR 로 부터 생성

ATL 클래스들

CComBSTR

CComBSTR 은 ATL의 BSTR랩퍼 클래스다. 몇몇 곳에서 _bstr_t 보다 더 유용하게 쓰인다. 가장 중요한 부분은 CComBSTR 은 내부에 존재하는 BSTR 을 직접적으로 접근할수 있다는 데 있다. 이 얘기는 즉, COM 메서드에 직접적으로 CComBSTR 객체를 전달할수 있다는 얘기가 된다. 그럼 CComBSTR 객체는 자동으로 BSTR 

에 관련된 메모리를 관리해 줄것이다. 예를 들어 아래의 인터페이스의 메서드를 호출한다고 가정해보자. :

// 간단한 인터페이스
struct IStuff : public IUnknown
{
  // 생략....
 
  STDMETHOD(SetText)(BSTR bsText);
  STDMETHOD(GetText)(BSTR* pbsText);
};

CComBSTR 은 BSTR 형변환 연산자를 가지고 있다. 따라서 객체를 직접적으로 SetText() 메서드에 전달할 수가 있다. 또한 & 연산자를 제정의 해서 BSTR* 타입을 리턴한다. 그래서 여러분은 BSTR* 

타입을 받는 메서드에 부가적인 형변환이 없이도 직접적으로 전달 할수 있게 된다.

CComBSTR bs1;
CComBSTR bs2 = "new text";


  pStuff->GetText ( &bs1 );       // 내부 BSTR 의 포인터 전달
  pStuff->SetText ( bs2 );        // BSTR 로 암시적 형변환
  pStuff->SetText ( (BSTR) bs2 ); // 명시적 형변환 위의 경우와 정확히 같다.

CComBSTR 은 _bstr_t 

타입과 거의 유사한 생성자 구조를 가지고 있다. 하지만 중요한 점은 MBCS 스트링을 자동적으로 변환해 주는 생성자는 없다는 것이다. 따라서 MBCS 스트링을 사용할 경우에는 여러가지 방법으로 BSTR형으로 변환해 주어야만 한다. 그 중에서 ATL 변환 마크로 들을 추천한다.

// 생성
CComBSTR bs1 = "char string";       // LPCSTR 로 부터 생성
CComBSTR bs2 = L"wide char string"; // LPCWSTR 로 부터 생성
CComBSTR bs3 = bs1;                 // CComBSTR  로 부터 복제생성
CComBSTR bs4;


  bs4.LoadString ( IDS_SOME_STR );  // 스트링 테이블 리소스로 부터 생성


// 값 얻어오기
BSTR bstr1 = bs1;        // 내부의 BSTR을 리턴 하지만 조작하지는 말것!!
BSTR bstr2 = (BSTR) bs1; // 형변환도 OK
BSTR bstr3 = bs1.Copy(); // 같은 내용의 BSTR을 생성후 리턴
BSTR bstr4;


  bstr4 = bs1.Detach();  // bs1 내부의 BSTR을 더이상 관리하지 않는다.


  // ...
  SysFreeString ( bstr3 );
  SysFreeString ( bstr4 );

위의 예제에서 

Detach() 메서드 부분을 주의해서 보자. 이 메서드의 호출후에는 CComBSTR 객체는 더이상 BSTR을 관리하지 않는다. 따라서 마지막부분의 SysFreeString() 

함수를 호출해 줄 필요가 있는 것이다.

마지막으로 중요한 문제는 위 클래스가 & 연산자를 정의했다는 부분이다. 즉, 이 얘기는 STL 컬렉션 클래스 들에는 CComBSTR타입을 직접적으로 쓸수 없다는 얘기이다. 왜냐하면 STL컬렉션들은 & 연산자는 내부적으로 관리하는 객체 리스트 들의 주소값을 리턴해야만 하는데 CComBSTR 클래스에서 & 연산자를 정의함으로써 CComBSTR* 을 리턴하는게 아니라, BSTR*를 리턴 하게 된다. 따라서 이 경우에는 아래의 예처럼 CAdapt 클래스로 처리해 주어야 한다. :

  std::list< CAdapt<CComBSTR> > bstr_list;

CAdapt 클래스는 컬랙션 클래스에 필요한 연산자들을 다시 정의 하고 있다. 따라서 CComBSTR 

의 리스트를 사용할수 있게 된다.

ATL 형변환 매크로들

ATL의 스트링 형변환 매크로 들은 스트링 사이의 인코딩을 변경하는 매우 편리한 방법을 제공한다. 특히, 함수호출 시에 매우 편리하다. 매크로의 이름들도 명료하다. 

[소스 타입]2[새로운 타입] 혹은 [소스 타입]2C[새로운 타입]. 

두번째의 매크로는 C라는 글자를 포함하는데 이는 const형(읽기전용)으로의 변환을 의미한다. 각각의 타입에 대한 정의는 다음과 같다.:

A: MBCS 스트링, char

* (A 

는 ANSI를 의미)
W: Unicode 스트링, 

wchar_t* (W

는 wide를 의미)
T: 

TCHAR 스트링, TCHAR*


OLE: 

OLECHAR 스트링, OLECHAR* (

사실, W와 같은 의미)
BSTR: 

BSTR

그래서, 예를 들면, 

W2A() 매크로는 유니코드 스트링을 MBCS 스트링으로 변환해 준다. 그리고 T2CW() 매크로는 TCHAR 

스트링을 읽기전용 유니코드 스트링으로 변환해 준다.

이 매크로들을 사용하기 위해서는 먼저 atlconv.h 헤더를 포함해 준다.(위의 매크로들은 ATL프로젝트가 아니여도 사용할수 있다.!! 왜냐하면 위의 헤더 파일은 다른 ATL 부분과의 의존성이 없다. 즉 따로 놀기 때문이다. 그리고 ATL의 _Module 객체를 필요로 하지 않는다.)  둘째로, 해더를 포함했으면 위의 매크로들을 사용하기에 앞서 

USES_CONVERSION 

라는 매크로를 써주어야 한다. 위의 매크로는 형변환을 하기위해 필요한 몇몇 지역변수들을 선언한다. 즉, 형변환을 하기위한 지저분한 일들을 해준다.

변환하고자 할 타입이 BSTR 타입이 아닐때는 변환된 타입은 스택에 저장된다. 따라서 함수범위를 넘어서 작업을 하고 싶으면 여러분은 다른 스트링 클래스에 복사를 해서 저장 하든지 해서 계속적으로 사용할수 있을 것이다. 하지만 BSTR타입의 경우는 ::SysFreeString등의 함수로 해제를 시켜 주어야 한다.

아래는 변환 매크로 들을 사용하는 예제 코드 이다. :

// 다양한 형태를 받는 함수들:
void Foo ( LPCWSTR wstr );
void Bar ( BSTR bstr );
// 스트링을 리턴하는 함수(BSTR*형에 주의):
void Baz ( BSTR* pbstr );


#include <atlconv.h>


main()
{
  using std::string;
  USES_CONVERSION;    // 형변환 매크로를 사용하기위해서


  // 예제 1 : Foo()함수에 MBCS를 전달
  LPCSTR psz1 = "Bob";
  string str1 = "Bob";


  Foo ( A2CW(psz1) );
  Foo ( A2CW(str1.c_str()) );


  // 예제 2: Bar()함수에 MBCS 와 유니코드 스트링 전달
  LPCSTR psz2 = "Bob";
  LPCWSTR wsz = L"Bob";
  BSTR bs1;
  CComBSTR bs2;


  bs1 = A2BSTR(psz2);         // BSTR 생성
  bs2.Attach ( W2BSTR(wsz) ); // CComBstr에 할당


  Bar ( bs1 );
  Bar ( bs2 );


  SysFreeString ( bs1 );      // 반드시 해제해 주어야 한다.
  // bs2의 경우는 CComBstr의 소멸자가 알아서 해재해 준다.


  // 예제 3: Baz()함수에서 리턴반든 BSTR형의 형변환
  BSTR bs3 = NULL;
  string str2;


  Baz ( &bs3 );          // Baz()를 통해 BSTR을 얻었다.


  str2 = W2CA(bs3);      // MBCS 스트링으로 형변환
  SysFreeString ( bs3 ); // 메모리 해제
}

보시다 시피, 위의 매크로 들은 매우 간편하다. 이제 몇가지 사실들에만 주의하면 어디서든 편하게 위의 매크로들을 사용할수 있을 것이다.

MFC 클래스들

CString

MFC의 

CString 클래스는 TCHAR 형 타입을 다룬다. 따라서 정확한 캐릭터 타입은 컴파일 시간에 전처리명령어를 통해 달라진다. 일반적으로 CString 타입은 STL의 string 타입과 유사하다. 왜냐하면 여러분은 CString을 다룰때 std::string 에서 처럼 직접적으로 문자열 조작을 피하고 제공되는 함수들을 써야 하기 때문이다. 한가지 STL의 스트링 클래스보다 CString클래스가 편리한 점은 CString클래스는 MBCS 스트링과 유니코드 스트링을 모두 수용하는 생성자를 가지고 있다는 사실이다. 그리고 LPCTSTR

형변환 연산자를 제공해서 여러분은 LPCTSTR을 받는 함수에 특별한 형변환 없이 전달 할수 있다. std::string에서 처럼 c_str()들의 메서드를 호출할 필요가 없다.

  // 생성자
  CString s1 = "char string";  // LPCSTR 로 부터 생성
  CString s2 = L"wide char string";  // LPCWSTR 로 부터 생성
  CString s3 ( ' ', 100 );  // 100바이트를 할당하고 스페이스 문자로 채운다. 
  CString s4 = "New window text";


  // LPCTSTR을 받는 함수에 직접 전달할수 있다.
  SetWindowText ( hwndSomeWindow, s4 );


  // 혹은 명시적 형변환으로 위의 경우와 정확히 같다.
  SetWindowText ( hwndSomeWindow, (LPCTSTR) s4 );

또한 리소스의 스트링 테이블을 좀 더 편하게 읽어올수 있다. 생성자에서도 그런일을 해주고 Format() 메서드에서도 그런 일이 가능하다.

  // 스트링 테이블의 문자열로 부터 생성
  CString s5 ( (LPCTSTR) IDS_SOME_STR );  
  CString s6, s7;


  // LoadString메서드
  s6.LoadString ( IDS_SOME_STR );


  // printf스타일로 포맷팅
  s7.Format ( IDS_SOME_FORMAT, "bob", nSomeStuff, ... );

첫번째의 생성자는 약간 이상해 보인다. 하지만 이는 정확히 문서화 되 있는 문자열 테이블로 부터 문자열을 생성하는 방법이다.

CString에 적용될수 있는 형변환은 

LPCTSTR 타입 뿐이다. LPTSTR (즉 non-const) 로의 형변환은 잘못된 것이다. 많은 사람들이 LPTSTR형으로 변환하고 사용하는 일을 종종 보게 되는데 이는 여러가지 문제를 야기할 것이다. 나중에 버그를 찾기도 굉장히 어렵게 만든다. ^^ 따라서 LPTSTR형의 값을 얻으려면 GetBuffer() 

메서드를 써야만 한다.

리스트 콘트롤에 텍스트를 지정한다고 가정하고 다음 예제를 보자.:

  CString str = _T("new text");
  LVITEM item = {0};


  item.mask = LVIF_TEXT;
  item.iItem = 1;
  item.pszText = (LPTSTR)(LPCTSTR) str; // 잘못된 사용!
  item.pszText = str.GetBuffer(0);      // 올바른 사용


  ListView_SetItem ( &item );
  str.ReleaseBuffer();  // 위의 버퍼의 관리를 다시 CString에서 하게끔 해제

위의 예에서 

pszText 멤버는 LPTSTR 타입이다. 그러므로 GetBuffer() 메서드를 사용해 주어야 한다. GetBuffer() 의 매개변수는 여러분이 할당하기를 원하는 버퍼의 최소 길이를 지정해 준다. 만약 1Kb의 버퍼를 원한다면 GetBuffer(1024) 

이런식으로 호출해 주면 될것이다. 0을 전달하는 것은 현재 스트링이 포함한 스트링의 길이와 정확히 같은 길이의 버퍼를 리턴한다.

위의 사선으로 표시한 잘못된 예제는 컴파일 되고 사실 잘 작동되는것 처럼 보인다. 그렇지만 그 코드는 분명 잘못된 코드이다. 일단 위의 코드는 객체지향의 개념에 어긋나는 것이다. 캡슐화 되어있는 데이터를 직접조작하는 습관은 좋지 못하다. 그리고 내부적으로 관리되는 데이터의 구조를 무너뜨릴 가능성이 크다. 따라서 나중에 분명 원하지 않는 결과를 초래 할 것이다.

요즘의 많은 소프트웨어들은 모두 버그를 포함하고 있다. 이는 프로그래머들의 잘못된 습관에서 나오는 경향이 많다. 따라서 항상 올바른 프로그래밍 습관을 만들려고 노력하자. 버그가 0%가 되는 그날까지...

CString 클래스는 또한 BSTR을 만들어 주는 두가지 함수가 있다. AllocSysString() 와 SetSysString(). SetSysString() 

이 BSTR* 인자를 받는다는 점만 빼고 , 위 두함수는 정확히 같은 일은 한다.

  // BSTR로 변환
  CString s5 = "Bob!";
  BSTR bs1 = NULL, bs2 = NULL;


  bs1 = s5.AllocSysString();
  s5.SetSysString ( &bs2 );


  // ...
  SysFreeString ( bs1 );
  SysFreeString ( bs2 );

WTL 클래스들

CString

WTL의 

CString 클래스는 MFC의 CString 

클래스와 정확히 똑같이 작동한다. 따라서 MFC의 CString부분을 참고하길 바란다.

printf스타일의 포맷팅 함수에서의 스트링 클래스 사용

여러분은 

printf() 혹은 비슷한 방식으로 작동하는 함수들을 사용할때 특별히 주의해야 한다. 이런 함수들에는 sprintf() 등이 있고, 또한 TRACE 나 ATLTRACE 

매크로도 똑같은 방식으로 작동한다. 이러한 함수나 매크로에서는 특별히 타입체킹을 하지 않기 때문에 여러분은 반드시 스트링 객체를 직접 전달하지 않고 C스타일 스트링을 전달 해야만 한다.

예를 들면, 

_bstr_t 객체가 가지고 있는 스트링을 ATLTRACE() 에 전달할때 여러분은 반드시 명시적으로 (LPCSTR) 나 (LPCWSTR) 

로 형변환을 해 주어야 한다.:

  _bstr_t bs = L"Bob!";
  ATLTRACE("The string is: %s in line %d\n", (LPCSTR) bs, nLine);

만약 형변환을 깜박했다면 아마 예상치 못한 결과가 출력될것이다.

총 정 리

스트링 클래스들 사이의 형변환을 일반적으로 다음의 방식을 따른다. 일반 소스 스트링을 C스타일 스트링으로 변환한 후 그것을 이용해 새로운 스트링 타입으로 생성하는 것이다. 따라서 아래의 표는 각각의 클래스 들이 C스타일로 형변환 할수 있는지 그리고 C스타일 스트링으로부터 객체를 생성할수 있는지 요약해서 보여주고 있다.

Class string
type		 convert 
to char*? 		 convert to
const char*?		 convert to
wchar_t*?		 convert to
const wchar_t*?		 convert
to BSTR? 		 construct
from char*?		 construct
from wchar_t*?
_bstr_t BSTR yes, cast1 yes, cast yes, cast1 yes, cast yes2 yes yes
_variant_t BSTR no no no cast to
_bstr_t3		 cast to
_bstr_t3		 yes yes
string MBCS no yes, c_str()
method		 no no no yes no
wstring Unicode no no no yes, c_str()
method		 no no yes
CComBSTR BSTR no no no yes, cast
to BSTR		 yes, cast yes yes
CComVariant BSTR no no no yes4 yes4 yes yes
CString TCHAR no6 in MBCS
builds, cast		 no6 in Unicode
builds, cast		 no5 yes yes
COleVariant BSTR no no no yes4 yes4 in MBCS builds in Unicode builds
1 Even though _bstr_t provides conversion operators to non-const pointers, modifying the underlying buffer may cause a GPF if you overrun the buffer, or a leak when the BSTR memory is freed.
2 A _bstr_t holds a BSTR internally in a wchar_t* variable, so you can use the const wchar_t* converter to retrieve the BSTR. This is an implementation detail, so use this with caution, as it may change in the future.
3 This will throw an exception if the data cannot be converted to a BSTR.
4 Use ChangeType() then access the bstrVal member of the VARIANT. In MFC, this will throw an exception if the data cannot be converted.
5 There is no BSTR conversion function, however the AllocSysString() method returns a new BSTR.
6 You can temporarily get a non-const TCHAR pointer using the GetBuffer() method.
 

 

저작자표시

'C & C++ > C & C++' 카테고리의 다른 글

전처리 지시어  (0) 2011.04.14
ini 파일 읽고 쓰기  (0) 2011.04.14
파일존재 파악, 선택시 파일삭제  (0) 2011.04.07
파일 사이즈 얻어오기  (0) 2011.04.07
[Tip] Wait() 시간 갭을 주기위한 함수  (0) 2011.04.07

관련글

댓글

티스토리툴바