* 이 글의 내용은 클립보드 API, const 이야기의 연장선상에 있다. 관심 있으신 분은 예전에 썼던 글을 먼저 읽어 보시기 바란다.
1.
Windows API에는 GetPriorityClipboardFormat라는 함수가 있다. 이것은 클립보드로부터 '붙여넣기'(paste) 기능이 있는 프로그램이 사용할 만한 함수이다. 이 함수가 지목하는 포맷에 해당하는 클립보드 내용을 붙여넣으면 되며, 사실은 그보다도 먼저 이 함수의 실행 결과에 따라 '붙여넣기' 메뉴를 enable/disable시킬지를 결정하면 된다.
내 프로그램이 지원하는 클립보드 포맷이 단 하나밖에 없다면 IsClipboardFormatAvailable을 쓰면 된다. 그렇지 않고 여러 종류의 포맷을 지원하는데, 현재 클립보드에 존재하는 포맷 중에 우선순위가 가장 높은 놈은 무엇인지 알고 싶다면 말 그대로 저 priority라는 단어가 들어간 함수를 써서 요청을 해야 한다. 이것은 마치 커널 오브젝트의 동기화에서 쓰이는 WaitForSingleObject와 WaitForMultipleObjects 함수쌍의 관계와 일면 비슷하다.
그런데 내가 궁금한 점은 이 함수의 첫째 인자가 const UINT *가 아니라 왜 그냥 UINT *냐는 것이다.
첫째 인자는 함수로 전달하는 복수 개의 클립보드 포맷 리스트의 포인터이며, 속성이 엄연히 out이 아닌 in이라고 명시되어 있다. 저 함수 역시 인자로 받은 리스트 내용을 참조만 할 것이니, 포인터가 read-only가 아니라 일반 read-write 형태여야 할 하등의 이유가 없다. WaitForMultipleObjects만 해도 HANDLE의 배열 포인터는 분명히 const HANDLE *로 잡혀 있지 않던가?
저게 const라면,
static const table[] = { CF_UNICODETEXT, CF_HDROP }; //사람이 텍스트로 입력한 파일명 & 탐색기에서 복사해 놓은 파일명을 모두 받아들임
int res = GetPriorityClipboardFormat(table, ARRAYSIZE(table));
이런 식으로 간편하게 static const 배열을 함수에다 넘겨 줄 수 있을 텐데, const가 아니기 때문에 일이 좀 귀찮아진다. table에 const 속성을 제거하든지, 아니면 함수에다 넘겨 줄 때 const_cast 연산자를 써 줘야 한다. 내 경험상, 강제로 const 포인터로 고친다고 해서 딱히 프로그램 동작에 문제가 생긴다거나 하는 건 아니더라.
하지만 내 프로그램 내부에서 값을 고칠 일이 절대로 없기 때문에 const로 엄연히 봉인해 버리고 싶은 테이블을 봉인하지 못한다니, 썩 보기 좋아 보이지 않는다. 또한 const_cast 같은 연산자가 늘어나는 건 내 소스 코드에서 무질서도가 쓸데없이 증가하는 듯한 느낌을 준다.
물론, 동일한 유형의 데이터에 대해서 클립보드 포맷을 복수 개 지원한다는 건 대개가 custom 포맷과 표준 포맷을 혼용하는 경우이다. 리스트의 모든 원소가 상수가 아니며, 우선적으로 선택되었으면 하는 앞부분은 어차피 RegisterClipboardFormat의 리턴값인 경우가 많다. 워드 프로세서라면 모든 정보가 보관되어 있는 고유 포맷일 것이고, 텍스트 에디터라면 칼럼 블록을 명시한 고유 포맷이다.
그러니 저 함수의 인자로 전달되는 배열 포인터는 애초부터 const가 아니라 일반 배열일 가능성이 더 높다. 메시지만 해도, 시스템 차원에서의 유일성을 보장받기 위해 RegisterWindowMessage로 특수하게 등록한 메시지는 WM_USER+x와는 달리 가변적인 값이다. 그렇기 때문에 윈도우 프로시저에서 switch/case를 이용해 걸러낼 수가 없으며 if문을 써서 비교해야 하지 않던가. (이 두 Register* 함수는 프로토타입이 UINT Foo(PCTSTR name)로 완전히 동일하며, 명칭을 hash하여 숫자로 바꿔 준다는 공통점이 있어서 더욱 동질감이 느껴진다)
그런데.. 그런 식으로 치자면 WaitForMultipleObjects가 받아들이는 HANDLE도 NULL이나 INVALID_HANDLE_VALUE 같은 오류 상황 말고는 고정불변 상수값이 존재할 여지가 전혀 없는 타입이다. 값의 가변/불변성과는 무관하게 해당 함수가 값들을 읽기만 한다면 함수 인자가 응당 const 포인터로 잡혀 있어야 할 텐데, 클립보드의 저 함수는 왜 저렇게 설계되었으며 디자인에 문제를 제기하는 사람이 왜 없는지 궁금하다.
2.
서식이 없고 칼럼 블록도 없는 일반 텍스트 에디터에서 붙이기를 구현한다면 굳이 custom 포맷을 등록할 필요는 없을 것이고 애초에 복수 개의 클립보드 포맷을 살펴볼 필요도 없을 것이다. 단, 여기에도 원래는 유니코드/ANSI와 관련된 미묘한 문제가 있다. wide 문자 기반인 CF_UNICODETEXT와, ansi 문자 기반인 CF_TEXT가 따로 존재하기 때문이다.
Windows NT는 이들 사이에서 '유도리'를 제공한다.
응용 프로그램이 유니코드 텍스트 형태(CF_UNICODETEXT)로 클립보드에다 텍스트를 복사해 놓은 뒤, 나중에 유니코드를 지원하지 않는 프로그램이 클립보드로부터 CF_TEXT 포맷을 요청하는 경우 운영체제는 CF_TEXT도 있다고 답변을 하며, CF_UNICODETEXT로부터 CF_TEXT 데이터도 자동으로 만들어 준다. 그 반대도 물론 해 준다. (복사는 CF_TEXT로, 붙여넣기는 CF_UNICODETEXT로)
마치 Get/SetWindowText, WM_GET/SETTEXT에서 운영체제가 A/W 문자열 보정을 하듯이, 클립보드에 대해서도 그런 보정을 해 준다. 재미있지 않은가? 그러니 오늘날의 Windows에서는 유니코드를 지원하는 프로그램은 어떤 경우든 CF_UNICODETEXT만 생각하고 요걸로만 읽고 쓰면 유니코드를 지원하지 않는 구시대 프로그램과도 의사소통에 아무 문제가 없다.
하지만 문제가 되는 건 내부적으로 유니코드를 사용하는 프로그램이 Windows 9x까지 고려해서 만들어질 때이다. 9x 계열에서는 CF_UNICODETEXT는 응용 프로그램이 굳이 요청해서 자기들끼리 쓰지 않는 한, 운영체제 차원에서 공식적으로는 '없는 포맷', 지원하지 않는 유령/공기 포맷이다. 고로 NT 계열과 같은 타입 자동 변환이 없다.
텍스트 에디터가 자기는 내부적으로 유니코드 기반이라고 해서 자신이 native로 사용하는 CF_UNICODETEXT 형태로만 데이터를 복사해 놓으면, 기존 메모장 같은 프로그램에서는 텍스트 붙이기를 할 수 없게 된다.
그렇기 때문에 9x 계열과 유니코드라는 두 토끼를 모두 잡으려면 응용 프로그램은 클립보드로부터 데이터를 읽을 때도 IsClipboardFormatAvailable가 아니라 저 GetPriorityClipboardFormat를 써서 CF_UNICODETEXT와 CF_TEXT를 모두 살펴봐야 한다. 물론 1순위는 유니코드로 하고 말이다.
그리고 빈 클립보드에다 텍스트를 복사해 넣을 때에도 CF_UNICODETEXT부터 먼저 집어넣은 뒤, CF_TEXT 타입도 자동으로 생겨 있는지를 IsClipboardFormatAvailable로 체크하고, 없으면 ansi 텍스트도 수동으로 넣어 줘야 한다. Windows NT에서는 유니코드 텍스트만 집어넣어도 CF_TEXT로 붙여넣는 게 저절로 가능하지만 9x에서는 그렇지 않기 때문이다.
참 얼마 만에 클립보드 얘기를 또 꺼내게 됐는지 모르겠다. 지금이야 먼 과거의 유물이 됐다만, Windows 9x 시절에는 텍스트 하나를 유니코드 형태로 주고받을 때는 이렇게 미묘하게 귀찮은 면모가 좀 있었다.
클립보드에다 데이터를 지정하는 SetClipboardData는 GMEM_MOVEABLE을 지정해서 GlobalAlloc으로 평범하게 할당한 메모리 핸들을 넘겨 주는 방식으로 사용하면 된다. 함수를 호출한 뒤부터는 그 메모리 핸들은 운영체제의 관할로 넘어가기 때문에 우리가 임의로 해제해서는 안 된다.
이것과 굉장히 비슷한 개념으로 운용되는 다른 함수는 SetWindowRgn인 것 같다. 평범한 HRGN을 넘겨 주지만 이제부터 이 region은 운영체제의 관할이 되기 때문이다. 우리가 더 건드려서는 안 된다.
3.
C/C++은 여느 언어와 마찬가지로 const라는 속성이 존재하는데, 이것은 (1) 완전히 붙박이 상수가 될 수 있으며, 아니면 (2) 런타임 때 가변적인 초기값이 붙는 것도 가능하지만, 한번 값이 정해진 뒤에는 불변이라는 의미도 될 수 있다.
이거 혼동하기 쉬운 개념이다. C/C++의 const는 (1)은 딱히 보장하지 않고 일단은 (2)만 보장한다.
const형 변수를 초기화하는 초기값으로는 반드시 case 레이블이나 static 배열의 크기처럼 컴파일 타임 때 값이 결정되는 상수만 와야 하는 게 아니다. 변수도 얼마든지 초기값으로 지정할 수 있으며, 이건 그냥 const뿐만 아니라 static const에 대해서도 마찬가지이다. 애초에 const는 타입에 제약이 없으니까. (1)을 정수 명칭에 한해서 보장해 주는 건 enum, 아니면 템플릿 인자이다.
그래서 C#은 이 두 개념을 const와 readonly로 확실하게 구분해 놓았는데, 이건 상당히 매력적인 조치라 여겨진다. 배열· 테이블도 const로 지정이 가능하니까 말이다. 또한 붙박이 불변 const는 스택에든 어디든지 여러 인스턴스가 중복해서 존재할 이유가 하등 없으니 static 속성도 자동으로 포함하는 걸로 간주된다.
한편, 포인터가 const라면(가령 p) p 자신의 값을 바꿀 수 없는지, 아니면 p가 가리키는 메모리의 값을 바꿀 수 없는지(*p 혹은 p->)가 문제가 된다. const TYPE *p라고 하면 *p가 잠기고, TYPE * const p라고 하면 p가 잠긴다. const TYPE * const p라고 하면 짐작하시겠지만 둘 다 잠긴다.
문법이 좀 복잡한데, const T와 T const는 의미상 동일하다. 그리고 포인터값 자체를 잠글 때는 * 뒤에다가 const를 추가로 붙인다고 생각하면 비교적 직관적으로 이해할 수 있다.
하지만 포인터라는 게 지니는 값은 NULL 같은 특수한 경우가 아니고서야 언제나 가변적인 메모리 주소이기 때문에.. 포인터에다 const는 p 자신이 아닌 *p를 잠그는 용도로 훨씬 더 많이 쓰인다. 클래스 멤버 함수에 붙는 const도 this 포인터에 대해서 *this를 읽기 전용으로 잠그는 역할을 한다. this는 예약어이다 보니 this의 주소값 자체를 변경하는 건 어떤 경우든 원래부터 가능하지 않으니 말이다.
그리고 *p가 잠긴 const 포인터에 대해서 그 잠김을 일시적으로 해제하는 형변환 연산자는 잘 알다시피 const_cast이다. 다만, const가 사라진 TYPE *라는 타입명을 그 뒤의 <> 안에다가 수동으로 일일이 써 줘야 한다. 이름은 const_cast이지만 얘는 '쓰기 금지'뿐만 아니라 언어 차원에서의 타입과 "무관하게" 변수 접근 방식과 관련하여 붙어 있는 추가적인 제약 속성을 제거할 때에도 쓰인다. volatile이 대표적인 예이고, 비주얼 C++의 경우 IA64 아키텍처 기준으로 __unaligned 속성도 이걸로 제거할 수 있다. (IA64는 기본적으로 machine word 단위로 align이 된 곳만 메모리 접근이 가능한지라..)
Windows API에는 포인터의 const-ness 구분 때문에 불편한 게 몇 군데 있다. 대표적인 건 CreateProcess 함수.
실행할 프로세스를 가리키는 명령줄은 PCTSTR이 아니라 PTSTR이다. 함수가 내부적으로 실행될 때는 파일명과 인자명을 구분하기 위해서 문자열의 중간에 \0을 삽입해서 토큰화를 하기 때문이다. 즉, strtok 함수가 동작하는 것처럼 토큰화를 하며 문자열을 변경한다.
이 함수는 실행 후에 문자열 내용을 다시 원래대로 되돌려 놓긴 하지만, 명령줄 문자열을 나타내는 메모리는 일단 read-only가 아니라 쓰기가 가능한 놈이어야 한다. *a+=0; 을 수행하려면 비록 *a의 값이 실제로 변경되지는 않지만 그래도 가리키는 메모리가 변경 가능해야 하는 것과 비슷한 이치이다.
Windows NT 계열에서 CreateProcessA 함수를 호출하면 얘는 어차피 문자열을 쓰기 가능한 문자열에다가 유니코드로 변환해서 내부적으로 W 함수가 사용된다. 그렇기 때문에 A함수에다가 (PSTR)"notepad.exe sample.txt" 이런 식으로 줘도 안전하긴 하다. 그러나 범용성을 고려하면 이는 그렇게 깔끔한 코드라고 보기 어렵다.
다음으로 DrawText도 기능을 제공하는 형태가 조금 지저분하다.
얘는 문자열을 받아들여서 출력하는데 폭이 부족할 경우 문자열을 있는 그대로 출력하는 게 아니라 "Abc..."라고 줄여서 출력하는 옵션이 있다. 그런데 사용자가 원한다면 자기가 받은 문자열 자체를 그렇게 출력되는 형태로 '수정해' 주는 옵션이 있다(DT_MODIFYSTRING). 이 옵션을 사용한다면 str은 PCTSTR이라는 프로토타입과는 달리 쓰기 가능한 포인터여야 한다.
또한 RECT *인자도 좀 아쉬운 구석이 있다. 일단은 in/out 겸용이어서 RECT *이지만, 이것도 out 없이 문자열을 찍을 영역만 지정하는 in 전용이 가능했으면 좋겠다.
끝으로, 리스트/트리 같은 공용 컨트롤에 데이터를 추가하는 LVITEM이 있다. 이들 구조체의 pszText는 PCTSTR이 아니라 PTSTR이다. 문자열을 얻어 올 때와 지정할 때 모두 동일한 구조체가 쓰이기 때문에 const 속성이 없는 것이다.
이 때문에 컨트롤에다 데이터를 처음 추가할 때 item.pszText=const_cast<PSTR>("Hello") 같은 연산이 부득이 쓰이기도 한다.
C++과는 달리 자바에는 클래스 멤버 함수라든가, call-by-reference로 전달되는 데이터에 대해서 const-ness를 보증하는 개념이 없다. 클래스에서 Get*으로 시작하는 메소드라고 해서 const를 따로 지정하지는 않으며, final 키워드는 함수의 오버라이드 불가, 값의 변경 불가 같은 '종결자' 용도로만 쓰인다. 과연 const가 없어도 괜찮은 걸까?
그런데 포인터의 단계가 복잡해지다 보면, const가 있어 봤자 가리키는 놈이 const인지, 나 자신이 const인지 일일이 따지고 추적해서 내부 상태의 불변성을 보장하겠다는 시도가 별 의미가 없어지긴 한다. 즉, this가 this와 *this까지 몽땅 봉인되어서 나 자신의 멤버 값은 변경할 수 없지만.. 내가 가리키는 메모리 영역의 값을 한 단계 거칠 수가 있으며 거기 값을 변경하는 게 가능하다면.. 궁극적으로 그 개체의 속성/상태는 바뀌었다고 볼 수 있기 때문이다.
어떤 코드를 실행해 보지 않고 메모리 접근이 안전한지 입증하는 정적 분석 기능이 만들기 까다로운 것도 본질적으로 이런 이유 때문이다. 컴파일러의 경고가 동작을 예측하고 비정상을 지적해 줄 수 있는 것도 간단한 지역변수 수준일 뿐이지, 몇 단계짜리 포인터에 구조체가 줄줄이 따라오면.. 답이 없다.
거기에다 클래스의 인터페이스 상으로는 Set*이 아니라 Get*처럼 "read-only"이고 값이 변하지 않는 기능만 사용한다고 하더라도, 클래스의 내부 상태는 얼마든지 바뀔 수가 있다. 한번 구해 놓은 계산값을 다음에는 빠르게 되돌리기 위해서 그 값 자체 내지 중간 상태를 캐싱하는 것처럼 말이다. 이런 경우가 워낙 많으니 C++에서는 나중엔 멤버의 const-ness에 예외를 허용하는 mutable 키워드도 도입하지 않을 수 없었다.
이건 마치 고유명사와 보통명사의 경계와도 비슷한 맥락의 문제인 것 같다. 로마자 알파벳이 한글과는 달리 대문자가 있고 고유명사는 첫 글자를 대문자로 적게 돼 있어서 일면 편리한 건 사실이다. 하지만 좀 깊게 생각을 해 보면, 새로운 명칭이 만들어졌을 때 그걸 고유명사로 볼지 기준이 생각만치 엄밀하지는 않은 경우가 많다. 기준이 생각만치 엄밀하지 않으며 그냥 자의적이다. 번역하지 않고 음역하는 놈은 죄다 고유명사인 걸까? 실체가 지구상에 오로지 하나밖에 없는 놈? 그렇다면 실물이 존재하지 않는 무형의 개념은? 그걸 정하는 기준은 무엇?
지금 우리가 보통명사로 별 생각 없이 쓰는 명칭들도 그 명칭이 처음 등장했던 시절엔 첫 글자를 대문자로 적는 유니크한 고유명사이기도 했다. const 개념 구분도, 대소문자 구분도 있건 없건 어느 하나가 다른 하나보다 절대적으로 우월하고 좋은 솔루션은 아니어 보인다는 생각이 든다.
에휴, 클립보드부터 시작해서 유니코드, const 등 별별 이야기가 다 이어져 나왔다. 이상~~ ^^
Posted by 사무엘
