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

아래아한글이 윈도우 비스타부터 키매크로를 지원 안(못) 하는 이유는?
(관련 글: 아래아한글의 키매크로 )
이것과 관련하여 갑자기 떠오른 생각이 있어서 글을 남긴다. 본인은 한컴에 입사한 개발자도 아니고 아래아한글의 소스 코드를 본 적도 없지만, 본인이 보기에 이것 때문이 거의 확실하다.

윈도우 훅 중 WH_JOURNALRECORD와 WH_JOURNALPLAYBACK 훅이 비스타에서부터는 보안 강화를 이유로 차단되었기 때문이다. MSDN을 보면 알 수 있지만 저건 완전 키매크로를 구현하라고 만든 훅이다.
(관련 글: 훅킹 프로그래밍 )
실패 사유를 나타내는 에러 코드는 5(access denied)가 들어온다.
심지어는 프로그램을 관리자 권한으로 실행해도 차단은 풀리지 않는다. 이건 좀 너무 심하지 않았나?

물론, 키매크로를 구현하는 방법이 저 훅만 있는 건 아니기 때문에 다른 키보드/마우스 훅을 사용하여 동일 기능을 우회 구현할 수도 있다. 하지만 이래저래 개발자에게는 귀찮고 짜증나는 일이 하나 더 생긴 게 틀림없다.

참고로 이렇게 차단을 하는 주체는 사용자 계정 컨트롤(UAC)이다. 그렇기 때문에 이걸 끄면 비스타도 XP와 완전히 동일하게 동작은 한다. 하지만 보안상으로는 위험하기 때문에 개발자가 사용자에게 UAC를 끌 것을 강요해서는 안 된다.
UAC는 안전을 위해 프로세스 간 의사소통을 하는 메커니즘에도 상당한 제약을 부과했다. 단적인 예로, 권한이 낮은 프로그램이 권한이 높은 프로그램에게 임의의 메시지를 보낼 수 없다.

이미 아시는 분도 있겠지만 <날개셋> 한글 입력기는 5.3부터 입력 패드라는 프로그램을 제공하고 있다. 윈도우 IME 훅킹을 통해, 정식 외부 모듈이 아니면서도 외부 모듈의 동작을 흉내 내어 주는 프로그램인데, 이 프로그램을 제대로 사용하려면 관리자 모드로 실행해 줘야 한다. 그렇지 않으면 입력 패드보다 권한이 높은 프로그램(관리자 권한으로 실행된)에다가는 글자 입력을 할 수 없게 된다.

그런데, UAC 하에서도 예외적으로 실행 중인 모든 프로세스의 윈도우에다가 메시지를 보낼 수도 있고 심지어 봉인된 WH_JOURNAL* 훅까지 구사할 수 있는 만능 권한 등급이 없는 건 아니다. MS에서는 대표적인 예 중 하나로 장애인의 UI 접근성 개선을 위해 쓰이는 프로그램에게나 그런 만능 권한을 주고 있다.
예를 들어 화면 키보드 같은 프로그램이야 권한을 초월하여 아무 프로그램에게나 문자 입력 메시지를 전달할 수 있어야 하고 심지어 운영체제 로그인 UI에도 존재해야 하기 때문이다. (ID/패스워드 입력할 때)

단지 그 권한을 얻기가 더럽게 까다로워서 문제이다. 만능 권한을 얻을 수 있는 프로그램은 사용자의 컴퓨터에 반드시 관리자 권한으로 정식으로 설치되어 EXE 파일이 Program Files 같은 특정 경로에만 존재해야 한다. 잘 알다시피 UAC 하에서는 평소에는 Program Files 디렉터리 밑에다가 파일을 만들지도 못한다.

또한, 결정적으로 EXE 내부에 디지털 서명이 되어 있어야 한다. 과거에 마치 ActiveX를 배포할 때 안전한 코드 인증을 받는 것처럼 말이다. 이거 서명을 받으려면 $이 필요하고, 무엇보다도 사업자 등록 번호가 있어야 한다. 즉, 듣보잡 개인 개발자는 서명을 받지도 못한다는 뜻.
따지고 보면 <날개셋> 입력 패드도 일종의 화면 키보드처럼 UI 접근성 개선 프로그램의 성격이 강하기 때문에 저런 권한이 있어야 할 텐데... 그러지는 못하고 있고 그저 사용자가 알아서 충분히 높은 권한을 줘서 프로그램을 실행해 주길 바랄 뿐이다.

이래저래 보안이 안전을 빌미로 세상을 많이 복잡하게 만들고 있다.
(관련 글: 프로그램의 권한 )

Posted by 사무엘

윈도우 운영체제에는 MDI (Multiple Document Interface)라는 규격이 존재하여, 한 응용 프로그램이 메모리가 허용하는 한 여러 파일 내지 문서를 한꺼번에 다루는 걸 수월하게 해 줬다. MDI 프로그램에는 '창'이라는 메뉴가 존재한다.
과거에 도스용 아래아한글이 기껏해야 겨우 두 개의 문서만 동시에 열 수 있었던 것에 비하면 이건 아주 획기적인 개념이 아닐 수 없었다. MDI는 무려 윈도우 3.x는 말할 것도 없고 원래 2.x 때부터 존재한 개념이라고 한다.

그래서 나만의 작업 문서라는 개념이 있고(스프레드 시트, 그래픽, 워드 프로세서 등등), 좀 규모가 있다 싶은 업무용 프로그램이라면 예외 없이 MDI 방식으로 만들어졌다. 그리고 본인이 개발한 <날개셋> 편집기 프로그램도 1.0 시절부터 MDI였다. ^^
프로그램 자체를 중복 실행하지 않고 한 프로그램 안에서 여러 문서를 동시에 열 수 있는 것은 작업 생산성 면에서 매우 바람직하고 시스템 자원 사용 효율면에서도 좋기 때문이다. (한 번에 소스 코드를 하나만 열 수 있는 에디터로 대규모 프로그래밍 작업을 해 보면 어떨까? -_-)

물론, 윈도우 운영체제가 제공하는 액세서리 프로그램들은 그 정도의 근성은 없는 그냥 말 그대로 액세서리에 불과하기 때문에 MDI 프로그램을 찾아볼 수 없다. 마치 워드패드나 그림판처럼 말이다.
하지만 과거 윈도우 3.x 시절에는 운영체제(?)의 쉘이요 간판 프로그램이라 할 수 있는 '프로그램 관리자'가 딱 MDI 프로그램이었다.

이 MDI 방식에 대해서는 비판도 많았다. 그 자체가 사실 등장한 지 20년 가까이 된 너무 구닥다리 인터페이스이도 하고.. 특히 Aero가 적용된 윈도우 비스타에서도 MDI 창들은 여전히 전혀 세련되지 못한 밋밋한 모양이다.
그래서 요즘은 프로그램 안에 또 여러 창이 타일처럼 더덕더덕 겹쳐 있는 모습 자체를 안 보이려고 하는 게 대세이다. 그 대안으로 각광받고 있는 건 탭 인터페이스이다.

이런 추세는 MS의 주력 상품인 오피스에서도 바로 나타났다. 그것도 꽤 오래 전부터 말이다.
워드의 경우, 아예 10년 전 오피스 2000부터 MDI 방식을 버렸다. 그냥 모든 문서마다 응용 프로그램 프레임이 따로따로 붙어서 '창' 메뉴만 있을 뿐 SDI 프로그램을 여러 개 실행한 것처럼 동작한다.
마치 윈도우용 아래아한글처럼 말이다. 특이하게도 오피스 제품들 중, 워드만 유일하게 그렇게 따로 놀고 있다.

엑셀은 그래도 좀 전통적인 스타일을 유지하고 있다. MDI스러운 메뉴를 볼 수 있으며, 여러 문서 창들을 응용 프로그램 창 내부에다가 덕지덕지 배열할 수 있다. 엑셀은 표 형태로 된 각종 수치와 데이터를 처리하는 프로그램이지 않던가? 당연히 그런 식으로 한 화면에서 여러 파일을 대조할 수 있어야 한다.

하지만 파워포인트는 성격이 좀 다르다. 큼직한 화면 전체에다가 슬라이드 그림을 놓고, 그 곁엔 다른 슬라이드들 썸네일과 슬라이드 노트를 작성하는 공간이 들어가기 때문에 근본적으로 화면이 많이 필요하다.
즉, 파워포인트 슬라이드의 작업 화면은 엑셀 워크시트와 같은 MDI 식 덕지덕지 타일 배열 자체가 무의미하다. 그래서 파워포인트는 워드가 아닌 MDI 형태임에도 불구하고 MDI 메뉴를 갖추고 있지 않으며, 문서 창은 언제나 최대화되어 있다고 가정하고 동작한다. 굳이 최대화 상태를 해제려면 계단식 배열 같은 별도의 명령을 직접 내려 줘야 한다.

끝으로 데이터베이스 프로그램인 엑세스는 한 프로그램이 한 데이터베이스만 열 수 있고, 그 데이터베이스 안에 있는 각종 테이블, 쿼리, 모듈 등을 MDI 형태로 여럿 열어볼 수 있는 형태이다. 이런 점에서는 엑셀처럼 매우 MDI스러운 UI를 유지하고 있는 셈인데, UI 기반이 엑셀과는 다르다 보니 각 창에 대한 시스템 메뉴도 갖추고 있고, MDI 배경색이 엑셀이나 파워포인트의 배경색보다는 짙다. 또한 View 탭이 따로 없으며, 창과 관련된 메뉴가 Home 탭에 같이 들어있다.

이렇듯, MS 오피스의 주축을 이루고 있으며 2007부터 리본 UI가 첫 적용된 워드, 엑셀, 파워포인트, 액세스의 UI 형태는 다 조금씩 차이가 있다는 사실이 흥미롭다. 참고로, 엑셀이나 파워포인트는 워드처럼 매 문서창이 완전히 제각각 따로이지 않음에도 불구하고, 매 문서마다 운영체제의 작업 표시줄(Taskbar)에 제목이 마치 별개의 프로그램처럼 추가된다. 이 역시 2000부터 그렇게 되었는데, 무척 특이한 점이 아닐 수 없다.

MDI에 대해 끝으로 생각해 볼 점은, 웹브라우저나 파일 관리 유틸리티가 MDI 형태로 개발되고 있지 않다는 것.
이들은 분명 한 프로그램이 여러 창을 취급할 수는 있어야 하지만, 문서라는 개념을 다루는 프로그램이 아니라는 것이 독특하다.

Posted by 사무엘

C 언어 표준 라이브러리에는 잘 알다시피 배열 데이터에 대해서 간단한 검색과 정렬 알고리즘을 구현해 놓은 함수가 존재한다.
정렬을 수행하는 qsort()가 대표적인 예이고, 이미 정렬된 배열에 대해서 이분 검색을 수행하는 bsearch()도 유용하다.

이들 검색과 정렬 함수는 비슷한 형태의 인자를 받아서 동작한다. 배열을 가리키는 포인터, 각 원소의 개수와 크기, 그리고 찾고자 하는 원소의 값, 그리고 비교 함수의 포인터이다. 비교 함수는 두 원소의 비교를 수행하여 대소 관계를 리턴값의 부호 또는 0 여부로 알려 주어야 한다. 이렇게 함으로써 int든 float든 그 어느 자료형이라도 범용적으로 검색하거나 정렬을 수행할 수 있다.

그런데 C 언어는 이분 검색뿐만 아니라 선형 검색을 하는 함수도 제공한다. 찾는 원소와 같은 값이 나올 때까지 배열을 처음부터 끝까지 단순히 뒤지기만 하는 알고리즘 말이다. 동작 방식은 단순하기 그지없지만, 이분 검색과 더불어 그냥 일관성을 위해서 선형 검색도 함수로 표준화한 듯하다. 선형 검색이 받아들이는 비교 함수는 두 값의 대소 비교를 할 필요가 없이 두 값이 단순히 같으면 0, 그렇지 않으면 nonzero만 되돌려도 된다.

그런데 본인은 C 언어가 제공하는 선형 검색 함수의 형태를 보고는 놀라지 않을 수 없었다.

1. 이분 검색이 bsearch이니 선형 검색은 응당 lsearch일 거라고 본인은 생각했다. 그런데 선형 검색 함수는 _lsearch와 _lfind로 나뉘어 있고, 어찌 된 이유인지 함수 이름 앞에 밑줄이 추가돼 있다. 이분 검색과 정렬 함수는 stdlib.h에도 선언이 되어 있는 반면, 선형 검색 함수는 거기에 없으며 반드시 생소한 search.h를 인클루드 해 줘야 한다. 왜 이런 차이가 존재하는지부터 의문이다.

2. _lsearch는 원소를 찾아서 이게 배열에 존재하지 않으면, 그 원소를 배열의 끝에다가 추가를 한다. 따라서 이 함수는 매개변수만 올바르다면, 원하는 원소가 배열에 없다고 하더라도 NULL을 리턴하지 않는다. 그 반면 _lfind는 read-only 함수로, 원하는 원소가 없으면 NULL을 되돌린다. 그러므로 정확하게 bsearch 함수의 동작 방식만 선형 검색의 형태로 원한다면 _lsearch가 아닌 _lfind를 써야 한다.

3. bsearch와는 달리, 선형 검색 함수는 배열 원소의 개수를 넘겨주는 인자가 포인터형이다. 그것도 size_t도 아닌 unsigned int의 포인터이기 때문에 64비트 환경에서도 여전히 32비트 값 전달만 가능하다는 한계마저 그대로 지닌다. ㅜ.ㅜ 왜냐하면 _lsearch의 경우, 원하는 원소가 배열에 존재하지 않아서 그 원소가 배열 뒤에 추가되었을 경우, 배열 원소 개수를 1 증가시켜 주기 위해서이다.

그러나 배열 원소 추가를 하지 않는 _lfind라면 배열 원소 개수 인자가 포인터여야 할 필요가 전혀 없고 bsearch처럼 size_t 값을 그대로 받기만 하면 된다. 왜 _lfind까지 _lsearch처럼 그렇게 포인터를 받게 해 놓았는지 모르겠다.

Posted by 사무엘

본인은 예전에 쓴 이 글에서 언급된 노트북을 개인용 컴퓨터로 아주 만족스럽게 잘 쓰고 있다. 이제 2년이 경과했지만, 예전 노트북과는 달리 이번 4대 노트북은 잔고장이 발생한 적이 전혀 없고 심지어 아직까지 운영체제를 재설치한 적도 없다.

http://moogi.new21.org/tc/141

그런데 지금으로부터 두세 주 남짓 전부터는 컴퓨터에 뭔가 이상 징후가 느껴졌다.
바로 컴퓨터의 속도가 체감상으로는 평소의 절반 이하 수준으로 곤두박질친 것이다.

창의 크기를 바꾸거나 인터넷 화면을 스크롤할 때의 반응이 매우 둔해지고, 컴파일도 엄청 느려졌다.
Aero를 꺼도 화면이 버벅대는 게 변함없었기 때문에 이건 그래픽 카드 문제가 아니며, 디스크 I/O 쪽의 병목 현상 역시 아니었다. 전적으로 CPU가 느려진 것이 확실했다. 심하게 버벅댈 때는 마우스 포인터까지 버벅대며 움직였다.
더구나 AC 전원을 연결해도 속도가 여전히 느렸기 때문에 전원 절약과 관련된 CPU 감속 역시 아니었다.

본인은 평소에 컴퓨터 관리를 얼마나 결벽증에 가깝게 하고 지내는데 메모리 부족이나 악성 코드 때문도 아니고..
이 노트북은 물론 예전 노트북에서도 이런 식의 이상 증세를 경험한 적은 없었기 때문에 처음엔 좀 당황했다.

이 문제는 의외로 굉장히 쉽게 해결됐다. 그것 때문일 수도 있다고 예상은 했지만 정말로 전적으로 그것 때문일 줄은 몰랐다.

바로... 냉각팬에 잔뜩 낀 먼지 때문이었다. 그것만 제거해 주자 컴퓨터는 거짓말처럼 본디 속도로 되돌아왔다!
팬이 잘 안 돌아가고 열이 못 빠져나가고 있으면 컴퓨터가 안전을 위해 스스로 알아서 감속 운행(?)을 해 왔던 것이다. 굳이 절전을 위한 감속뿐만 아니라 말이다. 먼지를 제거하기 전이나 후나 밖에서 느껴지는 컴퓨터 소음 내지 팬 바람은 별 차이가 없는데, 컴퓨터의 성능이 이렇게 확 달라지다니 참 뜻밖이고 의미 있는 경험을 했다. (날씨가 너무 덥고 레일이 너무 뜨거우면 알아서 감속을 하는 KTX처럼?? ㅋ)

10년이 넘게 노트북을 써 왔지만 이런 일은 처음이었다. 하긴, 2년이 넘도록 A/S 센터를 단 한 번도 찾지 않을 정도로 컴퓨터가 건강했기 때문에, 내부 청소를 할 일도 지금까지 없었다. 이렇게 한번 먼지를 제거해 줬으니 앞으로 또 이 노트북이 몇 년간 쌩쌩하게 돌아가 주기를 기대한다.

하긴, 다른 가전제품에서도 비슷한 경험을 한 적이 있다. 멀쩡하던 에어컨이 갑자기 전혀 동작하지 않고, 아무리 온도를 낮춰도 더운 바람밖에 나오지 않는 것이었다. “올여름엔 지내는 데 당분간 애로사항이 잔뜩 꽃피겠구나! A/S 센터 연락처가 어디더라?” 이러고 있었는데 문제의 원인은 정말 어처구니없는 곳에서 찾아낼 수 있었다.

에어컨으로부터 나오는 더운 바람이 빠져나갈 통로가 막혀 있었던 것이다. ㅜ.ㅜ
겨울에는 보온을 위해 닫아 두지만 한여름에는 응당 개방해 놓아야 한다.
컴퓨터든 에어컨이든 열이 잘 빠져나가게 해 줘야 한다는 교훈을 얻었다. 이건 자동차에도 동일하게 적용되는 원칙일 것이다.

Posted by 사무엘

오늘날 쓰이고 있는 컴퓨터라는 기계의 이론적 근간을 마련한 사람으로는 앨런 튜링(영국)이라든가 폰 노이만(헝가리->미국) 같은 불세출의 천재 수학자가 있다. 그런데 영국에서는 튜링보다 먼저, 범용적인 계산 기계라는 개념을 떠올렸던 천재가 있었으니 바로 찰스 배비지(1792-1871)이다. 전산학도라면 배비지의 해석 기관에 대해 들어 보지 못한 사람이 없을 것이다.

그는 시대를 너무 앞서 간 괴짜 덕후였으며, 재정 부족과 당대의 기계 제작 기술의 부족 때문에 그의 꿈이 당장 완전히 실현되지는 못했었다.
참고로 창조 과학회에서는 배비지가 독실한 크리스천 과학자였다고 띄우고 있다. ㅋㅋ 링크를 소개한다. (그 반면 튜링은 동성애자인 데다 자살로 생을 마감했으니, 기독교 진영에서는 별로 좋아할 구석이 없겠다)
http://www.kacr.or.kr/library/itemview.asp?no=243

그런데, 이 시대에 영국에서는 배비지의 계보를 이을 천재 수학자가 또 태어났는데, 이번엔 여자였다. 그녀의 이름은 에이다(Ada Lovelace; 1815-1852). 인류 역사상 최초의 프로그래머라고 일컬어지는 먼치킨 엄친딸 공순이이다. 이 두 사람은 사진기가 발명되기 거의 직전의 시기를 살았던 사람인지라 사진은 전해지지 않으며, 초상화나 스케치로 그려진 모습만 전해 내려온다. 하지만 에이다는 상당한 미녀였다고 한다. Lovelace라는 성은 백작 작위를 얻은 남편의 성에서 딴 것.

에이다는 ‘자고 일어나 보니 유명해졌더라’ 같은 어록으로 유명한 시인 바이런의 외동딸이었다. 아버지가 희대의 바람둥이었다고 하는데 딸 역시 머리가 비범했고 나중에는 도박에 빠졌다고 하니 평범한 인생을 살지는 못했으며, 그러다 자궁암 때문에 30 중반의 나이로 요절하여 세상을 짧고 굵게 살다 갔다.

그녀는 남들이 도무지 이해를 못 하던 찰스 배비지의 해석 기관의 원리를 간파하고 그 기계의 무한한 가능성을 알아차린 당대의 극소수 덕후 중 하나였다. 오늘날 절차형 프로그래밍 언어의 기본 골격이라 할 수 있는 루프, 조건문, 서브루틴 같은 개념을 떠올렸다. 그것을 처리하는 기계를 만들고 그 틀을 바탕으로 프로그램을 짜서 돌리면, 기계로 음악도 작곡하고 그림도 그리게 할 수 있다고 상상했다. 무려 19세기에 말이다!

배비지 역시 에이다의 재능과 글빨에 큰 감명을 받았다고 한다. 그녀는 기계가 숫자를 처리하기 위해서는 10진법이 아닌 2진법이 유리하다는 발상을 했으며, 베르누이의 수를 구하는 ‘프로그램’을 해석 기계를 기반으로 실제로 작성하기도 했다. 그래서 최초의 프로그래머이다. ㅎㄷㄷ;;; (베르누이는 유체 역학에서 배우는 베르누이의 원리를 발견한 그 과학자 겸 수학자이다. H2O가 뭔지 정도야 '문과 출신'도 알겠지만, 베르누이의 수가 뭔지는 어지간한 이과 출신도 들어 보지 못했을 것이다.)
http://www.bernoulli.org/

그로부터 100년 남짓한 시간이 지나고 전자식 컴퓨터가 실제로 발명되었을 때, 한 절차형 프로그래밍 언어는 바로 이 여성 프로그래머를 기려, 그녀의 이름을 따서 Ada라고 명명되었다. 프로그래밍 언어의 이름에다가 전설적인 프로그래머의 이름을 붙였으니 매우 고무적인 현상이라 하지 않을 수 없다.

Ada 언어는 1983년에 첫 제정되었으며, 이는 시기적으로 C++의 탄생 시기와 일치한다. C++의 고안자가 스웨덴 사람인 반면, Ada의 초창기 핵심 고안자는 프랑스 사람이었다. Ada는 당시 난립하던 프로그래밍 언어들의 통합을 목적으로 미국 국방성으로부터 강력한 후원을 받으며 만들어졌다. 그래서 그쪽 바닥--무기를 가동하는 전산 시스템 같은--에서는 지금까지도 표준 언어로 쓰이고 있다고 한다.

본인은 에이다 언어에 대해서 잘은 모르지만, 이 언어의 문법은 일단 파스칼과 얼추 비슷하다. 암호스러운 기호들보다는, 타이핑을 더 하더라도 깔끔하게 영어 단어 표기를 선호한다. 패키지 단위로 빌드가 이루어지는 것도 C/C++보다는 파스칼 방식이다. (참고로 베이직 언어의 경우, MS의 퀵베이직은 include에 컴파일/링크까지 C언어의 빌드 모델을 그대로 이어받은 반면, 파워베이직은 파스칼과 비슷한 방식을 쓰고 있다는 것이 흥미로움.)

Ada에 대해서도 예제 코드를 보면 이해가 빠를 것이다. 미리 말하지만 C/C++의 사고방식보다는 파스칼의 관점에서 보면 굉장한 동질감을 느낄 수 있다. 심지어 대소문자 구분이 없는 언어라는 것까지도 똑같다. 비록 요즘 C++의 영향을 받은 자바나 C# 같은 언어들의 추세는 대소문자 구분이지만 말이다. 더 자세한 것은 http://www.adahome.com/ 참고.
아니, 그러고 보니 Ada는 수학자의 이름을 따서 지어진 것까지 파스칼과 일치하는구나.

Ada는 기존 언어들의 통합을 목적으로 만들어진 만큼, 이것저것 여러 언어 요소들을 집어넣느라 표현의 자유가 굉장히 넓으며, 제공되는 언어 요소가 많다.
무슨 말이냐 하면, 가령 다차원 배열(a[2,5])과 배열의 배열(a[2][5])을 구분하여 모두 표현할 수 있고,
단축연산이 지원되는 논리 연산자와(and also나 or else), 그렇지 않은 연산자(그냥 and나 or)가 모두 제공된다.

파스칼처럼 0..100 같은 식의 subrange도 당연히 지원되고, 똑같은 정수형이라도 int 같은 기본 자료형과 완전히 호환되는 단순 alias/typedef인지, 아니면 int와 호환되지 않는 별개의 타입인지도 지정 가능하다. 타입 하나는 C/C++과는 비교도 할 수 없이 정교하고 엄격하게 만들 수 있어서 좋다.
함수 안에다 함수도 당연히 만들 수 있고, while이나 for 같은 loop 자체에다가 label 이름을 붙여서 다중 loop을 goto문 없이 바로 탈출하는 것이 가능하다.

이런 것들만 있는 것도 아니고, 어쨌든 Ada는 처음 발표되었을 때는 문법이 필요 이상으로 너무 복잡하고 컴파일러로 다 구현하는 데 난감하다는 불만도 있었다고 한다. Quicksort의 고안자께서도 그렇게 불만을 제기한 사람 중 하나였다고 함. 하지만 오늘날은 C++도 가히 복잡성 면에서는 타의 추종을 불허하는 경지에 도달한 것 역시 사실이다.

그다지 여성향을 느낄 수 없는 것 같은 전산학 분야에도 이런 사연이 있는 여성의 이름을 딴 프로그래밍 언어가 존재한다는 것이 흥미롭다. 여성 프로그래머 모에~ 이다. 하하. =_=;;
참고로 성경에는 Ada와 가장 비슷한 이름으로 유대 왕국의 왕 Asa가 있으나, 물론 성별부터가 다르다.

에이다가 살아 있던 19세기에 우리나라는 뭘 하고 있었는가? 딱 흥선대원군 시절이다. 그런데 본인은 그 시절 조선의 역사에 대해서 좋은 기억이 도무지 없다. 19세기 하면 홍 경래의 난, 전 봉준 동학 운동, 게다가 명성황후 시해 등... 나라는 점점 탐관오리 부정부패와 외세의 침략에 휘말려 막장으로 치닫다가 이내 일제에게 주권을 빼앗기고 만다. 그런데 그 시절에 영국은 저런 상상을 초월하는 학문적 성과가 속속들이 발표되고 있었으니... 오옷 역시 킹 제임스 성경과 철도를 만들어 낸 나라! 괜히 전세계를 호령한 선진국이 아니다.

게다가 전자기학의 대부인 마이클 패러데이(1791-1867), 제임스 맥스웰(1831-1879), 그리고 나중엔 찰스 다윈(1809-1882)이 전부 동시대를 살았던 영국의 과학자들이다! 이 정도면 충격과 공포가 아닐까? 맥스웰도 마찬가지이지만 패러데이는 다윈의 진화론을 단호하게 반박하고 부정한 것으로 유명한 사람인데( http://www.kacr.or.kr/library/itemview.asp?no=644&orderby_1=subject 참고), 에이다로부터 연애편지를 받고서 사랑의 힘으로 더욱 분발(?)하여 전자기력  관련 실험을 성공적으로 마칠 수 있었다 ‘카더라’. 그러고 보니 패러데이는 찰스 배비지와 거의 동갑이니 흠좀무.

끝으로, 잘 알려지지 않은 사실인데, 에이다 부인은 암 치료 과정에서, 당시 통용되던 bleeding (또는 bloodletting) 시술 중에 사망했다. 쉽게 말해 피를 빼내는 작업이다. 옛날 사람들은 병에 걸리면 환자의 혈액에 독소가 차기 때문에 그걸 제거하면 병이 나으리라고 믿었던 모양이다. 마치 체했을 때 손가락 끝을 따는 것처럼? 그런데 그렇게 바늘로 찔러서 몇 방울 따는 것과는 비교도 못 할 정도로 피를 많이 퍼내다가 오히려 환자를 탈수와 쇼크로 인해 죽게 한 경우도 많았다고.

미국의 초대 대통령이며 세계 최초로 자기 임기만 마치고 권좌에서 물러난 지도자인 조지 워싱턴도 bleeding 중에 죽었다. 문헌을 찾아보니 그는 은퇴 후 노후로 인한 폐렴· 천식· 독감 합병증에 걸렸는데, 의사가 치료랍시고 허약한 노인의 피를 5 pint... 거의 2리터가 넘게 빼냈던 것이다. 성인 인체의 전체 혈액이 5리터 남짓이라 하며 헌혈만 해도 아주 건장한 성인 남자를 대상으로 많이 채혈할 때가 3~400ml 정도 하는데, 그의 5배가 넘는 양을 뽑아냈으니 환자의 명을 재촉하는 행위밖에 더 되었겠는가? 그 당시는 혈액에 면역 시스템이 있다는 걸 모르던 시절이었고, 육체의 생명이 피에 있다는 걸(레 17:11) 실감을 못 했었다.

http://gwpapers.virginia.edu/articles/wallenborn.html
http://www.av1611.org/amazing.html

Posted by 사무엘

C 언어는 다른 언어가 언어 차원에서 기본으로 제공해 주는 상식적인 기능이 없고, 대신 별도의 함수 호출에 의존하는 형태인 게 몇 가지 있다. 거듭제곱 연산이 대표적인 예이고, 문자열 타입도 언어가 자체 제공하지 않는다. 사실은 동적(힙) 메모리를 할당하는 기능 자체가 아예 없다.

그 이유는 간단하다. 저런 기능들은 컴퓨터 CPU 명령 차원에서 직관적으로 구현 가능하지 않기 때문이다. 그래서 연산자가 그렇게도 많다는 C 언어는 거듭제곱 연산자가 없으며 pow라는 함수를 호출해야 한다. (그나마 파스칼은 그런 함수조차도 없기 때문에, exp와 log 함수 조합으로 임의의 수의 거듭제곱을 얻어내야 한다.)

메모리 할당도 마찬가지이다. 메모리 관리는 CPU뿐만이 아니라 해당 운영체제/플랫폼이 담당하는 비중도 크기 때문에, 작은 언어인 C가 언어 차원에서 자체 제공하지는 않는 것이다. malloc, free, realloc 같은 함수를 써야 한다. 그러면 윈도우 운영체제의 C 라이브러리는 내부적으로 또 HeapCreate, HeapAlloc 같은 더 저수준의 윈도우 API를 이용해서 그런 메모리 관리 기능을 구현해 준다.

그런데 C++에서는 드디어 동적 메모리 할당과 해제 기능이 언어 차원에서 연산자로 추가되었다. 바로 new와 delete 연산자이다. 그때까지 영단어로 이루어진 연산자는 sizeof가 고작이던 것이 새로 추가되었으며, 그 후로 *_cast라든가 typeid 등 여러 영단어 연산자가 C++에 추가되었다. 메모리 할당이라면 몰라도 개체의 생성과 소멸에 따른 생성자와 소멸자 함수 호출은 언어 차원에서 책임져 줘야 하는 영역이기 때문에 별도의 연산자가 생긴 것이다.

연산자가 추가된 덕분에 일단 type casting이나 sizeof 계산을 할 필요가 없게 된 것은 좋다.

pData = new DATA[nCount];
pData = (DATA *)malloc(sizeof(DATA)*nCount);

물론 번거로운 문법 정도야 C 시절에도 매크로로 대체 가능했겠지만 말이다.

#define NEW_C(T, N)  (T *)malloc(sizeof(T)*(N))

그러나 new 연산자는 malloc 함수처럼 범용적인 void* 포인터를 되돌리는 건 지원하지 않으며, 해당 타입의 배수가 아닌 크기의 메모리도 할당할 수 없다. 그렇기 때문에 가변 길이 구조체 같은 메모리를 할당하는 건 오히려 더 불편할 수 있다.
또한 할당 아니면 해제만 지원되지 C 함수처럼 realloc 기능도 없다. C++의 메모리 연산자는 오로지 개체의 생성과 소멸에만 초점을 둔 것이다. 그렇기 때문에 이것이 기존 C의 메모리 관리 함수를 완전히 대체하지는 못할 것으로 보인다.

new 연산자로 데이터 타입을 지정한 뒤에는 new DATA[100] 처럼 배열 첨자가 올 수 있고, 아니면 new Object(x, y)처럼 해당 개체의 생성자 함수에다 넘겨 줄 인자가 올 수도 있다. 두 문법 중 오로지 하나만 허용된다.
그러므로 생성될 때 생성자 함수 인자 전달이 필요한 개체는 배열로 만들 수 없다. 그러나 인자가 필요한 생성자 함수가 존재한다 할지라도, 전부 default argument가 있어서 대체가 가능하다면 배열을 만들 수 있다.

1. new operator vs operator new

이 new 연산자(new operator)는 내부적으로 operator new라는 함수를 호출하는 형태로 구현되어 있으며, 이 특수한 함수는 나름 오버로딩이 가능하다! (delete도 마찬가지) 비록 개체를 생성하여 생성자 함수를 호출한다는 기본 기능은 C++의 특성상 불변이지만, 이 연산자가 하는 일 중 메모리를 할당하고 해제하는 계층은 customize가 된다는 뜻이다.

void *operator new(size_t size);
void operator delete(void *ptr);

operator new 함수는 첫째 인자는 무조건 포인터 크기와 같은 부호 없는 정수형이어야 한다. 부호 있는 정수형도 허용되지 않는다. 그리고 리턴값은 void *이어야 한다.
한편 delete 함수는 첫째 인자는 무조건 void *이어야 하고, 함수의 리턴값은 void여야 한다. 일단 기본적인 생김새는 malloc, free와 완전히 일치한다는 뜻.

당연한 말이지만 이 함수만 단독 호출이 가능하다.
malloc(100)을 쓸 곳에 그냥 operator new(100) 이라고만 써도 된다. 그러면 어차피 new char[100]과 비슷한 효과가 나게 된다. C++ 언어는 이 함수들의 기본 구현을 라이브러리 차원에서 제공하고 있다. 만약 기본 C/C++ 라이브러리를 사용하지 않으면서 new/delete 연산자도 쓰고 싶다면 내가 직접 이들 함수를 구현해 줘야 한다.

거기에다 나만의 인자를 추가한 operator new/delete를 만들 수 있다. 예를 들어, C/C++ 라이브러리가 사용하는 프로세스 기본 힙이 아닌 다른 곳에다가 메모리를 할당하고 싶다면 이렇게 코드를 써 주면 된다.

void *operator new(size_t size, HANDLE hHeap)
{ return HeapAlloc(hHeap, 0, size); }

HANDLE hMyHeap = HeapCreate( ... );
Object *pt = new(hMyHeap) Object( ... );

new 바로 옆에다가 전달해 주는 인자는 operator new의 둘째 이후의 인자로 전달된다. delete도 비슷한 방식으로 오버로딩 가능하다. 놀랍지 않은지?

모든 개체과 기본 자료형에서 통용되는 global scope의 operator new/delete가 있는 반면, 특정 클래스에서만 통용되는 new/delete 함수를 만들 수도 있다. 함수 프로토타입은 동일하다. 이 new/delete 함수는 굳이 static을 지정해 주지 않더라도 언제나 static으로만 선언되기 때문에, 클래스 내부에 있더라도 가상 함수 지정이나 this 포인터는 지원되지 않는다. 또한 생성자· 소멸자· 대입 연산자 등과는 달리, 파생 클래스로 상속도 된다.

2. new operator vs new[] operator

그런데, 더욱 충공깽한 사실은 new와 new[] (delete도 delete[])가 구분되어 있다는 것. 이런 구분이 언제 필요하냐 하면 소멸자 함수가 존재하는 개체의 배열을 선언할 때이다. (물론 기본 자료형이 아니라 개체를 배열로 만드는 경우는 드물지만 말이다.)
우리가 요청하는 메모리의 크기와 실제로 운영체제로부터 할당되는 메모리의 크기는 여러 가지 요인으로 인해 일치하지 않는 경우가 있으며 후자가 전자보다 대체로 더 크게 잡힌다.

배열을 delete로 해제할 때는 여기에 있던 배열 각 원소들에 대해서도 소멸자 함수를 일일이 호출해 줘야 하는데, 원래 여기에 개체가 정확하게 몇 개 있었는지를 메모리 블록만 봐서는 알 수 없게 되는 것이다.
그래서 1980년대에 C++이 처음 등장했을 때는 delete 연산자에다가 배열의 개수까지 지정을 해 줘야 했다.

int *arr = new int[nCount];
Object *ptr = new Object[nCount];
(....)
delete arr; //기본 자료형은 그냥 이렇게 지워도 무방
delete[nCount] ptr; //이놈은 흠좀무

C++은 그렇잖아도 garbage collector도 없어서 불편해 죽겠는데 배열의 원소 개수까지 프로그래머가 관리해야 한다니, 이게 말이나 되는 소리인가?

프로그래머의 원성이 빗발친 덕분에 시스템이 바뀌었다. 배열의 원소 개수는 C++이 메모리를 할당하면서 내부적으로 알아서 관리하도록 바뀌고 원소 개수를 생략 가능해졌다. 그러나 그래도 이게 배열이라는 힌트는 알아서 줘야 한다. 배열일 때와 그렇지 않을 때 C++이 메모리를 관리하고 인식하는 방식은 여전히 서로 약간 다르기 때문이다.

delete arr; delete[] ptr; 를 해도 괜찮다는 소리이지 delete arr; delete ptr; 처럼 구분이 완전히 사라진 건 아니다.

그래서 operator new/delete를 오버로드했다면 operator new[]/delete[]의 오버로드도 지원된다. 둘은 인자의 의미나 하는 일의 차이는 전혀 없다. 단지 new[]의 경우, 연산자의 리턴값 포인터에다가 곧바로 개체가 저장되지는 않는다는 차이가 존재할 뿐이다. 배열 원소 개수가 앞부분에 먼저 저장되고 그 뒤의 공간부터가 쓰인다.

자바와 C#에서 볼 수 있듯, 요즘 대세는 개체는 무조건 new로 선언하는 것이다. 그게 언어 문법까지 더 명료하게 만들어 주는 효과까지 있다. 그러나 C++은 기본 자료형이든 개체든 스택과 힙에 모두 선언 가능하고, 심지어 함수 전달도 둘 다 call by name이나 reference 방식이 모두 가능하다.

일반적으로 컴파일러들은 C++의 operator new/delete도 내부적으로는 C의 malloc/free로 구현한다. 기능이 완전히 동일한데 둘의 동작 방식이 달라야 할 이유가 전혀 없기 때문이다. 그러나 원칙대로라면 malloc으로 할당한 포인터를 delete로 해제한다거나, new로 할당한 메모리를 free로 해제하는 것은 허용되지 않는 비추 행동이다. 그렇게 섞어 쓰지는 않는 게 좋겠다.

Posted by 사무엘

C++에는 namespace라는 엄청난 키워드가 존재한다.
namespace는 소스 코드에 존재하는 수많은 명칭(심볼)들로 하여금 이들이 통용되는 구획을 강제로 구분해 준다. (명칭의 decoration도 달라지기 때문에, 링크 때도 동명의 심볼들이 서로 구분 가능함)
방대한 프로그램을 짜고 특히 남이 만든 여러 라이브러리들을 한데 뭉뚱그려 관리하다 보면 함수나 전역 변수 이름, 심지어 매크로 같은 게 겹쳐서 링크 시 충돌이 있을 수 있다. 이때 namespace는 그런 문제에 대한 근본적인 해결책이 되어 준다.

C++은 C에 비해 scope이라는 개념이 더욱 발달했다.
여기서 말하는 scope이란, 단순히 전역 변수냐 지역 변수냐 하는 생명 주기 차원이 아니라, 어떤 심볼이 언어의 문맥 차원에서 인식되고 접근이 허용되는 범위를 일컫는다.
가령, C++ 클래스 내부에 있는 static 변수는 생명 주기로 말하자면야 C의 전역 변수와 다를 바가 없다. 그러나 단순 전역 변수와는 확연하게 다른 scope을 지니고 있다. 그래서 :: 같은 연산자도 생겼다.

예전에는, 특히 C 시절에는 global이라는 기본 namespace 하나밖에 없는 것과 마찬가지였지만 C++에서는 나만의 namespace를 정의할 수 있고, 심지어 이중 삼중으로 namespace 안에 또 namespace를 만들 수도 있다. 심볼들의 입체적인 관리와 구별이 가능해진 것이다.
사실 namespace는 90년대에 나중에 추가된 키워드로, 도스 시절의 볼랜드 C++ 같은 컴파일러에서는 지원도 되지 않는다. (MFC 역시 namespace는커녕 템플릿조차 없던 시절부터 만들어져 온 클래스 라이브러리인지라, namespace를 사용한 흔적이 없음)

그런데, namespace가 하는 일은 클래스가 하는 일과 좀 중복이 있어 보인다.
클래스도 그 자체가 이미 자신만의 새로운 scope을 만들어 낸 것이기 때문이다.
클래스 내부에 public으로 선언된 static 변수 내지 함수하고,
namespace 내부에 존재하는 전역 변수 내지 함수는 언뜻 보기에 위상이 완전히 똑같다.

밖에서는 클래스::이름, 또는 namespace::이름 이렇게 ::을 써서 호칭하는 것마저 동일하다.
클래스도 안에 클래스 내지 구조체가 중첩해서 존재할 수 있으며, 심지어 클래스 내부에서만 통용되는 enum이나 typedef를 선언하는 것도 가능하다.
그럼 도대체 namespace만의 특징은 무엇이 있을까? 아래의 코드를 생각해 보자.

namespace NS {
   class A {};
   void f( A *&, int ) {}
}

//void f(NS::A *&, int) {} //이게 뭘까?

class CS {
public:
   class A {};
   static void g( A *&, int ) {}
};

이렇게만 보면 NS라는 namespace에 소속된 클래스 A와 전역 함수 f,
그리고 CS라는 클래스에 소속된 클래스 A와 전역 함수 g는 서로 그게 그거 같고 정말 차이를 발견할 수 없어 보인다.
다만, class나 struct와는 달리 namespace는 뭔가 인스턴스화하는 자료형을 만드는 것이 아니기 때문에, 닫는 중괄호 뒤에 세미콜론을 붙일 필요가 없다. 뭐, 그 정도 차이는 존재한다.

이들 각 심볼을 외부에서 접근하는 방법도 완전히 동일하다. 아래 코드를 보라.

NS::A *pfm = NULL;
NS::f(pfm, 0); //하지만 바로 f(pfm, 0)만 해도 된다. 이유는 나중에 설명

CS::A *qfm = NULL;
CS::g(qfm, 0);

그런데, namespace는 클래스에 없는 부가 기능이 좀 있다.

첫째, 바로 ADL(Argument dependent name lookup)이라는 기법이다.
C++ 컴파일러는 함수의 argument의 타입으로부터 함수의 소속 scope를 자동 추론하는 기능이 있다.
namespace NS에 속해 있는 f를 호출할 때 굳이 NS::를 할 필요가 없다.
왜냐하면 f가 받는 함수 인자 중에 이미 NS에 소속된 자료형이 존재하기 때문에, 컴파일러는 이 f를 먼저 global scope에서 살펴봐서 없으면 NS namespace 안에서도 찾아보게 된다.

함수의 인자를 이용하여 함수를 추정한다는 점에서는 함수 오버로딩의 확장판이라고 볼 수도 있겠다.
사실, 위의 소스에서 주석을 쳐 놓은 global scope의 f 함수까지 정의한다면 컴파일러는 어느 f 함수를 선택해야 할지 모호하다면서 에러를 낸다.
이런 기능은 클래스에는 존재하지 않는다. g 함수를 호출할 때는 매번 CS::g를 해 줘야 한다.

둘째, using 키워드이다.
반복되는 타이핑을 좀 줄이고 싶어하는 건 프로그래머들의 공통된 희망 사항이다.
타입 선언을 좀더 간편하게 하기 위해서 C/C++에는 typedef라는 키워드가 있고, 베이직이나 파스칼에는 구조체 참조를 좀더 간편하게 하려고 With 같은 키워드가 있다.

그와 마찬가지로 C++에는 여타 namespace에 있는 명칭을 매번 :: 연산자 없이도 바로 참조 가능하도록 using namespace 선언을 제공한다. using namespace std; 처럼 말이다.
using namespace NS를 한번 해 주면, 그 뒤부터는 NS::A *pfm 마저도 A *pfm로 축약 가능해진다.
using의 용법으로는 또 다른 것도 있는데, 설명서를 읽어 봐도 잘 모르겠다. 정말 무진장 복잡하고 저런 걸 언제 어디서 써먹으면 될지 영 감이 안 잡힌다. =_=;;
다만, namespace가 아니라 클래스에 의해 만들어진 scope에 대해서는 그런 것 역시 지원되지 않는다.

셋째, namespace p = FS; 처럼, namespace에다 별명(alias)을 붙여 쓰는 것도 가능하다. 길고 복잡한 다단계 namespace를 손쉽게 축약하는 방법이다. 저런 문법도 있다니, 가히 충격과 공포.

끝으로, 이름 없는 namespace는 마치 C 시절의 static 전역변수/함수처럼, 해당 번역 단위(소스 코드; translation unit) 바깥으로 함수나 변수 심볼이 노출되지 않게 하는 역할을 한다는 것도 알아 두면 좋다.
이 정도 되면 namespace는 C++ 언어에서는 단순히 클래스 이상으로 자신만의 역할이 있다고도 볼 수 있겠다.

가장 먼저 언급한 ADL에 대해서는 비판은 있다. namespace에다가 일종의 예외 규정을 만드는 것이나 마찬가지이기 때문에 C++ 문법을 더욱 복잡하게 하고 컴파일러 만들기도 난해한 언어로-_- 만드는 데 일조했기 때문이다. 그러나 프로그래밍의 편의를 위해서 ADL은 어쩔 수 없이 꼭 필요하기도 하다. 이게 없으면 다른 namespace에 소속되어 있는 클래스의 오트젝트에 대해서는 연산자 오버로딩조차도 제대로 못 하게 되는 경우가 생길 수도 있기 때문이다.

참고로 자바나 C#처럼 C++보다 나중에 등장한 본격 객체 지향 언어들은 C++처럼 global scope이라는 게 존재하지 않는다. 전역 함수나 전역 변수라는 게 애초부터 존재하지 않으며 모든 심볼들은 무조건 클래스에다 소속되어 있어야 한다. 또한 이런 언어들은 C++ 같은 텍스트 include라든가 링크라는 개념이 없으며, 클래스가 곧 패키지요 namespace의 형태로 구조가 잘 짜여 있다. 그래서 C++처럼 namespace를 별도로 갖고 있지는 않다.

Posted by 사무엘

※ CreateFont

받는 인자가 무려 14개나 되어, Win32 API 전체를 통틀어 손꼽힐 정도로 받아들이는 인자가 많다. MSDN 레퍼런스 없이는 함부로 꺼내 쓰지도 못한다.
그렇다고 해서 딱히 포인터를 전달한다거나, 결과값을 받는다거나 하는 것도 아니고 인자들은 다 단순한 int 아니면 문자열들이다. 이 값들을 LOGFONT라는 구조체에다 담아서 한꺼번에 전달하는 CreateFontIndirect라는 함수가 별도로 있기도 하다.

하지만 실제로 쓰이는 인자는 글꼴 이름과 크기(가중치 100), 그리고 아주 가끔 빌드/이탤릭 여부(가중치 20) 정도가 진짜 전부이다.
전문적인 워드/그래픽 프로그램이 아니고서야 장평값이 다르다거나 기울여진 상태로 글자를 찍을 일이 있기나 할까? 운영체제가 기본으로 지정한 퀄리티(안티앨리어싱 여부) 말고 다른 걸 지정할 일도 거의 없기는 마찬가지. 좀더 간단한 형태의 함수가 있었으면 좋겠다. MFC의 CFont::CreatePointFont()처럼 말이다.

※ CreateProcess

인자 개수 10개. 프로그램을 실행하는, 좀더 정확히 말하면 프로세스를 생성해 주는 가장 저수준 함수이다.
실생활에서는 파일 이름과 매개변수(가중치 100)만 있으면 거의 다 통용되고, 거기에다 초기 시작 디렉터리와 윈도우 초기 배치 방식을 나타내는 SW_* 값 정도만 있으면 될 것이다(가중치 20).

하지만 이 함수 역시 사용하기는 무진장 까다롭다. 파일 경로를 나타내는 버퍼는 read only여서는 안 되고 write 가능한 영역에 있어야 한다. 운영체제가 이 문자열을 그대로 strtok 스타일로 tokenize를 했다가 다시 원래 형태로 되돌려 주기 때문이다. null 문자를 잠시 삽입하므로 이는 버퍼를 수정하는 행위임.
디버거 붙일지 여부, 각종 보안 설정, 환경 변수 값, 심지어 멀티모니터 환경에서 프로그램을 초기에 띄울 모니터 위치 등등.. 별별 정보를 다 지정 가능하기 때문이다.

게다가 리턴값으로는 새로 생긴 프로세스 및 스레드의 식별자와 핸들 같은 것도 돌아오는데, 그 핸들은 이 함수를 호출한 프로세스가 알아서 Close 해 줘야 된다. 여간 손이 많이 가는 게 아니다.
MS는 프로그램을 실행할 때 16비트 시절의 잔재인 WinExec 함수를 사용하지 말고 이 함수를 사용할 것을 권하나, WinExec의 간편함(달랑 명령줄과 윈도우 배치 방식만 넘겨주면 됨!)의 유혹을 뿌리치기는 쉽지 않을 것이다. 사실 WinExec도 이제는 내부적으로 CreateProcess를 호출하는 방식으로 실행된다.

※ CreateFile

인자 개수 7개. C 표준 함수에 있는 fopen처럼 파일 이름과 용도(많지도 않다. 읽기 아니면 신규 생성)만 있었으면 좋겠지만, 역시 운영체제 API이다 보니 보안 관련, 파일 공유 여부 같은 잡다한 정보들이 엄청 많이 들어간다. 파일을 그저 문서의 열기/저장 기능 구현 용도로나 쓴다면 대부분의 세부 옵션들은 필요하지 없으며, 그냥 디폴트만 넘겨 주면 된다.
사실 이 함수는 디스크 상의 파일뿐만 아니라 파일의 형태로 표현 가능한 각종 운영체제 오브젝트들을 생성할 수도 있는 상당히 다재다능한 녀석이다. 피타고라스는 세상만물이 수라고 말했다면, 유닉스에서는 모든 게 파일이라고 한다. 윈도우 운영체제도 그런 철학이 아주 없지는 않다.

※ GetOpenFileName

우리에게 친근한 파일 열기 대화상자를 꺼내 주는 함수. 이제 얘는 인자로 일일이 입력 정보를 받는 방식을 애초부터 포기하고, 대신 크고 아름다운 구조체만을 받는 형태이다. C++로는 응당 클래스를 만들어 쓴다. MFC의 CFileDialog처럼.

하지만 실제로 자주 쓰이는 정보는 열기/저장 여부, 시작 디렉터리, 파일 포맷 필터 말고 있나? (가중치 100)
거기에다가 아주 가끔씩 파일 복수 선택 여부라든가 '읽기 전용으로 열기' 같은 자잘한 옵션만.. (가중치 30)
이렇게 굳이 구조체 만들 필요 없이 간단하게 실행이 끝나는 함수도 좀 있었으면 좋겠다는 생각을 꽤 자주 하곤 했다.

※ TaskDialogIndirect

너무나 클래식한 API인 MessageBox 함수를 대체하는 새로운 UI 대화상자 함수로, 윈도우 비스타에서 처음으로 추가된 걸로 잘 알려져 있다.
다른 건 '메시지 박스' 그대로 쓰면 되는데 "다음부터 이 메시지 표시하지 않음" 체크 같은 딱.. 2% 아쉬운 면모만 보충하고 싶을 때... 이 함수가 가히 구세주이다. 참고로 이 함수를 쓰려면 공용 컨트롤 6.0 매니페스트가 필수라는 걸 잊지 말자.

물론 얘는 TaskDialog와 TaskDialogIndirect로 아예 두 버전으로 나뉘어 있고, 쓸데없이 괜히 함수 프로토타입만 복잡한 게 아니라 진짜로 사용자가 실제로 쓸 수 있는 기능이 엄청 많은 게 맞다. 최근에 만들어진 만큼 API를 비교적 잘 설계했다는 생각이 든다. 하지만 정확하게 기억은 안 나는데 TaskDialog에는 정작 내가 꼭 써야 하는 customize 기능이 빠져 있어서 어쩔 수 없이 훨씬 더 복잡한 TaskDialogIndirect 함수만 써야 했던 것 같다. 그건 아쉬운 점.

대화상자의 제목, 큰 제목, 본문, 각 버튼의 모양, 링크, 라디오 상자 등등등...
이건 구조체가 아니라 아예 대화상자 생성 스크립트(XML 기반)를 받게 해도 이상할 게 없어 보인다.
최신 MFC에는 이 task dialog를 감싸는 클래스가 "당연히" 추가되어 있으며, 각종 상업용 GUI 패키지들에는 XP 이하 운영체제에다가도 task dialog를 자체 구현한 솔루션이 있기도 하다.

Posted by 사무엘

C++ typename 키워드의 용법은 크게 두 가지이다. 그러나 주된 목적은 동일하다. 다음에 나오는 명칭이 변수도 될 수 있고 변수의 타입 이름이 될 수도 있는 문맥일 때, 이것이 명백하게 후자임을 알려 주는 것이다.

먼저, typename은 잘 알다시피 템플릿 인자를 선언할 때 class 대신 쓸 수 있다.

template<class T> void Swap(T& a, T&b );
template<typename T> void Swap(T& a, T&b );

위의 두 줄은 의미상 완전히 동일하다.
템플릿이 C++ 언어에 처음으로 추가되었던 당시에는 typename이라는 키워드가 없었고 템플릿 인자를 선언할 때에도 class를 썼던 것이다.
그러나 이것은 의미상으로 문제가 있었다. 아래의 예를 보자.

template <class T, int N>
class MyClass {
public:
    T data[N];
};

MyClass<int, 20> obj;

템플릿 인자로는 잘 알다시피 자료형 이름 내지 정수 숫자가 올 수 있다.
그런데 int N에 해당하는 템플릿의 인자로는 마치 일반 함수의 인자처럼 int 값에 해당하는 20이 쓰였다. 그런데, class T에 해당하는 첫째 인자는 그럼 T라는 클래스에 속하는 개체가 쓰인단 말인가?

전혀 그렇지 않다. 여기서는 진짜로 특정 type에 속하는 20 같은 값이 아니라, type 자체가 인자로 와야 하기 때문이다.
그래서 의미상 완전히 다르다는 걸 표현하기 위해 typename이라는 키워드를 class 대신 사용할 수 있게 되었다. 매우 바람직한 조치이다. class라는 키워드는 이제 진짜로 새로운 클래스를 선언할 때만 쓰도록 하자.

그리고 다음 용법이 개념상으로 진짜 중요하다. scope resolution과 관계가 있다.
A가 클래스 이름일 때 A::B라는 표현을 썼다면, C++의 특성상 B는 A의 멤버 변수일 수도 있고, A 클래스 내부에 선언된 다른 타입(클래스, 구조체 따위)의 이름일 수도 있다. 그 클래스 내부에 무엇이 선언돼 있냐에 따라서 해석이 달라진다. 처리가 어렵다.

그런데 설상가상으로 A 자체가 실제로 무슨 타입이 들어올지 모르는 템플릿 클래스의 인자라면? B에 대한 해석은 그야말로 귀에 걸면 귀걸이, 코에 걸면 코걸이가 될 수밖에 없어진다. A의 실체가 무엇이건 B의 정체는 컴파일 시점 때 다 결정되어야 하는데 말이다.

그럴 때 typename A::B를 써 주면, B는 A가 무엇이건 상관없이 변수가 아니라 말 그대로 type 이름으로 처리되어야 함을 컴파일러에게 알려 준다. 이 키워드는 절대적인 모호성 해결보다는, C++의 문법 해석의 복잡성을 좀 줄이고 컴파일러 개발을 더 수월하게 만들려는 목적이 더 크다고 보면 정확하다.
자, 이번에도 이해를 돕기 위해 예제 코드를 보자.

template<typename T>
class MyClass {
public:
    struct MYSTRUCT {
    };
    static MYSTRUCT dat;

    typename T::COMP pp;
};

struct SAMPLE {
    struct COMP {
    };
};

MyClass<SAMPLE> obj;

바로 이런 식으로 MyClass가, 자신의 템플릿 인자 T가 내부적으로 또 갖고 있는 COMP라는 구조체를 이용하기 위해서는 pp를 저렇게 typename을 줘서 선언해야 한다. COMP를 자료형 이름임을 명확하게 해 줄 필요가 있다.

비슷한 이유로 인해,

template<typename T>
typename MyClass<T>::MYSTRUCT MyClass<T>::dat;

템플릿 클래스 내부에 있든 구조체 형태로 된 static 멤버를 밖에서 또 정의해 줄 때, typename을 넣어 줘야 한다.
똑같이 MyClass<T>::로 시작하는 명칭이지만 typename이 선행된 MYSTRUCT는 자료형이고, dat는 멤버 변수로 인식되는 근거가 여기에 있는 것이다.
늘 생각하는 것이지만 C++의 세계는 참으로 심오하다. -_-;;

Posted by 사무엘

1.
병특 회사에서 근무하던 시절의 일이다.
그때 본인은 본업을 넘어-_-, ActiveX 컨트롤을 만들어 관리하던 적이 있었다.
(사용자들이 아무리 ActiveX 욕하고 우리나라가 무슨 MS 공화국이네 뭐네 하면서 까도, 일선 개발자들은 위에서 까라면 깔 수밖에 없다. 더구나 본인은 국방부 시계가 돌아가던 중! ^^;;; )
ActiveX는 내부에 플래시 UI를 하나 만들어서 플래시는 웹 상에서 사용자와 소통을 하고, ActiveX는 플래시와 소통을 하면서 플래시만으로 하기 힘든 네이티브 코드를 수행했다. 내가 왕년에 저런 일까지 했다니..

그런데 문제가 있었다. 정확하게는 기억이 안 나지만, ActiveX든 플래시든.. 뭔가 로컬에 있는 파일을 참조하는 건 아무 문제가 없었는데 웹에 있는 놈을 가져오는 건 아무 이유 없이 도무지 되지 않고 작동을 거부하는 것이었다.
먼 옛날 일이 됐으니 망정이지, 이것 때문에 당시 회사에 환멸을 느낄 정도로 좌절하고 삽질했었다. -_-;;

문제의 원인은 보안이었다. 그 당시 갓 출시된 플래시 7이던가 8이던가.. 하필 그때부터 보안 정책이 딱 바뀌어 플래시의 액션스크립트는 아무 웹에서나 정보를 덥석 가져오지 못하게 되었다.
그 반면, 내 로컬 컴퓨터의 ....\flash player\#security\flashplayertrust 이런 디렉터리에다가 configuration file을 만들어서 접근을 허용하는 웹 주소를 먼저 적어 줘야 하고, 플래시는 허용된 웹으로만 접근할 수 있다.
자세한 정보: http://kb2.adobe.com/cps/116/1165eb90.html

어쨌든 이것 때문에.. 가장 권한이 많고 강력한 ActiveX가 DllRegisterServer를 통해 등록될 때 저 flashplayertrust에다가 우리 플래시에 대한 정보를 덩달아 등록해 주고, 등록 해제될 때 그 정보를 삭제하도록 함으로써 문제는 일단락되었던 걸로 기억한다. ActiveX는 네이티브 코드인 관계로 파일, 레지스트리, 웹 등에 다 접근이 되고, 심지어 Win32 API를 직접 호출해서 뭐든 다 할 수 있으니.. 사기 유닛이다.

물론 오늘날은 다른 웹 표준과 RIA 기술도 풍부한데 저런 무식한 방법을 쓰는 건 곤란하다.
참고로 플래시에 전설의 flv 동영상이 추가된 게 그 무렵부터일 것이다. 유튜브가 그때 막 태동했으니 말이다. 플래시가 벡터 드로잉 애니메이션뿐만 아니라 일반 비디오 플레이어 분야도 섭렵하기 시작했으며, 덕분에 이제 인터넷으로 동영상 볼 때 ActiveX 설치를 요구하는 사이트는 개념 없다는 소리를 듣기 시작하게 됐다.

2.
안드로이드 어플 만들면서도 비슷한 경험을 했다. 아놔 다른 프로그램에서는 잘 되는 환경설정 변경이 왜 도대체 안 되고, 기껏 되더라도 왜 내가 바꾼 환경설정이 다른 곳에 도무지 적용이 안 되는지.. 함수 호출 결과는 성공인데.. 그 뒤 결과는 그냥 씹히고 있던 것이다.
하루를 삽질하고 났더니 원인은 역시 매니페스트 파일에다가 android.permission.WRITE_SETTINGS , android.permission.CHANGE_CONFIGURATION 요 따위 퍼미션 요청을 안 해 놨기 때문이었다.

3.
그동안 유닉스 계열 OS에 비해 권한이나 보안 같은 관념이 너무 약하던 윈도우도, 비스타부터는 그쪽으로 좀더 엄격해졌다.
잘 알다시피 사용자 계정 컨트롤(UAC)라는 게 추가됐으며, 프로그램을 관리자 권한으로 실행할 때와 그렇지 않을 때에 허용되는 권한의 차이가 매우 커졌다. 가령, 관리자 권한이 아니면 '내 문서' 말고 다른 디렉터리에다가는 파일을 제대로 만들지도 못한다.

그리고 이 프로그램이 요구하는 권한을 명시하는 게 가능해졌다.
아무 권한에서나 실행 가능한지, 무조건 관리자 모드에서 실행돼야 하는지 하는 걸 말이다.
지정은 EXE 내부의 매니페스트 XML에다가 하면 된다. 그 개념은 이미 윈도우 XP에서 시스템 DLL의 로딩 방식을 제어하기 위해 도입된 바 있으므로 새삼스러울 게 없다.
비주얼 C++ 2008부터는 링커 옵션에 이걸 바로 지정해 주는 게 추가됐다. 그 이전 버전에서는 사용자가 직접 xml 파일을 손으로 써서 링크해 주면 된다.

스크린 키보드처럼 장애인 Accessbility용 프로그램은 의외로 높은 보안 수준이 필요하다.
내가 받은 입력에 대한 결과를 시스템 모든 프로그램에다가 끼쳐야(키보드 입력 흉내) 하기 때문에
이런 프로그램은 별도의 인증을 거쳐야 운영체제가 그 정도의 권한을 허락하게 되어 있다.
그런 인증을 거치지 않은 "<날개셋> 입력 패드"는, 사용자가 직접 관리자 권한으로 실행해 주지 않으면,
자기보다 권한 등급이 높은 프로그램에다가는 글자 입력을 전달해 줄 수 없다.

글을 맺는 소감:
삽질해야 하는 게 싫다. -_-;;
지금 유닉스 명령어 익히느라 땀 뻘뻘 흘리는 걸 보면, 옛날에 지금보다 영어도 훨씬 더 못 하던 시절에 도스 명령은 어째 알아서 외웠는지 궁금하다.
지금 이놈의 안드로이드 때문에 삽질하는 걸 보면, 옛날에 윈도우 API는 어째 공부했는지 내가 생각해도 나 자신을 이해할 수 없다.
그때는 삽질을 삽질이라고 여기지 않고 전적으로 재미로 했기 때문에 프로그래밍에 재미를 붙일 수 있었던 것 같다.

Posted by 사무엘