김 용묵의 절대공간 - 블로그

본인이 예전에 글로 썼듯, 비주얼 C++ 201x의 IDE는 소스 코드의 구문 체크 및 인텔리센스를 제공하기 위해 백그라운드에서 완전한 형태의 컴파일러를 실시간으로 돌린다. ncb 파일을 사용하던 200x 시절에는 불완전한 모조 컴파일러였지만 201x부터는 그렇지 않다. 컴파일은 그걸로 하고, 자료 저장은 아예 별도의 DB 엔진으로 하니 계층이 전문화된 셈이다.

그런데 실시간으로 돌리는 컴파일러는, MS가 자체적으로 빌드를 위해 구동하는 컴파일러하고는 다른 별개의 종류이다. 이 개발툴로 오래 개발을 해 본 분은 이미 아시겠지만 같은 문법 에러에 대해서도 메시지가 서로 미세하게 다르고 심지어 문법 해석 방식이 불일치하는 경우도 있다. 마치 MS Office의 리본 UI와 MFC의 리본 UI는 구현체가 서로 별개이고 다르듯이 말이다.

그럼 이 보이지 않는 백그라운드 컴파일러의 정체는 뭘까? 이건 ‘에디슨 디자인 그룹(Edison Design Group)’이라고 유수 프로그래밍 언어들의 컴파일러 ‘프런트 엔드’만 미들웨어 형태로 전문적으로 개발하여 라이선스를 판매하는 어느 벤처기업의 작품이다. MS에서는 이 물건을 구입하여 자기 제품에다 썼다.

컴파일러를 만드는 것은 오토마타 같은 계산 이론부터 시작해서 어려운 자료구조와 알고리즘, 컴퓨터 아키텍처 지식이 총동원되는 매우 까다롭고 어려운 과정이다. 그렇기에 컴파일러는 전산학의 꽃이라 불리며, 대학교 전산학과에서도 4학년에 가서야 맛보기 수준으로만 다뤄진다.

그리고 컴파일 메커니즘은 프런트 엔드와 백 엔드라는 두 단계로 나뉜다. 소스 코드의 구문을 분석하여 문법 오류가 있으면 잡아 내고 각종 심벌 테이블과 parse tree를 만드는 것이 전자요, 이를 바탕으로 각종 최적화를 수행하고 실제 기계어 코드를 생성하는 건 후자이다.

굳이 코드 생성까지 하지 않아도 구문을 분석하여 인텔리센스를 구현하는 것까지는 프런트 엔드만 있어도 충분할 것이다. 프런트 엔드를 담당하는 쪽은 언어의 문법을 직접적으로 다루고 있으니, C++11 표준이 뭐가 바뀌는 게 있는지를 늘 매의 눈으로 감시하고 체크해야 한다. 그리고 그런 엔지니어들이 역으로 표준의 제정에 관여하기도 한다.

에디슨 디자인 그룹은 5명의 베테랑 프로그래머들로 구성된 아주 작은 회사이다. (홈페이지부터 디자인이 심하게 단촐하지 않던가?) 하지만 세계를 움직이는 굴지의 IT 회사들에 자기 솔루션을 납품하고 있다. 작지만 기술이 강한 이런 회사야말로 컴퓨터 공돌이들이 꿈꾸는 이상적인 사업 모델이 아닐 수 없으니 매우 부럽다. 개인이 아닌 기업이나 교육 기관이 고객이며, 한 솔루션의 소스 코드를 납품하는 라이센스 비용은 수만~수십만 달러에 달한다.

마이크로소프트 컴파일러는 인텔리센스만 이 회사의 솔루션으로 구현한 반면,
Comeau C++ 컴파일러는 프런트 엔드가 이것 기반이다. Comeau라 하면, C++의 export 키워드까지 다 구현했을 정도로 표준을 가장 충실하게 따른 걸로 유명한 그 컴파일러 말이다.

굳이 백 엔드와 연결된 컴파일러가 아니어더라도, 프런트 엔드가 만들어 낸 소스 코드 parse tree는 IDE의 인텔리센스를 구현한다거나 소스 코드의 정적 분석, 리팩터링, 심벌 브라우징(browsing), 난독화 등의 용도로 매우 다양하게 쓰일 수 있다. 나름 이것도 황금알을 낳는 거위 같은 기술이라는 뜻이다.

한편, 전세계 유수의 컴파일러들에 C++ 라이브러리를 공급하는 회사는 Dinkumware이라는 걸 난 예전부터 알고 있었다. 헤더 파일의 끝에 회사 설립자인 P.J. Plauger 이름이 늘 들어가 있었기 때문이다. 난독화가 따로 없는 그 암호 같은 복잡한 템플릿들을 다 저기서 만들었다 이 말이지?
비주얼 C++이라는 그 방대한 제품은 당연한 말이지만 모든 부품이 MS 독자 개발은 아니라는 걸 알 수 있다.

그나저나, 비주얼 C++ 201x의 백그라운드 컴파일러는 C 코드에 대해서도 언제나 C++ 문법을 기준으로만 동작하더라.. ㅎㅎ

Posted by 사무엘

IOCCC라고, 사람이 가장 알아 보기 힘들고 충공깽스러운 형태로 작성된 C 프로그램 코드를 접수받는 공모 대회가 있다.
단순 코더가 아니라 전산학 내공과 해커 기질이 충만한 레알 베테랑 프로그래머라면 이미 들어서 알 것이다.

입상작들은 내가 보기에 크게 (1) 아스키 아트형, 아니면 (2) 크기 줄이기 암호형이라는 두 갈래로 나뉜다. 대회에 공식적으로 이런 식으로 참가 부문이 나뉘어 있는 건 아니지만, 여기 참가자들이 추구하는 오덕질의 목표가 대체로 이 둘 중 한 갈래로 나뉘기 때문이다.

전자는 영락없이 아스키 문자로 사람 얼굴이나 문자 같은 그림을 그려 놨는데 그건 컴파일 되는 올바른 C 코드이다. 그뿐만이 아니라 그걸 실행하면 기가 막힌 유의미한 결과물이 나온다. 간단한 게임이라든가 원주율값 계산 같은 것부터 시작해 심지어 CPU 에뮬레이터나 간단한 컴파일러, 운영체제까지 들어있는 경우도 있다.

후자는 수단과 방법을 가리지 않고 길이를 줄이기 위해 들여쓰기, 주석, 헝가리언 표기법 따위는 다 쌈싸먹고 진짜 정체를 알 수 없는 이상한 숫자와 기호와 문자로 범벅이 된 코드인데, 빌드해 보면 역시 소스 코드의 길이에 비해 믿을 수 없는 퀄리티의 동작이 나온다. 자바스크립트 같은 코드를 난독화 처리한 것과 비슷한 형태가 된다.

어떤 언어에서 소스 코드 자신을 출력하는 프로그램을 콰인(Quine)이라고 부른다. GWBASIC이라면 언어에 LIST라는 명령이 있으니 쉽겠지만, 일반적인 컴파일 기반 언어에서는 그걸 만드는 게 보통일이 아니다. 그런데 이 IOCCC 대회 입상작 중에는 A라는 코드가 있는데 그걸 실행하면 B라는 소스 코드가 출력되고, B를 빌드하여 실행하면 C라는 소스 코드가 나오고, 다음으로 C를 빌드하면 다시 A가 나오는... 중첩 콰인을 실현한 충격과 공포의 프로그램도 있었다. 그것도 A, B, C는 다 형태가 완전히 다르고 인간이 인식 가능한 아스키 아트! Don Yang이라는 사람이 만든 2000년도 입상작이다.

역대 수상작들을 보면 프로그래머로서 인간의 창의력과 잉여력, 변태스러움이 어느 정도까지 뻗칠 수 있는지를 알 수 있다. 그리고 이런 대회는 한 프로그래밍 언어의 극악의 면모를 시험한다는 점에서 전산학적으로도 나름 의미가 있다. 들여쓰기와 긴 변수명과 풍부한 주석이 갖춰진 깔끔한 코드든, 저런 미친 수준의 난독화 코드든 컴파일러의 입장에서는 어차피 아무 차이 없는 똑같은 코드라는 게 아주 신기하지 않은가?

다른 언어가 아니라 C는 시스템 레벨에서 프로그래머의 권한이 강력하다. 그리고 전처리기를 제외하면 특정 공백 문자에(탭, 줄바꿈 등) 의존하지 않는 free-form 언어이며, 언어 디자인 자체가 온갖 복잡한 기호를 좋아하는 오덕스러운 형태인 등, 태생적으로 난독화에 유리하다. 게다가 도저히 C 코드라고 볼 수 없을 정도로 코드의 형태와 의미를 완전히 엉뚱하게 뒤바꿔 버리는 게 가능한 매크로라는 비장의 무기까지 있다!

심지어는 C++보다도 C가 유리하다. 함수를 선언할 때 리턴 타입을 생략하고 함수 정의에서는 리턴 문을 생략할 수 있다. 가리키는 대상 타입이 다른 포인터를 형변환 없이 바로 대입할 수 있으며, 또한 인클루드를 생략하고 표준 함수를 바로 사용할 수도 있다. C++이었다면 바로 에러크리이지만, C에서는 그냥 경고만 먹고 끝이니 말이다. C의 지저분한 면모가 결국 더 짧고 알아보기 힘든 코드를 만드는 데 유리하다는 뜻 되겠다.

현업에서는 거의 언제나 C++만 써 와서 잘 실감을 못 했을 뿐이지, C는 우리가 생각하는 것보다 저 정도로 꽤 유연(?)한 언어이긴 하다. IOCCC 참가자의 입장에서 C++이 C보다 언어 구조적으로 더 유리한 건, 아무데서나 변수 선언을 자유롭게 할 수 있다는 것 정도일 것이다.

그러나 겨우 그 정도로는 불리한 점이 여전히 유리한 점보다 더 많은 것 같다. 생성자와 소멸자, 오버로딩, 템플릿 등으로 더 알아보기 힘든 함축적인 코드를 만드는 건 상당한 규모가 있는 큰 프로그램에서나 위력을 발할 것이고, 긴 선언부의 노출이 불가피하여 무리일 듯.

옛날에는 대회 규정의 허를 찌른 엽기적인 꼼수 작품도 좀 있었다.
이 대회는 1984년에 처음 시작되었는데, 그때 입상작 중에는 main 함수를 함수가 아니라 기계어 명령이 들어있는 배열로 선언해 놓은 프로그램이 있었다(1984/mullender). 이건 기계 종류에 종속적일 뿐만 아니라 요즘 컴파일러에서는 링크 에러이기 때문에, 그 뒤부터는 대회 규정이 바뀌어 이식성 있는 코드만 제출 가능하게 되었다.

그리고 1994년에는 콰인이랍시고 0바이트 소스 코드가 출품되었다(1994/smr). 소스가 0바이트이니, 아무것도 출력하지 않아도 콰인 인증..;; 이건 충분히 참신한 덕분에 입상은 했지만 그 뒤부터는 역시 소스 코드는 1바이트 이상이어야 한다는 규정이 추가되었다. 빈 소스 파일을 빌드하려면 빌드 옵션도 좀 미묘하게 변경을 해야 했다고 한다.

이런 코드를 작성하기 위해서는 모든 변수와 함수를 한 글자로 표현하는 것부터 시작해서 평범한 계산식을 온갖 포인터와 비트 연산자로 배배 틀기, 숫자 테이블 대신 문자열 리터럴을 배열로 참고하기(가령, "abcd"[n]) 같은 건 기본 중의 기본 테크닉이다. 그리고 그걸 아스키 아트로 바꾸는 능력이라든가, 원래 오리지널 프로그램을 기가 막히게 짜는 기술은 별개이다. 이런 코드를 만드는 사람은 정말 코딩의 달인 중의 달인이 아닐 수 없다.

이 대회는 전통적으로 외국 해커 덕후들의 각축장이었다. 그러나 지난 2012년도 대회에서는 자랑스럽게도 한국인 입상자가 한 명 배출되었는데, 본인의 모 지인이다. 그가 출품한 프로그램은 영어로 풀어 쓴 숫자를 입력하면(가령, a hundred and four thousand and three hundred and fifty-seven) 그걸 아라비아 숫자로 바꿔 주는 프로그램(104357). 코드를 보면 저게 어딜 봐서 숫자 처리 프로그램처럼 생겼는가. -_-

코드를 대충 살펴보면, long long이 바로 등장하는 데서 알 수 있듯, 나름 32비트 범위를 벗어나는 큰 자리수까지 지원한다. 문자열 리터럴을 배열로 참고하는 것도 곧바로 쓰였음을 알 수 있다.
그리고 옛날의 C 시절에 허용되었던 관행이었다고 하는데, 함수의 인자들을 아래와 같은 꼴로 선언하는 게 이 대회 출품작에서는 종종 쓰인다고 한다.

int func(a,b) int a, char *b; { ... }

하긴, C/C++이 기괴한 면모가 자꾸 발견되는 건 어제오늘 일이 아니다.
a[2]뿐만이 아니라 2[a]도 가능하다든가,
#include 대상으로 매크로 상수도 지정 가능하다든가,
C++의 default argument로 0이나 -1 같은 것뿐만 아니라 사실은 아예 함수 호출과 변수 지정도 가능하다는 것..
switch문의 내부에 for 같은 다른 반복문이 나온 뒤에 그 안에 case가 있다던가..;;

정말 약 빨고 만든 언어에다 약 빨고 코딩한 개발자라고밖에 볼 수 없다.
나로서는 범접할 수조차 없는 이상한 프로그래밍 대회에 한동안 엄청 관심을 갖더니 결국 입상해 버린 그의 오덕력에 경의를 표한다. 그저 놀라울 뿐이다. 이 정도로 소개하고 띄워 줬으니, 그분이 이 자리에 댓글로 소환되는 걸 기대해 보겠다. 아무래도 한국인 다윈 상 수상자가 배출된 것보다는 훨씬 더 자랑스러운 일을 해낸 친구이지 않은가. ㄲㄲㄲㄲㄲㄲㄲ

뭐, 입상했다고 당장 크게 부와 명예가 뒤따르는 건 아니겠지만, 팀장이나 임원이 IOCCC에 대해서 아는 개발자 출신인 회사에 지원할 때 “나 이 대회 입상자요!”라고 이력서에다 써 넣으면 그 이력서의 메리트는 크게 올라갈 수밖에 없을 것이다. 실제로 IOCCC 같은 잉여로운 대회에 참가하는 geek 중에는 구글, MS급 회사 직원도 있고, 사실 이런 대회에 입상할 정도의 guru급 프로그래머가 일자리를 못 구해 걱정할 일은 절대 없을 테고 말이다.

이런 대회에 더 관심 있으신 분은, IOCCC의 국내 저변 확대를 위해 애쓰고 있는 저 친구의 소개 페이지를 참고하시기 바란다.

Posted by 사무엘

지금으로부터 거의 3년 전, 이 블로그가 개설된 지 얼마 되지 않았던 시절에 본인은 C++의 매우 기괴-_-한 문법인 다중 상속과 멤버 포인터(pointer-to-member)에 대해서 제각각 따로 글로 다룬 적이 있었다.
이제 오늘은, 그 기괴한 두 물건이 한데 합쳐지면 언어의 디자인이 얼마나 더 흉악해지는지를 보이도록 하겠다.
그 내력을 알면, C++ 이후의 객체지향 언어에서 다중 상속이 왜 봉인되어 버렸는지를 이해할 수 있을 것이다. 뭐, 이미 다 아는 분도 있겠지만 복습 차원에서.

클래스의 멤버 포인터는 그 가리키는 대상이 변수이냐 함수이냐에 따라서 내부 구조가 크게 달라진다는 말을 예전에 했었다. 함수일 때는 포인터답게 말 그대로 실행될 함수의 메모리 위치를 가리키지만, 변수일 때는 이 멤버가 this로부터 얼마나 떨어져 있는지를 나타내는 정수 오프셋에 불과하다. &POINT::x 는 0, &POINT::y는 4 같은 식.
그래서 비주얼 C++은 x64 플랫폼에서도 단순 클래스의 멤버 변수 포인터는 뜻밖에도 8바이트가 아닌 4바이트로 처리한다. UNT_PTR이 아니라 그냥 unsigned int라고 본 것이다.

그런데 다중 상속이 동반된 클래스는 '단순' 클래스라고 볼 수가 없어지며, 그런 클래스를 대상으로 동작하는 멤버 포인터는 내부 메커니즘이 굉장히 복잡해진다. 멤버 변수야 오프셋이 바뀌니까 그렇다 치지만, 멤버 함수의 포인터도 데이터 오프셋의 영향을 받는다. 비록 함수 자체는 오프셋을 타지 않고 고정된 메모리 주소이긴 하지만, 멤버 포인터가 어느 함수를 가리켜 부르느냐에 따라 그때 그때 this 포인터를 잘 보정해서 줘야 하기 때문이다.

다음 코드를 생각해 보자.
참고로, class 대신 struct를 쓴 이유는 public: 을 따로 써 주는 귀찮음을 해소하기 위해서일 뿐이다. (C#은 struct와 class의 용도가 구분되어 있는 반면, C++은 전혀 그렇지 않으므로.)

struct B {
    int valB; void functionB() { printf("functionB: %p\n", this); }
};
struct C {
    int valC; void functionC() { printf("functionC: %p\n", this); }
};

struct D: public B, public C {
    int valD; void functionD() { printf("functionD: %p\n", this); }
};

그 뒤,

D ob;
void (D::*fp)();
printf("this is %p\n", &ob);
printf("sizeof pointer-to-member is %d\n", sizeof(fp));

fp = &D::functionB; (ob.*fp)();
fp = &D::functionC; (ob.*fp)();
fp = &D::functionD; (ob.*fp)();

코드를 실행해 보면, 놀라운 결과를 볼 수 있다.
이제 fp의 크기가 포인터 하나의 크기보다 더 커졌다.
비주얼 C++ 기준으로, '포인터+int'의 합이 된다. 그래서 x86에서는 8바이트, x64에서는 12바이트.

게다가 중요한 건, functionC를 실행했을 때만 this의 값이 달라져 있다는 것이다.
이건 뭐 다중 상속의 특성상 어쩔 수 없는 면모이며, 멤버 함수를 ob.functionC()라고 직접 호출할 때는 컴파일러가 알아서 처리해 주는 기능이긴 하다.
하지만, 직접 호출이 아니라 멤버 포인터를 통한 간접 호출을 할 때는 이걸 어떻게 구현해야 할까?

결국은 멤버 함수 포인터 자체에 추가 정보가 들어갈 공간이 있어야 하고, 그 정보는 포인터에다가 함수에 대한 대입이 일어날 때 implicit하게 따로 공급되어야 한다.
다중 상속을 받은 클래스의 멤버 함수를 가리키는 포인터는 this 보정을 위한 정수 오프셋이 내부적으로 추가된다. 이제 fp는 단일 포인터 변수라기보다는 구조체처럼 바뀌었다는 뜻이다.

이 fp에다가 functionB나 functionD를 대입하면 그 멤버 함수의 주소만 대입되는 게 아니라, 숨겨진 오프셋 변수에다가도 0이 들어가며(보정할 필요가 없으므로), functionC를 대입하면 그 주소와 함께 오프셋 변수에다가도 0이 아닌 값이 같이 대입된다. 그리고 실제로 fp 호출을 할 때는 this 포인터에다가 보정이 된 값이 함수로 전달된다.

이야기는 여기서 끝이 아니다. 설상가상으로 가상 상속까지 추가된다면?
내가 클래스를 A가 아니라 B에서부터 시작한 게 이것 때문이다. 맨 앞에다가 드디어 다음 코드를 추가하고,

struct A {
    int valA;
    void functionA() { printf("functionA: %p\n", this); }
};

앞에서 썼던 B와 C도 A로부터 가상 상속을 받게 고쳐 보자.

struct B: virtual public A { ... }
struct C: virtual public A { ... }

이것도 물론 추가하고.

fp = &D::functionA; (ob.*fp)();

이렇게 해 보면..
비주얼 C++ 기준 fp의 크기는 더욱 커져서 '포인터+정수 2개' 크기가 된다. x86에서는 12바이트, x64에서는 16바이트.
다중 상속만 있을 때는 함수 말고 변수의 멤버 포인터는 크기가 변함없었던 반면, 가상 상속이 가미되면 변수 멤버 포인터도 이렇게 '크기 할증'이 발생한다. 대입 연산이나 함수 호출 때 몰래 같이 발생하는 일도 더욱 많아지며, 이 현상을 좀 유식하게 표현하면 cost가 커진다.

그 이유는 어렴풋이 유추할 수 있을 것이다. 가상 상속이라는 건 말 그대로 기반 클래스의 오프셋이 클래스의 인스턴스별로 동적으로 변할 수 있다는 뜻이다. this 포인터 보정이 뒷부분 파생 클래스의 정확한 위치를 파악하기 위해서 발생하는 일이라면, 가상 상속 보정은 앞부분 기반 클래스의 위치를 파악하는 것이 목적이다.

이런 사정으로 인해 functionA()도 원래 개체의 주소와는 다른 주소를 받으며, 이것은 functionC()가 받는 주소와는 또 다르다.
다만, pointer-to-member는 가상 함수와는 기술적으로 전혀 무관하게 동작하기 때문에, 가상 함수가 존재하는 클래스라고 해서 오버헤드가 추가되는 건 없다. 함수 멤버 포인터로 가상 함수를 가리키면, 아예 가상 함수 테이블을 참조하여 진짜 함수를 호출하는 wrapper 함수가 따로 만들어져서 그걸 가리키고 있게 된다.

요컨대 비주얼 C++은 단순 클래스, 다중 상속만 있는 클래스, 거기에다 가상 상속까지 있는 클래스라는 세 등급에 따라 멤버 포인터를 관리한다. 다만, 함수가 아닌 변수 멤버 포인터는 가상 상속 여부에 따라 두 등급으로만 나누는 듯하다. 이 정도면, 이 글을 쓰는 본인부터 이제 머리가 핑그르르 도는 것 같다.

이제 마지막으로 생각해 볼 문제가 있다. C++은 클래스의 명칭 선언만 하는 게 가능하다는 점이다.

class UnknownBase;
class UnknownDerived;

굳이 클래스의 몸체를 몰라도 이 클래스에 대한 포인터 정도는 선언이 가능하다. 그렇기 때문에 명칭 선언은 컴파일 때 헤더 파일간의 의존도를 줄이고 모듈간의 독립성을 높일 때 요긴하게 쓰이는 테크닉이다.
다만, 여러 클래스들을 명칭 선언만 하면 이들간의 상속 관계도 아직 밝혀지지 않기 때문에, 실질적인 기반 클래스와 파생 클래스 사이에 암시적인 형변환이나 static_cast, dynamic_cast 따위를 쓸 수 없다는 점도 주의해야 한다.

게다가 이렇게 명칭만 달랑 선언된 클래스에 대해서 멤버 포인터를 선언하면..
컴파일러는 이 클래스가 다중 상속이 존재하는지, 가상 상속이 존재하는지 같은 걸 알지 못한다!
그렇다고 무식하게 에러 처리하며 멤버 포인터의 선언을 거부할 수도 없는 노릇이니,
컴파일러는 가장 보수적으로 이 클래스가 어려운 요소들은 모두 갖추고 있을 거라고 생각하고 가장 덩치 크고 복잡한 등급을 선택할 수밖에 없다.

나중에 사용자가 추가 인클루드를 통해 클래스의 몸체를 선언하여, 이 클래스는 단순한 놈이라는 게 알려지더라도 한번 복잡하게 결정되어 버린 타입 구조는 다시 바뀌지 않는다.
게다가 이렇게 unknown 클래스에 대한 멤버 포인터는 단순히 '가상 상속 클래스' 등급이 아니라, 메타 정보가 추가로 붙는지 비주얼 C++에서는 함수 기준으로 x86에서 무려 16바이트를 차지하며, x64에서는 24바이트를 차지하게 된다. 포인터 둘, int 둘의 합이다.

printf("%d\n", sizeof(void (UnknownDerived::*)() ));

물론, 멤버 포인터부터가 굉장한 레어템인데, 몸체도 없이 명칭 선언만 된 클래스에 대해서 멤버 포인터를 덥석 들이대는 코딩을 우리가 실생활에서 직접 할 일은 극히 드물다. 하지만 딱 machine word와 동일한 크기를 기대했던 멤버 함수 포인터가 3~4배 크기로 갑자기 뻥튀기되고 생각도 못 했던 오버헤드가 추가되는 일은 없어야 하겠기에, 비주얼 C++은 역시 비표준 확장을 통해서 이 문제에 대한 해결책을 제시하고 있다.

그것은 바로 _single_inheritance, _multiple_inheritance, _virtual_inheritance라고 참 길게도 생긴 키워드.
클래스를 명칭 선언만 할 때

class _single_inheritance UnknownDerived;

이런 식으로 써 줌으로써 “이놈은 다중 상속 같은 귀찮은 요소가 없는 클래스이다. 따라서 얘에 대한 멤버 포인터는 추가 오프셋이 없는 제일 간단한 등급으로 만들어도 OK다”라는 힌트를 컴파일러에다 줄 수 있다.
복잡한 놈이라고 예고를 해 놓고 단순한 형태로 클래스를 선언하는 건 괜찮으나, 간단한 놈이라고 예고를 해 놓고 나중에 다중 상속이나 가상 상속을 쓰면 물론 컴파일 에러가 발생하게 된다.

아마 스타크래프트를 만든 사람도 스탑 럴커 같은 전술은 생각을 못 하지 않았을까.
저런 판타지 같은 면모는 C++을 설계한 사람이나 추후에 기능을 확장한 표준 위원회 사람들도 생각을 못 했을 가능성이 높아 보인다.
그렇기 때문에 비주얼 C++처럼 단순, 다중, 가상으로 세 등급을 나눠서 포인터에다 할증 제도를 넣고, 관련 예약어까지 추가한 건 전적으로 표준이 아니라 컴파일러 구현하기 나름이다.

아, 자세한 건 이 사이트 내용을 좀 공부하고 글을 쓰려고 했는데 도저히 다 읽을 엄두가 안 난다.
관심 있는 분들은 알아서 탐독해 보시길.
언뜻 보니, 다중 상속이 멤버 포인터보다 시기적으로 나중에 등장했다. 그래서 둘을 한꺼번에 구현하는 게 이 정도로 복잡하게 꼬인 셈이다.

Posted by 사무엘

1.

C/C++에서 const라는 키워드는 어떤 변수를 선언할 때 타입과 함께 지정해 줄 수 있는 modifier 속성이다. 이와 비슷한 위상인 키워드로 volatile도 있다.

이 const의 큰 의미와 용도는 C와 C++에서 모두 동일하다. 바로, 한번 값이 정해지고 나면 그 뒤로 값이 또 바뀔 수 없다는 걸 뜻한다. 비슷한 용도로 쓰이는 매크로 상수나 enum과는 달리, const 개체는 엄연히 상수 역할을 하는 '변수'이기 때문에 L-value의 특성도 껍데기나마 지니며, 자기 주소를 & 연산자로 얻을 수 있다는 특징이 있다. (자기 주소가 있는데 왜 대입을 못 하니 ㄲㄲㄲ)

그런데 const라는 의미를 언어 차원에서 실현하는 방식이 C는 다소 느슨한 편이다.
C 언어도 const 변수에다가 대놓고 대입 연산자를 들이대는 시도 정도는 컴파일러가 에러로 대응하며 막아 준다. 그러나 강제로 const 속성을 없애는 형변환+포인터 연산 같은 것까지 저지하지는 못한다.

이는 마치, C/C++ 코드에서 변수를 초기화하지 않고 사용하는 걸 간단한 지역 변수 정도는 컴파일러가 알아서 발견하여 경고로 처리해 주지만, 복잡한 배열이나 포인터, 구조체의 경우를 일일이 체크하지는 못하는 것과 비슷한 맥락. 그래서

const int MARK = 100;
const int *p = &MARK;

printf("%d %d\n", MARK, *p);
*const_cast<int *>(&MARK) = 50;
printf("%d %d\n", MARK, *p); //이것이 문제.

이런 코드를 돌려 주면 C에서는 MARK가 처음에는 100이다가 나중에는 50이 되어 버린다! 이런 이유로 인해 C에서 const int는 껍데기만 const이지 case 문의 상수로 쓰이지도 못한다. 아, C 언어는 const_cast라는 연산자가 없으니, 그냥 *((int *)&MARK) = 50; 이라고 해야겠지만 말이다.

허나, C++은 이 정책이 바뀌어서 const를 다루는 방식이 좀 더 엄밀해졌다. 사실, 객체 지향 언어이다 보니 상수값을 취급하는 방식이 더 정확하고 엄밀해져야만 하는 게 마땅하다. 무작정 C 같은 '고수준 어셈블리' 패러다임만 추구해서는 곤란할 터이다.

C++은 MARK 변수가 차지하는 메모리에 들어있는 값과 상관없이 소스 코드에서 MARK가 그대로 쓰인 곳은 언제나 100을 대응시켜 준다. 다시 말해 위의 경우 100과 50이 출력된다. MARK와 *(&MARK)의 값이 달라지는 한이 있더라도 MARK는 언어 차원에서 처음 선언해 준 값이 그대로 유지되며, 진짜 매크로 상수처럼 쓰일 수 있다는 뜻이다. 신기하지 않은가? C와 C++ 사이의 교묘한 차이 중 하나이다. C/C++ 프로그래머라면 이 정도는 이미 아는 분이 많을 것이다.

2.

C/C++은 잘 알다시피 '선언 따로, 정의 따로'라는 좀 원시적이라면 원시적인 디자인 철학을 따르는 언어이다. 그래서 헤더에 들어간 선언은 그 선언을 사용하는 모든 번역 단위들이 include를 “매번” 해 줘야 하고, 그 선언에 대한 정의는 아무 번역 단위에다가 “한 번만” 써 주면 링크 때 알아서 말 그대로 '연결'이 된다. 그렇다, 걔네들은 원래 그런 언어이다.

자바나 C#은 클래스의 선언과 정의가 일심동체이고 그 클래스가 곧 번역 단위이다. 뭐, C++도 클래스를 선언하면서 멤버 함수의 몸체까지 헤더 파일 안에다 같이 써 주는 게 불가능하지는 않지만, 그건 간단한 인라인 함수를 만들 때에나 제한적으로 쓰이는 관행이다. 아니면 어차피 모든 클래스의 몸체가 헤더에 들어가야만 하는 템플릿일 때 정도.

자, 이런 이중적인 구조로 인해 C++은 static 멤버 변수의 정의조차도 클래스의 선언과 동시에 할 수가 없다.
여러 번역 단위에서 매번 인클루드되는 '선언부'에다가 한 번만 등장해야 하는 '정의부'가 동시에 들어갈 수는 없기 때문이다.
자바나 C#은 클래스 안에다가 static int MAX = 100; 같은 문장을 아무렇지도 않게 넣을 수 있으나, C++은 굳이 static int MAX; 와 int CFoo::MAX = 100; 을 분리해서 써 줘야 한다.

그럼, C++의 클래스에서 멤버를 선언할 때 대입 연산자가 들어갈 일이란 오로지 순수 가상 함수를 선언할 때 쓰이는 = 0밖에 없는 걸까? (자바와 C#은 순수 가상 함수는 오히려 pure이나 abstract 같은 키워드를 따로 써서 표현함!)

놀랍게도 그렇지는 않다.
딱 하나 예외적으로, static const라는 속성을 지닌 간단한 '정수 계열'의 멤버는 클래스 안에다 선언과 함께 초기화를 하는 게 가능하다. 즉, 클래스 안에다가 static const int MAX = 100; 정도는 C++도 허용해 준다는 뜻이다.

물론 제약이 몹시 심하다.
static과 const 중 속성이 하나라도 빠져서는 안 된다. 그리고 배열이나 구조체의 초기화는 어림도 없다. static const WCHAR NAME[] = L"foo"; 같은 거 안 된다.

쉽게 말해 정수 정도면, 심벌이 있는 곳의 메모리 주소를 참고하는 게 아니라 심벌의 값 자체를 매번 집어넣어 주는 게 어차피 이득이니까 예외적으로 클래스 내부에서의 정의와 초기화가 허용되는 셈이다. 그러니 static const 정수는 그냥 메모리 주소를 얻는 게 가능한 enum 수준에 불과하다.

정수 계열은 심지어 __int64도 허용되지만 포인터는 허용되지 않는다. 그리고 부동소수점도 안 된다. static const double PI = 3.141592; 는 안 된다는 뜻이다. 이건 현재 GNU 계열 컴파일러에서만 지원하는 extension일 뿐, 표준은 아니다.

3.

한 소스 파일에다가 const 속성을 가진 커다란 정수 테이블 배열을 전역변수 형태로 만들었다. 그건 난수표가 될 수도 있고 time-critical한 실시간 계산 프로그램(게임이라든가)에서는 삼각함수나 로그값 테이블이 될 수도 있고 문자 코드 변환 테이블이 될 수도 있다.

그런데 다른 번역 단위에서는 그 테이블의 명칭을 extern으로 선언해 놓고 참고하여 사용했는데, 링크할 때는 그 명칭을 찾을 수 없다고 에러가 나는 것이었다. 본인은 그 이유를 알 수 없었다. 경험적으로 const 속성을 제거하면 문제를 피해 갈 수 있긴 했으나, 값을 변경하지 않는 상수 테이블을 일반 배열로 취급할 수도 없는 노릇이었다.

링크가 되지 않던 이유를 난 한참 뒤에야 알게 됐다.
C가 아닌 C++에서는 static이나 extern 명시가 없이 const로 선언된 전역변수는 기본적으로 extern이 아니라 static 속성이 부여된다. 그러니 그 번역 단위 내부에서만 쓸 수 있지, 외부로 명칭이 노출되지 않으며, 따라서 링크 에러가 난다.

왜 그렇게 정책이 바뀌었냐 하면 const 개체에 대해서는 이 글의 1번 항목에서 명시한 것과 같은 무결성을 보장하기 위해서인 듯하다.
심벌이 가리키는 메모리 주소는 값이 언제 바뀌어 있을지 모르니, const 개체의 값은 매 번역 단위마다 컴파일러가 소스 코드로부터 읽어들여서 확인하기 위해서이다.

이 조치를 무시하고 const 개체의 값을 다른 번역 단위에서도 사용하려면 extern을 명시적으로 지정해 줘야 한다.

extern const TYPE TABLE = ... 라고 바로 써 줘도 되고, external const TYPE TABLE; 이라고 먼저 선언만 한 뒤에 나중에 const TYPE TABLE = ... 을 쓰면 TABLE은 여느 전역변수와 마찬가지로 다른 번역 단위에서 참조가 가능한 extern 변수가 된다.

4.

Windows 환경에서 개발을 하다 보면 지금 설치되어 있는 운영체제의 SDK에 기본 내장되어 있지 않은 GUID를 수동으로 추가해서 사용해야 할 때가 있다.

GUID는 코드가 아니라 128비트짜리 난수가 들어있는 구조체에 불과하지만, 엄연히 const 전역변수들의 집합이기 때문에 선언부와 정의부가 따로 있다. 그리고 주요 GUID의 실제 값들은 플랫폼 SDK의 라이브러리 디렉터리에 있는 uuid.lib에 들어있다. kernel32, user32, gdi32만큼이나 딱히 우리가 지정을 안 해도 자동으로 링크되는 기본 라이브러리이기 때문에, 파일의 존재감을 모르는 분도 많을 것이다.

그런데 이놈의 GUID 하나 좀 쓰자고 헤더 파일과 소스/라이브러리 파일을 다 구비해 줘야 하는 걸까? 여간 번거로운 일이 아닐 수 없다. 귀찮다고 헤더 파일에다가 GUID 값을 몸체(정의)를 다 써 주면, 이론적으로는 그 헤더를 인클루드하여 사용하는 모든 번역 단위에 동일한 GUID의 몸체들이 obj 파일 내부에 중복 기재될 위험이 있기 때문이다.

결국 이 문제는 MS 컴파일러의 경우 자기만의 언어 확장을 만듦으로써 우격다짐으로 해결했다. DLL 심벌을 만들거나 사용할 때 __declspec(dllexport/dllimport)를 사용하는 것처럼 __declspec(selectany)라는 속성도 있다. 이것이 지정된 전역 변수는 여러 object에서 중첩 기재된 심벌이라도 링크 때 딱 한 몸체만 임의 선택된다.

여러 소스 코드에서 공통으로 쓰이는 GUID를 새로 추가하고 싶으면 #include <initguid.h>를 해 준 뒤, DEFINE_GUID 매크로로 새 GUID의 명칭과 값을 써 주면 된다. 이 매크로는 내부적으로 selectany 지정자를 사용한다.

결국 이것은 전역 변수 선언계의 #pragma once나 마찬가지이다. 중복 인클루드 방지에 이어 심벌 몸체의 중복 링크 방지 마크이다. 이게 다 C/C++에는 간편히 끌어다 쓰는 패키지 개념이 없이, 원시적인 헤더/라이브러리에만 의존하느라 컴파일러 제조사가 부득이 추가한 꼼수인 셈이다.

내가 늘 느끼는 거지만..
C++ 님 좀 짱이다. 10년이 넘게 파 왔지만 아직도 지금까지 몰랐던 사실들이 계속 발견된다.

Posted by 사무엘

1. 들어가는 말: MFC에 대한 큰 그림

MFC는 Windows API를 단순히 C++ 클래스 형태로 재포장만 한 게 아닌 독창적인 기능이 다음과 같이 최소한 세 가지 정도는 있다.

• 가상 함수가 아니라 멤버 함수 포인터 테이블을 이용하여 메시지 핸들러를 연결시킨 메시지 맵. MFC 프로그래머 치고 BEGIN/END_MESSAGE_MAP()을 본 사람이 없다면 간첩일 것이다.
• 운영체제가 제공하는 핸들 자료형들과 C++ 개체를 딱 일대일로 연결시키고, 특히 MFC가 자체적으로 생성하지 않은 핸들이라도 임시로 C++ 개체를 생성해서 연결했다가 나중에 idle time 때 자동으로 소멸을 시켜 주는 각종 handle map 관리자들. 절묘하다.
• 20년도 더 전의 MFC 1.0 시절부터 있었던 특유의 document-view 아키텍처. 상당히 잘 만든 디자인이다.

양념으로 CPoint, CRect, CString 같은 클래스들도 편리한 물건이긴 하지만, 그건 너무 간단한 거니까 패스.

사실, MFC는 Windows API를 객체지향적으로 재해석하고 포장한 수준은 그리 높지 않다. 본디 API가 prototype이 구리게 설계되었으면, MFC도 해당 클래스의 멤버 함수도 똑같이 구린 prototype을 답습하고 내부 디테일을 그대로 노출했다.

이와 관련하여 내가 늘 드는 예가 하나 있다. 당시 경쟁작 라이브러리이던 볼랜드의 OWL은 radio button과 check button을 별도의 클래스로 분리했다. 그러나 MFC는 그렇게 하지 않았다. 운영체제 내부에서 둘은 똑같은 버튼 윈도우이고 스타일값만 다를 뿐이기 때문이다. 그러니 MFC로는 동일한 CButton이다. 그리고 CStatic도 마찬가지.
아마 기존 응용 프로그램의 포팅을 용이하게 하려고 의도적으로 이런 식으로 설계한 것 같긴 하지만, 이것 때문에 MFC를 비판하는 프로그래머도 물론 적지 않았던 게 사실이다.

그러나 인간이 하루 하루 숨만 쉬고 똥만 만드는 기계가 아니듯, MFC는 단순한 API 포장 껍데기가 아니라 다른 곳에서 더 수준 높은 존재감을 보여준다. 오늘 이 글에서는 document-view 아키텍처 쪽으로 얘기를 좀 해 보겠다.

2. view가 일반적인 윈도우와 다른 점

MFC는 뭔가 문서를 생성하여 작업하고 불러오거나 저장하는 일을 하는 업무용 프로그램을 만드는 일에 딱 최적화되어 있다. 그렇기 때문에 MFC AppWizard가 FM대로 생성해 주는 기본 코드는 아주 간단한 화면 데모 프로그램만 만들기에는 구조가 필요 이상으로 복잡하고 거추장스러워 보인다.
그냥 프레임 윈도우의 클라이언트 영역에다 바로 그림을 그려도 충분할 텐데 굳이 그 내부에 View라는 윈도우를 또 만들었다. 그리고 View는 Document 계층과 분리돼 있기 때문에, 화면에 그릴 컨텐츠는 따로 얻어 와야 한다.

이런 계층 구분은 소스 코드가 몇십~몇백만 줄에 달하는 전문적인 대형 소프트웨어를 개발할 걸 염두에 두고 장기적인 안목에서 해 놓은 것이다.
먼저, View와 Document를 구분해 놓은 덕분에, 동일한 Document를 여러 View가 자신만의 다양한 설정과 방법으로 화면에 동시에 표시하는 게 가능하다. 텍스트 에디터의 경우, 한 문서의 여러 지점을 여러 창에다 늘어놓고 수시로 왔다 갔다 하면서 편집할 수 있다. 한 창에서 텍스트를 고치면 수정분이 다른 창에도 다같이 반영되는 것이 백미.

일례로, MS 워드는 기본, 웹, 읽기, 인쇄, 개요 등 같은 문서를 완전히 다른 방식으로 렌더링하는 모드가 존재하지 않던가(물론, MS 워드가 MFC를 써서 개발됐다는 얘기는 아님). 게다가 이 중에 실제로 위지윅이 지원되고 장치 독립적인 레이아웃이 사용되는 모드는 인쇄 모드뿐이다. 인쇄를 제외한 다른 모드들은 인쇄 모드보다 문서를 훨씬 덜 정교하게 대충 렌더링하는 셈이다.

이렇듯, view는 그 자체만으로 독립성이 충분한 특성을 가진 계층임을 알 수 있다. view는 프레임 윈도우와도 분리되어 있는 덕분에, 한 프레임 윈도우 내부에 splitter를 통해 하위 view 윈도우가 여러 개 생성될 수도 있다.
CWnd의 파생 클래스인 CView는 윈도우 중에서도 바로 저런 용도로 쓰이는 윈도우를 나타내는 클래스이며, 부모 클래스보다 더 특화된 것은 크게 두 가지이다. 하나는 CDocument와의 연계이고 다른 하나는 화면 출력뿐만 아니라 인쇄와 관련된 기능이다.

SDI형 프로그램에서는 view 윈도우 자체는 계속 생성되어 있고 딸린 document만 수시로 바뀌기 때문에, document를 처음 출력할 때 view가 추가적인 초기화를 하라고 OnInitalUpdate라는 유용한 가상 함수가 호출된다. 그리고 화면 표시와 프린터 출력을 한꺼번에 하라고 WM_PAINT (OnPaint) 대신 OnDraw라는 가상 함수가 호출된다. 하지만 프린터 출력이 화면 출력과 기능면에서 같을 수는 없으니 CDC::IsPrinting이라든가 OnPrepareDC 같은 추가적인 함수도 갖고 있다.

그러고 보니 MFC의 view 클래스는 운영체제에 진짜 존재하는 '유사품' 메시지인 WM_PRINT 및 WM_PRINTCLIENT와는 어떻게 연계하여 동작하는지 모르겠다. 화면의 invalidate 영역과 긴밀하게 얽혀서 BeginPaint와 EndPaint 함수 호출을 동반해야 하는 WM_PAINT와는 달리, PRINT 메시지는 invalidate 영역과는 무관하게 그냥 창 내용 전체를 주어진 DC에다가 그리면 된다는 차이가 존재한다. 거의 쓰일 일이 없을 것 같은 메시지이지만, AnimateWindow 함수가 창 전환 효과를 위해 창 내용 이미지를 미리 내부 버퍼에다 저장해 놓을 때 꽤 유용하게 쓰인다.

3. CView의 파생 클래스들

MFC에는 CView에서 파생된 또 다른 클래스들이 있다. 유명한 파생 클래스 중 하나인 CCtrlView는 MFC가 자체 등록하는 클래스 말고 임의의 클래스에 속하는 윈도우를 그대로 view로 쓰게 해 준다.
그래서 운영체제의 시스템 컨트롤을 view로 사용하는 CTreeView, CListView, CEditView, CRichEditView 등등은 다 CCtrlView의 자식들이다.

• 프로그램의 클라이언트 영역에다 CTreeView와 CListView를 splitter로 나란히 배열하면 '탐색기' 내지 레지스트리 편집기 같은 외형의 프로그램을 금세 만들 수 있다.
• <날개셋> 편집기가 MFC를 써서 개발되던 버전 2.x 시절에는 문서 창을 CCtrlView로부터 상속받아 만들었다.

CCtrlView 말고 CView의 또 다른 메이저 파생 클래스로는 CScrollView가 있다. 얘는 이름에서 유추할 수 있듯, view에다가 스크롤과 관련된 기본 구현들이 들어있다. 텍스트 에디터 같은 줄 단위 묶음 스크롤 말고, 픽셀 단위로 컨텐츠의 스크롤이 필요한 일반 워드 프로세서, 그래픽 에디터 같은 프로그램의 view를 만들 때 매우 유용하다. 마우스 휠과 자동 스크롤 모드(휠 클릭) 처리도 다 기본 구현돼 있다.

인쇄 미리 보기 기능은 온몸으로 scroll view를 써 달라고 외치는 기능이나 다름없으며, 실제로 MFC가 내부적으로 구현해 놓은 '인쇄 미리 보기' view인 CPreviewView 클래스도 CScrollView의 자식이다.
단, 요즘은 Ctrl+휠을 굴렸을 때 확대/축소 기능도 구현하는 게 대세인데 배율까지 관리하는 건 이 클래스의 관할이 아닌 듯하다. 그건 사용자가 직접 구현해야 한다.

그럼 스크롤 가능한 view로는 오로지 자체 윈도우만 설정할 수 있느냐 하면 그렇지는 않다. CFormView는 대화상자를 view 형태로 집어넣은 클래스인데 그냥 CView가 아니라 CScrollView의 파생 클래스이다. 워낙 설정할 게 많아서 환경설정 대화상자 자체가 세로로 쭈욱 스크롤되는 프로그램은 여러분의 기억에 낯설지 않을 것이다.

옛날에 윈도우 3.x 시절의 PIF 편집기처럼 클라이언트 영역에 대화상자 스타일로 각종 설정을 입력 받는 게 많은 프로그램을 만들 때 CFormView는 대단히 편리하다. 대화상자는 여느 윈도우들과는 달리, 자식으로 추가된 컨트롤들에 대해 tab 키 순환과 Alt+단축키 처리가 메시지 처리 차원에서 추가되어 있다.

4. CScrollView 다루기

처음에는 CView로부터 상속받은 view를 만들어서 프로그램을 열심히 만들고 있다가, 뒤늦게 view에다가 스크롤 기능을 추가해야 할 필요가 생기는 경우가 종종 있다.
이미 수많은 프로그래밍 블로그에 해당 테크닉이 올라와 있듯, 이것은 대부분의 경우 base class를 CView에서 CScrollView로 문자적으로 일괄 치환하고 몇몇 추가적인 코드만 작성하면 금세 구현할 수 있다.

클래스 이름을 치환한 뒤 가장 먼저 해야 할 일은 스크롤의 기준이 될 이 view의 실제 크기를 SetScrollSizes 함수로 지정해 주는 것이다. OnInitialUpdate 타이밍 때 하면 된다. 안 해 주면 디버그 버전의 경우 아예 assertion failure가 난다.

여기까지만 하면 반은 먹고 들어간다. OnDraw 함수의 경우, 전달되는 pDC가 아예 스크롤 기준대로 좌표 이동이 되어 있다! 즉, 내부적으로 (30, 50) 위치에다가 점을 찍는 경우, 현재 스크롤 시작점이 (10, 20)으로 잡혀 있으면 화면상으로 이 위치만치 뺀 (20, 30)에 점이 찍힌다는 뜻이다. 내가 수동으로 스크롤 좌표 보정을 할 필요가 없다. 아, 이 얼마나 편리한가! invalid 영역의 좌표도 화면 기준이 아닌 내부 기준으로 다 이동된 채로 전달된다.

그러니 CView 시절에 짜 놓은 그리기 코드를 어지간하면 수정 없이 CScrollView에다 곧바로 써먹을 수 있다. 다만, 최적화만 좀 신경 써 주면 된다. 당장 화면에 표시되는 영역은 수백 픽셀에 불과한데 수천 픽셀짜리의 전체 그림을 몽땅 불필요하게 계산해서 그리는 루틴을 OnDraw에다 때려박지 않도록 주의해야 한다.
이때 유용한 함수는 RectVisible이다. 이 영역이 invalidate되었기 때문에 반드시 그려 줘야 하는지의 여부를 알 수 있다.

그 다음으로 신경을 좀 써야 하는 부분은 마우스 클릭이다.
마우스 좌표는 화면 기준으로 오지 내부 기준으로 오지는 않으므로, 내부 개체에 대한 hit test를 하려면 마우스 좌표에다가 GetScrollPosition(현재 스크롤 위치) 함수의 값을 더하면 된다.
그리고 화살표 키로 무슨 아이템을 골랐다면, 그 아이템의 영역이 지금의 화면 범위를 벗어났을 경우 스크롤을 시켜 줘야 한다. 수동 스크롤은 ScrollToPosition 함수로 하면 된다.

화면의 일부 영역을 다시 그리도록 invalidate하는 것도 스크롤 위치 반영이 아닌 그냥 지금 화면 기준의 좌표를 지정하면 된다. 그러면 OnDraw 함수에서는 스크롤 위치가 반영된 내부 좌표 기준으로 refresh 위치가 전달된다.

끝으로, 마우스로 어떤 개체나 텍스트를 눌러서 끌든, 혹은 단순 selection rectangle을 만들든 그 상태로 포인터가 화면 밖으로 나갔을 때, 타이머를 이용한 자동 스크롤도 구현해야 할 것이다. 이 역시 자동화하기에는 customization의 폭이 너무 넓기 때문에 MFC가 알아서 해 주는 건 없다. 알아서 구현할 것. 이 정도면 이제 스크롤 기능을 그럭저럭 넣었다고 볼 수 있을 것이다.

이 정도면 어지간한 개발 이슈들은 다 나온 것 같다.
참, 혹시 재래식 GDI API가 아니라 GDI+를 쓰고 있는 프로젝트라면 CScrollView로 갈아타는 걸 신중히 해야 할 것 같다. GDI+는 MFC가 맞춰 놓은 GDI 방식의 기본 스크롤 좌표를 무시하고 DC의 상태를 난장판으로 만들어 버리기 때문이다. GDI+는 재래식 GDI보다 느리지만 곡선의 안티앨리어싱과 알파 블렌딩이 뛰어나니 아무래도 종종 사용되게 마련인데..

간단한 해결책 중 하나는, GDI+ 그래픽은 CreateCompatibleDC / CreateCompatibleBitmap을 이용한 메모리 DC에다가 따로 그리고, 본디 화면에다가는 그 결과를 Bitblt로 뿌리기만 하는 것이다. 그렇게 하면 아무 문제가 발생하지 않고, 심지어는 속도도 내 체감상으로는 더 빨라지는 것 같다.

Posted by 사무엘

1. 메뉴 -- 긴 역사를 자랑하는 GUI 구성요소

'메뉴'(menu)라는 단어는 순우리말로는 흔히 차림표라고 하고, 식당의 음식 메뉴 아니면 컴퓨터 소프트웨어의 GUI 요소라는 꽤 이질적인 두 심상이 결합해 있는 독특한 단어이다. 이런 점에서 '메뉴'는 '마우스'하고도 비슷한 구석이 있는 것 같다.

메뉴는 GUI라는 개념이 컴퓨터에 도입된 이래로 굉장히 오랜 시간을 인간과 함께해 왔다. 워낙 중요하고 필수적인 기능이기 때문에 Windows 운영체제는 아예 API 차원에서 창을 하나 만들 때 메뉴 핸들을 같이 넘겨 줄 수 있게 돼 있다. (CreateWindowEx 함수) Windows는 그래도 보급 메뉴(?) 지원을 무시하고 GUI 툴킷이 자체 구현한 싸제 메뉴를 붙일 여지라도 있지만, Mac OS는 메뉴 bar가 무조건 화면 위에 붙박이로 고정이고 게다가 운영체제의 시스템 메뉴와 일심동체로 통합되어 있기 때문에 싸제 메뉴 같은 건 있을 수 없다.

물론, 너무 무난하고 밋밋한 관계로 요즘 만들어지는 응용 프로그램에서는 메뉴가 천덕꾸러기처럼 취급되는 면모가 없지는 않다. 메뉴+툴바가 리본 UI로 대체된 것은 물론이고, 메뉴가 있더라도 메뉴 bar를 평소에는 감춰 버리고 Alt키를 눌러야만 마지못해 보여 준다. 글쎄, 이러다가 나중에 또 복고풍으로 메뉴로 돌아가지는 않을지?
그리고 어떤 경우든 사각형 안에서 선택막대로 기능을 선택하는 전통적인 메뉴 개념 자체가 없어지는 일은 없을 것이다.

난 닷넷 프레임워크는 그냥 운영체제의 보급 메뉴를 자기 고유 API로 감쌌는줄 알았는데, 그렇지 않다는 걸 알게 되어 개인적으로 놀란 적이 있다. 닷넷 기반 GUI 프로그램은 기본적으로 Office XP 스타일을 적당히 따라 한 싸제 메뉴가 나온다.

보급이든 싸제든, 어쨌든 GUI에서 전통적인 메뉴는 F10을 눌렀을 때 화면 상단에 나타나는 가로줄 메뉴, 혹은 main 메뉴를 가리키는 경우가 많다.
그러나 이것 외에 어떤 개체를 마우스로 우클릭했을 때 나타나는 Context 메뉴, 혹은 팝업 메뉴는 좀 더 나중에, 1990년대 중반에 도입되었다. 윈도우 95 이전에 3.x 시절에는 그림판으로 두 색깔을 번갈아가며 쓸 때 말고는 마우스를 우클릭할 일 자체가 거의 없었던 것 같다. 팝업 메뉴를 띄우는 기능 자체는 3.x 시절에도 있었을 텐데도 불구하고 말이다.

2. HMENU

자, 그럼 Windows 플랫폼 프로그래밍의 관점에서 운영체제의 메뉴 개체에 대해서 좀 더 살펴보자.

이 메뉴라는 놈을 관리하는 개체는 바로 HMENU이다. 얘는 메뉴에 표시시킬 각종 아이템들과 그것들의 상태들을 보관하고 있는 일종의 연결 리스트의 포인터라고 생각하면 된다. 어떤 메뉴 항목에는 또 부메뉴가 딸려 있을 수 있으므로 메뉴는 일종의 재귀성까지 갖추고 있다.

메뉴는 잘 알다시피 리소스의 형태로 쉽게 만들어 내장시킬 수도 있다. 그러나 HMENU 값은 아이콘이나 액셀러레이터, 마우스 포인터 같은 여타 리소스들과는 달리, read-only 리소스가 아니다. 이게 무슨 말인지 배경을 좀 설명하자면 이렇다.

16비트 Windows 시절에는 EXE/DLL에 있는 리소스 데이터를 얻기 위해서 별도로 파일을 열고 메모리를 할당하고 고정하는 등의 절차가 필요했다. 그러나 운영체제가 32비트 환경으로 바뀌면서 실행 파일의 로딩 방식이 memory mapping 방식으로 바뀌었기 때문에, 모듈에 내장된 리소스를 찾는 건 그냥 이미 로딩된 메모리의 주소만 되돌리는 형태로 아주 간단해졌다.

그래서 예전과는 달리, 이제는 한번 fetch해 온 리소스 데이터에 대해서 FreeResource 같은 함수를 호출할 필요가 없어졌다. 그 리소스를 제공하는 EXE의 실행이 종료되거나 DLL이 Unload될 때 어차피 자동으로 한꺼번에 해제되기 때문이다.

일반적인 읽기 전용 리소스는 그런 간소화의 혜택을 입게 되었다.
그러나 메뉴의 경우는 모듈에 내장된 메뉴 데이터의 포인터만 얻어 오는 걸로 끝이 아니라, 그 데이터를 토대로 메뉴 연결 리스트를 별도로 재구성한다. 사용자는 그 연결 리스트의 데이터를 변경함으로써 메뉴에 별도의 항목을 추가하거나 삭제하고, 체크 표시나 disable 처리를 할 수 있다.

그렇기 때문에 LoadIcon, LoadCursor 등의 리턴값은 Free를 할 필요가 없지만, LoadMenu 핸들의 리턴값은 반드시 DestroyMenu를 해 줘야 한다. (물론, 아이콘 같은 리소스라 해도 모듈 내장이 아니라 직접 동적으로 생성한 놈이라면 Destroy*함수를 호출해서 수동으로 소멸해야 하는 건 변함없음.)

HMENU는 내부적으로 딱히 reference counting을 하지는 않는 단순한 구조이다.
윈도우와 연결되어 있는 메뉴는 윈도우가 소멸될 때 같이 자동으로 소멸되며(물론 부메뉴들도 재귀적으로 다 같이), 한 메뉴 인스턴스가 여러 윈도우에서 공유되지는 않는다. '이동', '닫기' 같은 명령이 있는 시스템 메뉴가 있는데, 필요하다면 사용자가 이 메뉴 역시customize할 수 있다.

3. API 디자인

(1) Windows API의 설계 관점에서 흥미로운 것은, 정수로 식별하는 ID를 받는 곳에다가 필요에 따라 메뉴 핸들도 같이 집어넣게 한 게 종종 보인다는 점이다.
CreateWindowEx 함수의 경우, HMENU는 생성하려는 윈도우가 팝업 같은 메이저 윈도우이면 메뉴 핸들이고, 메뉴를 갖는 게 의미가 없는 자그마한 마이너 자식 윈도우이면 정수 ID를 의미한다.

물론 메뉴 핸들과 ID가 동시에 쓰일 일은 없는 건 사실이다. 윈도우의 ID는 대화상자의 차일드 컨트롤들을 식별할 때에나 쓰는 것이니 말이다.
하지만 어째 이 둘을 실제로 공유시킬 생각을 했는지 궁금하다. 어지간하면 그냥 내부 구조체에다 별도의 멤버를 따로 둘 법도 한데, Windows 1.x 시절의 헝그리 정신을 살려, 메모리 절약을 위해 공용체를 썼는가 보다.

또한 메뉴 API도 AppendMenu나 InsertMenu를 보면, 일반 메뉴 아이템에 대해서는 명령 ID를 전달하는 항목에, MF_POPUP이 지정된 하위 메뉴 아이템에 대해서는 또 HMENU를 typecast하여 전달하게 되어 있다.

(2) CreateMenu와 CreatePopupMenu 함수를 왜 따로 만들어 놨는지 영 이해가 안 된다. HINSTANCE와 HMODULE만큼이나 사실상 의미 없는 구분이 돼 있다.
응용 프로그램의 main 메뉴나 우클릭 팝업 메뉴는 화면에 보이는 형태만 다를 뿐, 부메뉴를 가질 수 있는 재귀적인 형태인 것도 똑같고 내부 자료 구조가 달라야 할 것은 없다.
하긴, 그러고 보니 HCURSOR도 HICON하고 내부적으론 거의 같은 자료구조라고 하지. (핫스팟 위치만 추가됐을 뿐)

(3) 메뉴의 상태를 나타낼 때 MF_GRAYED와 MF_DISABLED를 따로 만들어 놓은 건 개인적으로 무척 기괴하게 여겨진다.
MF_GRAYED는 우리가 흔히 보는 '사용할 수 없는' 메뉴 아이템이다. 흐리게 표시되고 선택도 되지 않는다. 그러나 MF_DISABLED는 선택만 안 될 뿐 흐린 표시는 아니다.
이건 솔직히 말해서 잉여력이 넘치는 구분이다.

그래서 심지어는 MS 내부의 개발자들조차도 이를 혼동해 있다.
고전 테마를 쓰고 있을 때는 MF_DISABLED를 설정한 메뉴가 '일반 글자'로 표시된다.
그러나 Luna나 Aero 같은 테마가 적용되어 있을 때는 이게 MF_GRAYED와 동일하게 '흐린 글자'로 표시된다! 문서화된 바와도 다르고 일관성 없게 동작한다는 뜻이다. 내 말이 믿어지지 않으면 당장 프로그램을 짜서 확인해 보기 바란다.
일상생활에서는 MF_DISABLED는 전혀 신경 쓸 필요 없고 MF_GRAYED만 쓰면 될 것 같다.

(4) RemoveMenu, DeleteMenu, DestroyMenu의 차이가 뭘까?
먼저 DestroyMenu는 HMENU 자체를 완전히 소멸시키는 함수이다. 메뉴와 부메뉴들이 모두 다 사라지고 해당 핸들은 사용할 수 없게 된다.
RemoveMenu와 DeleteMenu는 메뉴 안에 있는 한 항목을 제거한다. 제거할 항목을 순서 인덱스 또는 명령 ID로 지정할 수 있다. 부메뉴를 가진 항목이나 항목 구분용 separator는 명령 ID를 갖고 있지 않으므로 반드시 순서 인덱스만 지정 가능할 것이다.

둘의 차이는 딱 하나. 부메뉴를 가진 항목을 지울 때 부메뉴 핸들을 재귀적으로 destroy하느냐(Delete) 안 하느냐(Remove)이다. 마치 '프로젝트 목록에서 파일 제거'와, '파일 제거 + 실제로 디스크 상에서도 삭제'의 차이와 비슷한 맥락이다.

(5) 사실, Windows의 메뉴 API가 좀 더 객체지향적으로 설계되었다면, HMENU뿐만 아니라 각각의 메뉴 아이템을 나타내는 HMENUITEM 같은 자료형도 또 만들었을 것이다.
지금은 그렇지 않기 때문에 메뉴 아이템을 식별할 때마다 매번 HMENU와 UINT nID, 그리고 nID가 명령 ID인지, 순서 인덱스인지를 나타내는 플래그를 넘겨줘야 한다. 메뉴 항목을 편집하거나, 어디 뒤에 삽입하거나 삭제하는 함수들이 전부 저 인자들을 일일이 받는다. 내가 보기엔 무척 지저분하다.

또한 동일한 기능을 하는 API가 구 API, 그리고 좀 더 기능이 확장되고 구조체를 인자로 받는 신 API가 섞여서 중구난방스러운 것도 어쩔 수 없는 일이다. 가령, 예전에는 CheckMenuItem 같은 함수가 있었지만 지금은 SetMenuItemInfo가 있는 식. 새로운 함수는 범용적이긴 하지만 매번 구조체를 만들어서 초기화해 주는 작업이 몹시 성가신 것도 사실이다.

32비트 Windows부터는 각각의 메뉴 아이템에 대해서 명령 ID와는 별개로 임의의 UINT_PTR 데이터 값을 갖는 게 가능해졌다. 마치 리스트박스에서 item data와 비슷한 맥락이다. 이 값을 읽고 쓰는 함수로 지저분하게 SetMenuItemData 같은 함수를 또 추가하느니, 차라리 메뉴와 관련된 모든 속성을 읽고 쓸 수 있는 SetMenuItemInfo라는 종결자 함수를 만들게 됐을 것이다.

Posted by 사무엘

1.

본인은 비주얼 C++ 2012로 갈아탄 뒤부터 예전에는 본 적이 없는 이상한 현상을 겪곤 했다. 내가 만들고 있는 프로그램을 IDE에서 곧장 실행하자(Ctrl+F5 또는 F5) 프로세스는 분명히 실행되어 있는데 창이 화면에도, 작업 표시줄에도 전혀 나타나 보이지 않았다.

Spy++를 돌려 보니 프로그램 창이 생기긴 생겼는데 어찌 된 일인지 WS_VISIBLE 스타일이 없이 숨겨져 있다는 걸 알게 되었고, 문제의 원인은 생각보다 금방 발견할 수 있었다.
프로세스에 전달되는 STARTUPINFO 구조체의 wShowWindow 멤버 값은, dwFlags에 STARTF_USESHOWWINDOW 플래그가 있을 때에만 유효하다는 걸 깜빡 잊고 있었던 것이다.

일반적으로 프로그램을 실행할 때 운영체제가 그 구조체에다 ShowWindow 플래그를 안 넣는 적은 사실상 없기 때문에 지금까지 그 로직이 별로 문제가 되지 않았었다. 하지만 비주얼 C++ 2012는 이례적으로 그 구조체의 거의 모든 멤버들을 그냥 0으로만 집어넣은 채 프로세스를 생성하고, 0은 SW_HIDE와 같기에 창이 화면에 나타나지 않았다.

2.

<날개셋> 한글 입력기 외부 모듈을 debug 형태로 빌드한 뒤 디버거를 붙여서 실행해 보면, 때에 따라서는 호스트 프로세스가 종료될 때 memory leak 로그가 뜨는 경우가 종종 있었다. 하지만 이것이 항상 나타나는 건 아니고 leak의 양이 심각하게 많은 건 아니었기 때문에, 본인은 크게 신경 쓰지는 않았다.

그런데 우연히 추가 디버깅을 한 결과, 응용 프로그램에 따라서 아예 COM 개체들의 reference count가 달라지고 TSF 모듈의 소멸자 함수의 실행 여부가 달라지는 걸 발견하였고, 이에 본인은 이 현상에 대해 좀 더 심혈을 기울여 디버깅을 실시하게 되었다.

이건 꽤 특이한 현상이었다. <날개셋> 편집기에서도 leak이 발생했기 때문에 가장 먼저 'TSF A급 지원' 옵션을 꺼 봤다. 그리고 외부 모듈은 아예 날개셋 커널을 로딩하지 않고 아무 기능도 사용할 수 없는 panic 상태로 구동했다. 그렇게 프로그램의 주요 기능들을 다 끄고 절름발이로 만들었는데도 <날개셋> 외부 모듈을 한 번이라도 로딩을 하고 나면 leak이 없어지지 않았다.

이런 식으로 COM 오브젝트의 reference count가 꼬이는 버그는 여간 골치 아픈 문제가 아니기에 각오 단단히 하고 디버깅을 계속할 수밖에 없었다. 그 결과 무척 신기한 점을 발견했다. MFC를 사용하는 GUI 프로그램과, MFC든 무엇이든 대화상자(DialogBox)를 사용하는 프로그램에서는 leak이 안 생기는데, Windows API로 message loop을 직접 돌리면서 윈도우를 구동하는 프로그램에서는 memory leak이 발생한다는 것이었다.

오히려 방대하고 복잡한 MFC를 쓰는 프로그램에서 메모리가 새면 샜지, 왜 더 간단한 프로그램에서 문제가 발견되는 걸까?
이 정도까지 밝혀지니 궁금해 미칠 지경이 됐다. leak이 있는 프로그램과 없는 프로그램을 종료할 때 외부 모듈 개체의 Release 함수가 어떻게 호출되고 reference count가 어떻게 변하는지를 검토했다.

그리고 드디어 leak이 있는 프로그램과 없는 프로그램의 차이가 밝혀졌다.
MFC는 프로그램 창이 WM_CLOSE 메시지를 받아서 창의 소멸 단계로 들어서기 전에, 프로그램 창을 강제로 한번 감춰 주고 있었다( ShowWindow(SW_HIDE) ). CFrameWnd::OnClose()에서 CWinApp::HideApplication을 호출함. 이걸 함으로써 운영체제의 TSF 시스템 내부는 객체에 대한 Release가 일어나고 메모리 해제가 완전히 이뤄졌다. 소스가 없는 대화상자도(DialogBox 함수) 잘은 모르지만 종료될 때 비슷한 call stack을 갖는 Release 호출이 있었다.

그 반면 창이 없어질 때 따로 별다른 처리를 하지 않는 프로그램에서는 외부 모듈 개체의 reference count가 1 남게 되었고, 이것이 memory leak으로 이어졌다. MS에서 직접 만든 다른 입력 프로그램들도 마찬가지다. 도대체 왜 그럴까?.

MFC가 WM_CLOSE에서 자기 창을 감추는 이유는 그냥 자식 윈도우들이 순서대로 닫히는 모습이 사용자에게 티가 나 보이지 않게 하고, 겉보기로 창이 당장 없어져 버렸으니 프로그램 종료에 대한 사용자 반응성을 향상시키려는 목적으로 보인다. 그게 반드시 필수는 아니다. 내가 보기에 그렇게 하지 않는 게 잘못이라 볼 수는 없다.

OS별로 살펴보니, 이런 leak은 윈도우 XP와 비스타에서는 없었다가 그 후대인 7과 8에서 생겼다. 즉, XP/Vista에서는 hide를 안 해 줘도 원래 leak이 없는데 7부터는 hide를 해 줘야 한다는 뜻. 아무튼 난 여러 모로 윈7의 문자 입력 체계가 별로 마음에 안 든다. 이쪽 부분 담당자가 갑자기 바뀌었는지, 혹은 대대적인 리팩터링을 한 후유증이기라도 한지 자잘한 버그들이 너무 많이 들어갔기 때문이다.

결국 이것은 IME 문제가 아니라 운영체제 내지 응용 프로그램의 문제라는 결론을 내리고 편집기의 소스를 고쳤다. 문제를 피해 가는 법을 발견하긴 했으나 뒷맛이 개운하지 못하다.

* Windows 환경에서의 4대 디버깅 도구와 테크닉

• 문자열을 printf 스타일로 포맷하여 OutputDebugString 함수로 전달하는 TRACE 함수 (디버거 로그)
• 별도의 디버거 로그가 아니라 그냥 화면 desktop DC에다가 로그를 찍는 깜짝 함수
• 프로그램이 특이한 환경에서 뻗을 때 call stack을 확인할 수 있는 miniDumpWriteDump와 SetUnhandledExceptionFilter 함수
• memory allocation number에다가 breakpoint를 거는 _crtBreakAlloc 변수. 정체불명의 memory leak 잡을 때 필수

Posted by 사무엘

마이크로소프트 Windows라는 운영체제는 GUI 요소인 '창'(window)에서 모티브를 따서 작명되었다. 그 이름이 암시하듯, Windows는 창을 만들고 제어하는 것이 프로그래밍에서 큰 비중을 차지하며, 창과 창끼리의 의사소통은 메시지라는 놈을 통해서 행해진다. 이건 프로그래머라면 이미 다 잘 아는 내용일 것이다.

메시지는 굳이 GUI를 만들지 않더라도 응용 프로그램간에 데이터를 공유하고 스레드 동기화가 갖춰진 통신을 하는 데 상당히 유용한 수단이다. 오늘날 같은 보호 모드 멀티태스킹/멀티스레드 환경에서도 과거의 16비트 시절 같은 직관적인 통신 메커니즘을 제공하기 위해 운영체제가 밑에서 알아서 신경 써 주는 게 많기 때문이다. 그래서 그 기능만 쓰라고 message-only 윈도우라는 것도 있다.

메시지는 자신이 어떤 메시지인지를 나타내는 정수와, 덧붙일 수 있는 추가 숫자 정보 두 종류로 구성된다. 일명 wParam, lParam인데, 16비트 시절에는 메시지, wParam, lParam의 크기가 각각 16, 16, 32비트였다. 그것이 32비트 기계에서는 모두 32비트 크기로 확장되었고, 64비트에 와서는 msg만 그대로이고 나머지 둘은 64비트로 더 커졌다.

이론적으로 아무 숫자나 담아서 메시지로 전달할 수 있다. 그러나 운영체제는 내부적으로 다음과 같은 방식으로 메시지의 용도를 정해 놓고 있다. 이는 마치 운영체제가 메모리 주소의 용도를 영역별로 나눠서 정해 놓은 것과 동일한 맥락이다. (MS-DOS 호환용, 응용 프로그램용, 커널용 등)

첫째, 0부터 WM_USER-1까지 총 1024개의 메시지는 시스템 메시지로서 그 의미가 예약되어 있다.
0인 WM_NULL은 의도적으로 아무 일도 하지 않는 메시지로 비워 놨지만, 그 뒤부터 WM_CREATE(1), WM_DESTROY(2) 같은 것은 아마 윈도우 1.0 시절부터 있었을 기초 메시지들이다..

글자 입력란에는 cursor라고 하여, 공식적으로는 caret이라고 불리는 반전 사각형이 깜빡거린다. 이건 WM_TIMER로 구현했을 법도 해 보이는데 Spy++ 같은 프로그램으로 확인해 보면 그렇지 않다. 메시지 코드는 0x118이고 winuser.h에 WM_* 형태로 문서화되지 않은 비공개 내부 메시지에 따라 동작한다. 신기하지 않은가? (그 주변의 0x117이나 0x119대엔 당연히 공개된 WM_*메시지들이 꽉 차 있음.) 게다가 의미가 뭔지는 모르겠지만 wParam과 lParam에도 그냥 0이 아니라 뭔가 메모리 주소처럼 보이는 값들이 있다.

사용자는 0x1000 이내의 영역에 있는 숫자에다가 나만의 의미를 부여해서는 안 된다. 지금은 쓰이지 않아도 나중에 운영체제가 찜할 가능성이 있다. 가령, 마우스 휠의 움직임을 감지하는 WM_MOUSEWHEEL은 윈도우 98에서 정식으로 새로 추가되었고, 터치스크린 입력을 감지하는 WM_TOUCH 같은 메시지는 윈도우 7에서 추가되었다.

이런 식으로 Windows가 버전업되면서, 메시지가 미래에 자꾸 추가될 수 있다. 개인적으로 최소한 4096개도 아니고 1024는 공간이 너무 부족하지 않나 하는 생각도 든다. 나중에는 이 공간이 메시지들로 다 차 버리고, 추가 메시지는 WM_EXTEND_MSG 같은 최후의 메시지 하에서 부가 정보는 wParam과 lParam에 담겨 오게 되지 않을까? =_=;;

운영체제 메시지 중에는 WM_SETTEXT, WM_GETTEXT이라든가 심지어 WM_COPYDATA처럼 포인터를 통한 데이터 전달이 필요한 것도 있다. 운영체제의 SendMessage 함수는 그런 메시지를 다른 프로세스에다가 보내라고 사용자가 요청할 경우, 자체적으로 공유 메모리를 생성하여 메모리 주소 변환을 하고, 텍스트의 경우 심지어 ANSI/유니코드 변환까지 자동으로 한다. 그러니, lParam을 포인터로 인식하는 시스템 메시지에다가 엉뚱한 숫자를 집어넣어서 보냈다간 큰일난다. 아울러 포인터를 전달해야 하는 메시지는 SendMessage로만 전달 가능하지, PostMessage로는 되지 않게 운영체제가 막는다.

또한 일부 메시지는 반드시 특정 방법만 이용하여 생성해야 하는 것도 있다. 가령, WM_PAINT는 invalidate region을 만드는 함수를 호출해서 운영체제가 생성하도록 해야 하지, 응용 프로그램이 메시지 자체만을 인위적으로 만들어 내서는 안 된다. 실제로 실험을 해 보지는 않았지만, 없는 WM_PAINT를 페이크로 사칭하여 생성하는 것은 운영체제가 아마 안전을 위해 금지하지 않을까 싶다.

요컨대 WM_USER 이내의 메시지는 용도가 운영체제에 의해 예정되고 그에 따른 특수 처리가 추가될 여지가 있는 영역이므로, 사용자가 사칭하거나 조작해서는 안 된다.

그 다음 둘째 계층은 WM_USER부터 WM_APP까지 3만여 개 남짓한 영역이다.
이 메시지는 각 윈도우들이 자체적으로 의미와 용도를 마음대로 정해서 쓸 수 있다. 즉, 윈도우 클래스(RegisterClass)별로 의미가 완전히 private하다.

내가 뭔가 새로운 커스텀 컨트롤을 개발해서 이 컨트롤을 조작하는 수단을 윈도우 메시지라는 형태로 제공하고 싶다면, 각종 커스텀 메시지들을 (WM_USER + xxx)의 형태로 정의하면 된다.
임의의 크기의 데이터를 다른 프로세스끼리 전달하려면 프로그래머가 알아서 주소 marshalling를 하든가, WM_COPYDATA로 주고받을 구조체 스펙을 정하든지, 아니면 짤막한 문자열만 잠시 주고받으려면 atom에다 등록하여 atom 번호만 주고받든지 해야 한다. 뭐, atom은 오늘날에 와서는 거의 구닥다리 메커니즘으로 전락하긴 했지만.

리스트 박스나 콤보 박스는 Windows 1.0 시절부터 있었던 워낙 붙박이이다 보니 LB_ADDSTRING이나 CB_GETCURSEL 같은 메시지는 놀랍게도 앞의 시스템 메시지 영역에 들어있다. 그러니 그 메시지는 값만 보고도 대상 윈도우가 뭔지 볼 필요도 없이 문맥 독립적으로 용도를 추측할 수 있다. 대상 윈도우가 무엇이든 간에 LB_ADDSTRING의 lParam에는 언제나 포인터가 들어있다고 가정할 수 있다.

그러나 사용자 메시지부터는 얘기가 달라진다. WM_USER+1이라는 값을 갖는 메시지는 어느 윈도우가 받느냐에 따라서 처리가 완전히 달라진다. 붙박이 시스템 컨트롤 말고, 32비트 시절에 나중에 도입된 공용 컨트롤도 이제는 아이템을 추가하고 삭제하는 등의 자신의 메시지들은 시스템 영역에 있지 않고 이 사용자 영역에 있다.

따라서 메시지가 하는 일에 따라 부가정보를 변조하는 hook 같은 걸 만든다면, 메시지의 값만 볼 게 아니라 그 메시지를 받는 대상 윈도우의 클래스 이름도 확인해야 한다. 이건 철저하게 문맥 의존적인 메시지인 셈이다.

운영체제(시스템) 메시지, 그리고 사용자 메시지 이렇게 둘이 갖춰지면 끝인 것 같은데 플랫폼 SDK를 보니 셋째 계층인 WM_APP라는 것도 있다. 이건 도대체 뭘까?
이것은 내부적인 처리 방식의 차이에 따른 구분이 아니라 그냥 용도에 따른 명분상의 구분이다.

결론부터 말하자면 이 계층은 응용 프로그램이 어떤 컨트롤에다 서브클래싱을 한 뒤, 응용 프로그램이 새로운 윈도우 프로시저에다 보내 주는 '반사'(reflect) 메시지를 여타 메시지들과 구분하기 위해 존재하는 영역이다. 에디트 컨트롤을 예로 들면, 글자색과 배경색을 바꾼다거나 25자리 제품 시리얼 번호를 입력받는데 5자리마다 '-'를 자동으로 추가하는 것 같은 자잘한 동작 방식을 변경하고 싶을 때 서브클래싱을 이용한다.

일반적으로 컨트롤은 어떤 일이 일어났다는 통지를 부모 윈도우에다 WM_COMMAND(붙박이 컨트롤)나 WM_NOTIFY(공용 컨트롤)의 형태로 보내 주는데, 그때 해야 하는 처리가 천편일률적으로 정해져 있기 때문에 부모 윈도우가 아니라 해당 컨트롤의 서브클래스 프로시저 자신이 도로 받아서 알아서 하게 하고 싶을 때가 있다.

이때 그 통지 메시지는 WM_APP 이후의 영역으로 더해서 보내고, 그 메시지에 대한 처리를 내 custom 윈도우 프로시저에다 넣으면 된다. 이 영역의 메시지는 WM_USER 영역의 메시지, 즉 기존 컨트롤의 메시지와 겹치지 않는다는 보장이 있기 때문이다.

요컨대 시스템 메시지는 그냥 닥치고 global, WM_USER 메시지가 RegisterClass에 종속이라면, WM_APP 메시지는 CreateWindow 종속이라고 생각하면 된다. WM_USER급 메시지의 경우, 해당 윈도우 클래스가 CS_GLOBAL 스타일이 있다면 그 윈도우를 사용하는 모든 프로그램들에서 global 종속이 보장될 것이다.

다음 넷째 계층은 RegisterWindowMessage 함수를 통해 등록된 custom 메시지들에 배당된다.
운영체제 전체를 통틀어서 uniqueness가 보장되는 나만의 고유 메시지를 만들고 싶으면 아무래도 숫자만으로는 무리가 있다. Windows 메시지가 무슨 방대한 128비트짜리 GUID급도 아니니 말이다. 그래서 문자열로부터 0xC000 ~ 0xFFFF 영역에 있는 숫자를 메시지 값으로 얻어 낸다. 아마 hash 연산 같은 걸 쓰겠지.

단, 같은 문자열을 등록하더라도 돌아오는 숫자는 그때 그때 다르다. 그렇기 때문에 RegisterWindowMessage의 리턴값은 프로그램의 컴파일 시점 때 하드코딩으로 박을 수 없다. C++ 언어로 치면 switch문으로 판단을 할 수 없으며 번거롭지만 if를 써야 한다. 하지만 한번 등록된 값은 운영체제가 부팅되어 있는 한 불변이므로, 전역변수의 초기값으로 지정하는 것 정도는 가능하다.

이 custom 메시지는 상당히 유용하다.
시스템 전체에다 메시지 hook을 걸어서 나만의 처리를 하는 프로그램을 만들었다고 치자. 그리고 hook을 건 응용 프로그램과 여타 프로세스의 주소 공간에 침투한 hook 프로시저 사이에 통신을 해야 하는데 이때 가장 효과적으로 쓰일 수 있는 수단이 바로 custom 메시지이다. 내가 만든 프로그램이니 나만 아는 문자열로 custom 메시지를 생성하고, 그걸로 EXE와 hook DLL이 통신을 하면 된다는 뜻이다.

뭐, EXE로 보낼 때야 그냥 WM_USER나 WM_APP급의 고정된 상수만으로 충분하겠지만, 다른 수많은 임의의 프로세스들을 상대하는 훅 DLL로 보내는 건 여타 메시지들과 전혀 충돌하지 않는 게 보장되는 고유 메시지를 써야 할 테니 말이다.

윈도우 95/NT4 초창기 시절에 WM_MOUSEWHEEL 메시지가 운영체제 차원에서 없었던 시절엔, 마우스 휠을 인식하는 드라이버 내지 추가 프로그램을 실행한 뒤, 휠이 굴렀다는 메시지 값을 RegisterWindowMessage(MSWHEEL_ROLLMSG)로부터 얻게 하던 시절이 있었다. 이 문자열의 값은 다음과 같았다.
#define MSWHEEL_ROLLMSG  _T("MSWHEEL_ROLLMSG")

그리고 오늘날 custom 메시지가 쓰이는 또 다른 대표적인 분야는 시스템 트레이라고 불리는 notification area이다. 트레이에다가 자기 아이콘을 추가하는 프로그램들은 _T("TaskbarCreated")라는 메시지를 받았을 때 아이콘을 다시 등록해 줘야 한다.

운영체제의 셸은 자기가 갖고 있던 아이콘들을 자체 보관하지 않는다. explorer 프로세스가 에러가 나서 뻗었거나 강제 종료되었다가 다시 실행되었다면, 아이콘들이 싹 다 날아가게 된다. 이때 셸은 모든 프로그램들을 대상으로 저 메시지를 보내서, 프로그램들로 하여금 알아서 트레이에다 아이콘을 다시 등록하게 한다. 마치 WM_PAINT 메시지를 받았을 때 창이 알아서 자기 내용을 다시 그려야 하듯이 말이다.

저건 너무 유명한 메시지가 되어 버렸기 때문에 장기적으로는 WM_TASKBAR_CREATED 같은 시스템 메시지로 승격이라도 돼야 하지 않나 싶다. 그리고 응용 프로그램들이 늘어날수록 이런 custom 메시지의 공간도 부족해지지는 않으려나 우려가 된다. 16000여 개만으로 충분하겠지? custom 클립보드 포맷이라든가 스레드별로 할당되는 TLS 슬롯의 개수와 비슷한 맥락으로 공간의 한계가 존재하는 영역이라고 볼 수 있다.

Objective C는 언어 차원에서 생으로 문자열 메시지를 객체들 사이에 주고받는 걸 지원한다. C++ 일반 멤버 함수를 호출하는 것보다 오버헤드는 당연히 훨씬 더 크지만, 함수 프로토타입이 하나 바뀌었다고 프로그램 모듈간의 바이너리 호환성이 박살 난다거나, 재컴파일을 해야 하는 그런 불편함은 없다. 내가 옵C를 잘은 모르지만 Windows의 custom 메시지를 보니 문득 옵C 생각도 났다.

이렇게 윈도우 메시지의 계층 4개를 모두 살펴보았다. 시스템 메시지만 1024개로 영역이 매우 좁아서 WM_USER의 영역이 넓은 편인 반면, 나머지 계층은 16비트 정수에서 1/4에 해당하는 16384개를 사이좋게 나눠 쓰고 있다.
그리고 메시지를 담는 공간 자체는 진작부터 32비트로 커졌지만, Windows는 16비트 크기의 범위를 벗어나는 영역은 여전히 예약만 해 놓고 쓰지 않고 있다.

허나, 개인적인 생각은 이들 중에서 그래도 custom(registered) 메시지가 16비트 이상의 범위로 확장되거나 이동하기 가장 용이한 영역이 아닌가 싶다.
일단 얘는 upper bound가 없는 가장 마지막 계층인 데다, MSG 구조체를 포함해서 메시지 값을 담는 모든 자료형이 32비트 UINT로 이미 다 확장되어 있고, custom 메시지는 언제나 함수가 되돌리는 변수값으로 활용하지 하드코딩이 없으니, 확장에 가장 유동적으로 대처 가능하기 때문이다.

Posted by 사무엘

심각한 뒷북인지 모르겠는데,
본인은 비주얼 C++에서 이런 문법이 가능하다는 걸 아주 최근에야 알게 되었다.

DATA container[N];

for each(DATA elem in container) {
    do_with(elem);
}

저건 언어 차원에서 제공하는 새로운 문법이기 때문에 STL <algorithm>의 for_each 함수와는 다르다.

배열을 순회하기 위한 별도의 임시 변수(일회용 int i나 거추장스러운 포인터)를 선언할 필요 없이, 코드를 굉장히 깔끔하게 만들 수 있어서 좋다. 이것의 주 용도는 C++을 상당한 고수준 언어로 끌어올린 C++/CLI 환경이지만, 네이티브 환경에서도 정적 배열과 STL 컨테이너 정도에서는 아주 요긴하게 쓰일 수 있다.

DATA가 int 같은 아주 기본적인 자료형이라면 그냥 저렇게 써 주면 되고, 개당 수십~수백 바이트씩 하는 무거운 구조체라면 const DATA&를 하면 된다. 그리고 순회 중인 배열 자체의 데이터를 루프 안에서 고쳐야 한다면 물론 DATA&라고 써 주면 된다.
저건 C++11 같은 급도 아니고, 생각보다 굉장히 오래 된 비주얼 C++ 2005에서부터 지원되기 시작했다고 한다.

컴파일러가 언어 표준에 없는 변칙 문법이나 키워드를 지원하는 것은 특정 CPU나 운영체제에 종속적인 기능을 추가로 제공하기 위해서이다.
하지만 for each는 그런 범주에 속하지 않으며, 전통적인 C/C++ 언어의 토큰 나열과 비교했을 때 문법도 굉장히 이질적이다. 그럼에도 불구하고 비주얼 C++이 이것을 제공하는 것이 신기하기 그지없다.

그리고 또 하나 생각할 점은, 저기서 each와 in은 문맥 의존적인 임시 예약어(키워드)라는 것이다. for 다음에 이어졌을 때만 키워드이며, 다른 곳에서는 사용자가 each나 in을 일반적인 변수/함수명으로 얼마든지 쓸 수 있다는 뜻.

언어 설계 차원에서 C/C++은 원래 임시 예약어라는 게 없는 언어이다. 한번 예약어로 찜해진 단어는 그 어떤 곳에서도 명칭으로 결코 쓰일 수 없다. 다른 구문이나 수식을 파싱하는 데는 문맥 의존적인 어려운 문법이 많지만, 예약어 식별만은 단순하게 만들려고 했는가 보다.

그 반면, 파스칼은 begin, end, if, for 같은 단어야 절대적인 예약어이겠지만 forward(함수 전방 선언용)를 포함해 몇몇 키워드는 일정 문맥에서 별도의 의미를 갖는 임시 예약어이다. 그리고 객체지향 개념이 추가된 오브젝트 파스칼의 경우 virtual 같은 함수 modifier, 그리고 클래스 내부에서 public/protected 같은 멤버 접근성 modifier도 임시 예약어이다. C++은 그렇지 않다.

비주얼 C++은 for each, in뿐만 아니라 abstract, override, delegate 등 몇몇 비표준 임시 예약어를 더 두고 있기도 한데, 이것은 대개가 C++/CLI용이고 네이티브 환경에서는 쓰일 일이 별로 없다. 일반적인 경우라면 비표준 확장 예약어는 앞에 __를 붙여서 명칭 충돌의 여지를 없앤 뒤에 절대적인 예약어로 추가하는 게 관행일 텐데, 저것들은 그렇게 하지 않았다.

끝으로, for each, in에다가 2차원 배열을 넘겨 주면 어떻게 될까 궁금해서 시도를 해 봤는데, 이때도 각 원소들이 하나씩 순서대로 순회되더라.
각 배열을 배열의 포인터로 받으면서 1차원적으로 순회되지는 않는가 보다.

비주얼 C++ 2010은 인텔리센스 컴파일러와 실제 컴파일러의 동작이 서로 다르기라도 했는지, IDE에서는 이때 each 변수가 2차원 배열과 서로 호환이 되지 않는다고 빨간줄 에러를 뱉은 반면, 실제 컴파일은 됐다.
2012에서는 그것이 개선되어 IDE에서도 빨간줄이 생기지 않는다.

Posted by 사무엘

※ 윈도우 프로그래머라면 누구나 다 알 만한 내용에 대한 정리이다.
보면 아시겠지만 1~5까지 등장하는 기술들은 서로 동등한 차원의 관계에 있는 것들이 아니다.

1. 윈 API

kernel32, gdi32, user32를 주축으로 운영체제가 응용 프로그램에다 자신의 기능을 제공하는 가장 원초적인 매체이다. 우리에게 친근한 CreateWindowEx, DispatchMessage, CreateFile 등등등! 20년에 달하는 역사를 자랑하며, Windows라는 운영체제와 PC 데스크톱 애플리케이션이라는 영역 자체가 존속하는 한 결코 없어지지 않는다. 과거의 도스 API는 그냥 인터럽트 호출을 그대로 노출하던 반면, 윈도우 API는 C언어 함수 호출 형태를 근간으로 만들어져 있다.

2. MFC

윈 API만 쓰면 생산성이 크게 떨어지고 불편한 관계로, 1990년대 초에 응용 프로그램의 주 개발 언어가 C에서 C++로 넘어가던 시기에 기존 API를 C++ 라이브러리 형태로 적당히 wrapping하기 위해 이 물건이 개발되었다.
생성자와 소멸자, 오버로딩과 상속, message map 같은 것들 덕분에 생API보다야 개발 생산성이 크게 향상되는 건 사실이나, 이걸 제대로 쓰려면 윈 API도 알아야 되고 객체지향 이념과 MFC가 새로 도입된 개념까지 다 알아야 하기 때문에 초기 학습자의 부담이 커진다. 또한 MFC 자체가 부과하는 오버헤드도 만만찮다.

MS C 7.0의 다음 버전인 비주얼 C++ 1.0때부터 application frameworks라는 이름으로 존재하고 있었다. 16비트 시절부터 존재했으니 역사가 제법 길다.

3. COM

함수 호출 규약, 메모리 할당과 해제 방식, 문자열의 처리 방식, 특정 기능이 담겨 있는 객체를 식별하고 외부에 노출하는 방식 같은 아주 기본적인 바이너리 수준에서의 소프트웨어 컴포넌트 제조 규격을 범언어적으로 통일하는 스펙이다. 가령, 윈API가 DLL 로딩을 위해 전통적으로 지저분한 LoadLibrary(파일명), GetProcAddress나 import library 같은 저수준 방법을 썼다면, COM의 사고방식으로는 CoCreateInstance와 깔끔한 class ID만으로 끝인 것이다.

이건 1990년대 중반의 32비트 윈도우 이래로 도입되었다. 지금은 옛날보다야 중요도가 크게 떨어진 게 사실이지만 DirectX, 탐색기 셸, 드래그 드롭 같은 일부 분야의 API는 이 COM 방식으로 제공되기 때문에 프로그래머아면 COM의 개발 취지와 기본 개념 정도는 알 필요가 있다. 한편, MFC도 이런 COM 규격을 만족하는 컴포넌트를 새로 구현하는 데 쓰이는 공통 필수 기능을 지원한다.

4. GDI+

클래식 윈 API 중에서 GDI 계층을 계승하는 그래픽 라이브러리로, MS가 제공하는 API로는 드물게 C와 더불어 순수 C++ 기반으로 만들어졌다. 또한 사용하는 자료형이나 명칭들이 윈 API와는 완전히 다르며 서로 관련이 없다는 특징이 있다. 비록 GDI+는 기존 GDI보다 느리고 오버헤드가 크지만, 알파 블렌딩, 그러데이션 같은 최신 그래픽 카드를 활용하는 고급 그래픽 기능에 더욱 특화되어 있으며, 일부 그리기 기능은 반드시 GDI+만 써야 가능한 것도 있다.

가령, 안티앨리어싱이 적용된 글자를 찍는 건 재래식 GDI로도 가능하지만 안티앨리어싱이 적용된 선을 그리는 건 GDI+를 써야만 가능하다. 그리고 윈도우 비스타/7의 glass 영역에다가 알파 채널이 적용된 그림/글자를 제대로 그리는 것도 역시 GDI+로만 가능하다.

5. .NET

기계어가 아닌 바이트코드 가상 기계(common language runtime)를 기반으로 하면서, 운영체제 API를 객체지향 위주로 완전히 새로 설계한 윈도우 프로그래밍 플랫폼이다. 예전에는 비주얼 베이직이 얼추 이런 개발 환경을 지향하고 있었지만 닷넷은 그보다 스케일이 범언어적으로 훨씬 더 커졌다. .NET 환경에서의 주력 개발 언어인 C#은 최신 언어답게 디자인이 깔끔하고 빌드 생산성이 우수하다. 하지만 네이티브 기계어 프로그램만치 빠르거나 운영체제 내부를 세밀하게 지어하지는 못하며, 닷넷 프레임워크 위에서만 돌아갈 수 있다는 한계도 있다.

.NET에서는 기본 그래픽 API가 GDI+이다. 둘 다 윈도우 XP부터는 기본 내장이고, 윈도우 98부터 2000/ME까지는 운영체제에 배포판을 추가 설치해서 쓸 수는 있다. 다만, 윈95는 지원을 끊었다.
윈도우 8에서는 닷넷조차도 다른 언어와 플랫폼으로 대체되었는지 WinRT라는 플랫폼이 등장하며, C++ 언어도 C++/CX라고 대대적으로 칼질이 가해졌다. 이게 앞으로 6번으로 추가되어야 할 듯하다.

맥 OS는 운영체제의 API가 저런 식의 내력을 거친 게 있으려나 궁금하다. 코코아, 카본 같은 건 어느 위상에 속할까?

Posted by 사무엘