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

1. 심벌 검색 기능의 퇴화(?)

예전에도 글에서 언급한 적이 있지만, 비주얼 C++에는 Alt+F12를 누르면 심벌 검색을 할 수 있다. 주어진 프로젝트의 소스 코드에 등장하는 모든 명칭들(클래스, 함수, 전역 변수 등등)의 선언과 정의가 있는 곳을 곧바로 찾아갈 수 있으니 이건 매우 편리한 기능이 아닐 수 없다.

이 기능이 특히 강력한 이유는 내가 해당 프로젝트의 내부에서 선언한 명칭뿐만 아니라, 인클루드 파일에 있는 명칭들도 전부 조회할 수 있기 때문이다. 따라서 C/C++ 라이브러리에 있는 함수나 윈도우 플랫폼 SDK 내지 MFC 라이브러리에 있는 방대한 명칭들도 다 조회가 되어서 해당 명칭의 출처를 쉽게 알아낼 수 있다.

어차피 소스 코드를 빌드하여 precompiled header나 인텔리센스 정보를 만들 때 이런 정보들을 다 한 번씩 파싱을 하기 때문에, 심벌 검색은 최적화된 자체 데이터베이스를 대상으로 신속하게 행해진다. 무식하게 수백, 수천 개의 헤더와 소스 파일들을 텍스트 형태로 찾는 find in files 형태가 아니다.

그런데, 비주얼 C++ 2010을 보니 심벌 검색은 해당 프로젝트에서 직접 선언한 명칭만 가능하고, 그 프로젝트가 stdafx.h에다가 인클루드하여 사용하는 플랫폼 SDK, MFC 같은 것들의 명칭은 조회되지 않는다.
200x 시절과 동일하게 '참조에서 찾기' 옵션을 켜고, 검색 범위를 'All components'로 바뀌었는데도 여전하다. 이 기능에 무슨 문제가 생겼는지 궁금하다.

(WM_CREATE 위치가 뜨는 2003 좌, 하지만 뜨지 않는 2010 우)

물론, 소스 코드에서 MFC나 플랫폼 SDK의 명칭을 참조하는 부분에서 F12를 눌러 보면 여전히 해당 명칭의 선언부로 가긴 간다. 하지만 명칭을 직접 입력해서 찾는 심벌 검색 기능은 왜 그게 불가능해진 걸까?

보아하니 그저 닷넷 프레임워크 라이브러리의 명칭을 조회하는 기능에만 신경 쓰느라, C++ 네이티브 개발 쪽은 지원이 간과되기라도 한 건지? 2010은 그렇잖아도 인텔리센스에다 빌드 보조 파일들이(*.sdf, *.ipch) 예전에 비하면 기겁을 할 정도로 방대해졌는데 편의 기능은 도리어 없어지면 어떡하냐 말이다.

2. 메뉴 편집기의 우클릭

C++ 프로젝트를 새로 만들거나 열어서 리소스에서 메뉴 편집기를 연다. 아, 프로젝트를 만들 필요 없이 그냥 리소스 템플릿만 하나 만들어서 메뉴를 생성해도 되겠다.

열었으면 클라이언트 화면의 빈 공간을 아무 데나 우클릭하여 메뉴 편집기에 대한 컨텍스트 메뉴를 연다. 그 후 마우스로 다른 곳을 클릭하거나, 명령을 선택하거나, ESC를 눌러서 컨텍스트 메뉴를 없앤다.
그러면 컨텍스트 메뉴가 화면 좌측 상단에 한 번 또 나타나서 사용자를 성가시게 할 것이다.

이는 명백한 버그이다. 대화상자 같은 다른 리소스 편집기에서는 우클릭을 해도 이런 현상이 생기지 않는다.
2010뿐만이 아니라 무려 2003에서도 동일한 현상이 발견된다. 거의 10년 묵은 버그라는 뜻인데 아무도 신경을 안 쓰는지 지금까지 고쳐지지 않았다.
설마 6.0에서까지 이랬을 것 같지는 않은데 잘 모르겠다. 아직도 6.0 쓰시는 분이 계시면 확인 요망.

여담이지만 마우스가 아니라 Shift+F10 같은 키보드로 컨텍스트 메뉴를 열면 이런 현상이 생기지 않는다.
그리고 화면 빈 공간이 아니라 편집 중인 메뉴 항목의 경우 우클릭하더라도 역시 그 현상이 생기지 않는다.
이건 아주 사소한 코딩 실수로 보이고, 몇 라인만 고치면 바로 제거할 수 있는 버그이다만, 10년에 가까운 시간 동안 발견하고 지적한 사람이 없었나 보다.

C#이나 VB, C++/CLI 같은 닷넷 환경의 경우, 폼(네이티브 개발 환경으로 치면 대화상자)에다가 메뉴 컴포넌트를 집어넣으면 그 자리에서 바로 메뉴를 편집할 수 있게 되어 있으니 네이티브 개발과는 환경이 꽤 다르다.
닷넷 프로그램도 기본 메뉴는 일반 윈도우 운영체제가 제공하는 표준 네이티브 메뉴 형태로 나오지 않겠나 하고 생각해 왔는데, 놀랍게도 그렇지 않다. 비주얼 스튜디오 200x와 비슷한 형태인 싸제 메뉴이다.

3. 툴바 편집기의 화면 잔상

이뿐만이 아니다.
리소스 중에서 툴바 편집기를 보면, 툴바 아이템들을 순서대로 하나씩 찍어 보기만 해도 예전 selection 흔적이 지저분한 잔상으로 잔뜩 남는다. 저건 절대로 multiple selection을 나타내는  게 아니며, WM_PAINT 메시지만 다시 받아도 잔상은 싹 없어진다.

열기, 저장, 모두 저장, 인쇄 아이콘의 테두리에 생긴 잔상들을 보라.
그리고 믿어지지 않겠지만 이건 비주얼 C++ 2003 시절부터 변함없던 버그이다!
전세계에서 압도적인 인지도와 점유율을 자랑하는 개발툴에 이런 초보적인 버그가 있다는 게 믿어지는가? 6.0은 그렇지 않았던 걸로 난 기억한다.

아이콘의 배치 순서를 조정하거나 중간에 여백을 넣기 위해서 드래그 드롭만 해도 잔상이 잔뜩 쌓인다. 구체적으로 재연 조건과 증상을 일일이 기술하기에는 구차하나, 잔상 현상은 2010에서 조금 더 심해졌다.

4. 속성 대화상자

비주얼 C++ 6.0까지는 전통적으로 가로로 길쭉한 자신만의 context-sensitive한(문맥 민감. 사용자가 키보드 포커스를 두거나 선택한 개체나 문서에 따라서 대화상자 내부 내용이 수시로 동적으로 바뀌는) 속성 대화상자가 있어서 Alt+Enter를 누르면 언제든지 그게 떴었다. old timer라면 추억의 옛날 스타일 대화상자를 기억하실 것이다.

그게 닷넷부터는 비주얼 베이직 스타일의 프로퍼티 그리드로 다 바뀌었다.
특히 프로젝트 설정 대화상자(VC6 표준 단축키 기준 Alt+F7)도 이 형태로 리모델링된 것 여러분들 다 아실 것이다.

그러나 프로퍼티 그리드가 커버하지 못하는 UI가 있었으니 그것은 바로 preview 기능이다.
비트맵, 대화상자, 메뉴 등 리소스들을 일일이 열 필요 없이 찍어 보기만 해도 이놈이 대략 어떻게 생겼는지 간략히 표시해서 보여주는 기능인데,
이건 2차원적인 공간에다 뭔가를 그려야 하기 때문에 기존 프로퍼티 그리드로 커버할 수가 없다.

그래서 별도의 버튼을 누르면 결국 과거 6.0 시절의 속성 대화상자와 비스무리하게 생긴 대화상자가 떠서 미리보기를 보여주는 기능이 들어갔다. 뭐, 여기까지는 뭐 나쁘지 않다. 메뉴나 대화상자가 좀 더 깔끔하게 그려졌으면 좋겠는데 10년 전이나 지금이나 하나도 바뀐 게 없이 똑같이 엉성하다는 건 아쉽지만 말이다.

그런데 과거의 200x 시절에는 미리보기를 보는 중에도 키보드 포커스는 각종 리소스들을 고르는 화면에서 계속 유지가 되어서 위· 아래 화살표를 누르며 리소스들을 조회할 수 있었는데,
2010부터는 뭔가를 선택하고 나면, 키보드 포커스가 미리보기 대화상자로 바뀌어 버린다. 그래서 마우스로 해당 아이템들을 일일이 찍어야 한다.

역사적으로 비주얼 C++은 4.0 때 Developer Studio (MSDEV)라는 첫 UI가 갖춰진 이래로 닷넷으로 넘어갈 때 대대적인 리모델링을 거쳤고, 2010 때는 WPF 기반으로 또 IDE의 구현체가 크게 바뀌었다.

요즘 다시 C++11 지원처럼 C++ 지원이 강화되고는 있다지만, 기존 코드들이 리팩터링되는 과정에서 예전에는 없던 사소한 버그들이 끼어 들어가는 게, MS에서 닷넷에 비해 네이티브 환경 개발에 점점 소심해지고 있다는 생각이 들어서 아쉽다. 닷넷과 관련된 개발 환경이라면 저런 버그가 들어갔을 리가 없을 텐데 말이다.

다음은 버그까지는 아니고, 비주얼 C++과 관란하여 추가로 떠오르는 생각들이다.

1. 비주얼 C++은 32비트 시절 이래로(무려 4.x부터) 80비트 초정밀 부동소숫점인 long double을 무시하고, 이것도 일반 double과 완전히 동일한 64비트 부동소숫점으로만 제공하는 것으로 잘 알려져 있다.
난 32비트 CPU에서는 10바이트 단위로 정보를 처리하는 게 불편해저서 long double이 도태한 게 아니겠나 정도로만 생각해 왔다.
그런데 나중에 알고 보니 인텔 CPU엔 80비트 부동소숫점을 연산하는 명령 자체는 존재한다고 한다. 단지, MS 컴파일러가 이를 활용하지 않는다고.

이것까지 지원해야 하면 %타입 문자부터 시작해서 언어 라이브러리에도 그야말로 대대적인 칼질이 가해져야 하는 건 사실일 것이다. 그런데 그렇다고 해서 있는 CPU의 기능을 컴파일러가 활용하지 않는 건 좀 문제가 있어 보이는데?
인텔 컴파일러 같은 다른 벤더 제품 중에는 long double을 쓸 수 있는 놈이 있는지 궁금하다.

2. 오늘날 거의 모든 IDE와 에디터들은 탭을 customize할 수 있다.
화면에 표시되는 탭 길이를 조절하고(보통 거의 다 4를 쓰지만), 코딩용 자동 들여쓰기를 할 때 공백을 삽입할지 탭을 삽입할지를 지정할 수 있다. 그리고 언어별로 어떤 탭 설정을 사용할지도 지정 가능하다.

그런데 여기서 한 발 더 나아가서, 읽어들이는 소스 코드의 형태를 보고 탭 컨벤션을 자동 감지하게 할 수는 없나?
space로 맞춰져 있는 소스 코드에다가 눈치 없게 탭으로 들여쓰기를 삽입한다거나 혹은 그 반대로 하는 것. 불편하다.

자동 들여쓰기를 구현했을 정도라면 앞뒤의 중괄호가 어떻게 돼 있고 whitespace들이 space인지 tab인지 주변 context들은 다 파악했다는 뜻이다.
따라서 조금만 더 센스 있게 동작하게 만드는 것은 마치 코드의 줄바꿈 문자의 종류를 자동 감지하는 것만큼이나 그렇게 어려운 일이 아니리라 여겨진다.

Posted by 사무엘

전산학의 초창기이던 1950년대 후반엔 프로그래밍 언어의 조상이라 할 수 있는 코볼, 포트란 같은 언어가 고안되었다. 그리고 이때 범용적인 계산 로직의 기술에 비중을 둔 알골(1958)이라는 프로그래밍 언어가 유럽에서 만들어졌는데, 이걸 토대로 훗날 파스칼, C, Ada 등 다양한 언어들이 파생되어 나왔다.

이때가 얼마나 옛날이냐 하면, 셸 정렬(1959), 퀵 정렬(1960) 알고리즘이 학술지를 통해 갓 소개되던 시절이다. 구현체는 당연히 어셈블리어.;; 그리고 알골이 도입한 재귀호출이라는 게 함수형 언어가 아닌 절차형 언어에서는 상당히 참신한 개념으로 간주되고 있었다. 전산학의 역사를 아는 사람이라면, 컴퓨터를 돌리기 위해 프로그래밍 언어가 따로 만들어진 게 아니라, 프로그래밍 언어를 구현하기 위해 컴퓨터가 발명되었다는 걸 알 것이다.

알골 자체는 시대에 비해 언어 스펙이 너무 복잡하고 막연하기까지 하며, 구현체를 만들기가 어려워서 IT 업계에서 실용적으로 쓰이지 못했다. 그러나 후대의 프로그래밍 언어들은 알골의 영향을 상당히 많이 받았으니 알골은 가히 프로그래밍 언어계의 라틴어 같은 존재로 등극했다.

물론, 그로부터 더 시간이 흐른 오늘날은 알골의 후예에 속하는 언어인 C만 해도 이미 라틴어 같은 전설적인 경지이다. 중괄호 블록이라든가 C 스타일의 연산자 표기 같은 관행은 굳이 C++, 자바, C# 급의 언어 말고도, 자바스크립트나 PHP처럼 타입이 엄격하지 않고 로컬이 아닌 웹 지향 언어에도 그런 관행이 존재하니 말이다.

C가 먼저 나온 뒤에 거기에 OOP 속성이 가미되어 C++이라는 명작/괴작 언어가 탄생했다. C가 구조화 프로그래밍을 지원하는 고급 언어에다가 어셈블리어 같은 저급 요소를 잘 절충했다면, C++은 순수 OOP 개념의 구현보다는 역시 OOP 이념을 C 특유의 성능 지향 특성에다가 적당히 절충을 잘 했다. 그래서 C++이 크게 성공할 수 있었다.

잘 알다시피 C/C++은 모듈이나 빌드 구조가 컴파일 지향적이며, 거기에다 링크라는 추가적인 작업을 거쳐서 네이티브(기계어) 실행 파일을 만드는 것에 아주 특화되어 있다.

번역 단위(translation unit)라고 불리는 개개의 소스들은 프로그래밍에 필요한 모든 명칭들을 텍스트 형태의 다른 헤더 파일로부터 매번 include하여 참조한 뒤, 컴파일되어 obj 파일로 바뀐다.
한 번역 단위에서 참조하는 외부 함수의 실제 몸체는 어느 번역 단위에 있을지 알 수 없다. 어차피 링크 때 링커가 모든 obj 파일들을 일일이 뒤지면서 말 그대로 연결을 하게 된다.

이 링크를 통해 드디어 실행 파일이나 라이브러리 파일이 최종적으로 만들어진다. 실행 파일은 대상 운영체제가 인식하는 실행 파일 포맷을 따라 만들어지지만 static 라이브러리는 그저 obj들의 모음집일 뿐이기 때문에 lib 파일과 obj 파일은 완전히 같지는 않아도 내부 구조가 크게 차이가 나지 않는다.

이런 일련의 컴파일-링크 계층이 C/C++을 로컬 환경에서의 매우 강력한 고성능 언어로 만들어 주는 면모가 분명 있다. 또한 197, 80년대에는 컴퓨터 자원의 한계 때문에 원천적으로 언어를 그런 식으로 설계해야 하기도 했다.
그러나 오늘날은 대형 프로젝트를 진행할 때 C/C++의 그런 디자인은 심각한 비효율을 초래하기도 한다. 내가 늘 지적하듯이 C보다도 특히 C++은 안습할 정도로 빌드가 너무 느리고 생산성이 떨어진다.

그에 반해 자바는 문법만 살짝 비슷할 뿐 디자인 철학은 C++과는 완전히 다른 언어이다. 잘 알다시피 자바는 의도하는 동작 환경 자체가 native 기계어가 아니라 플랫폼 독립적인 자바 가상 기계이다. 컴퓨터 환경이 발달하고 웹 프로그래밍이 차지하는 비중이 커진 덕분에 이런 발상이 나올 수가 있었던 셈이다.

모든 자바 프로그램은 무조건 1코드, 1클래스이며(단, 클래스 내부에 또 다른 클래스들이 여럿 있을 수는 물론 있음), 심지어 소스 파일 이름과 클래스 이름이 반드시 일치해야 한다. 클래스가 곧 C/C++의 ‘번역 단위’와 강제로 대응한다. 그리고 컴파일된 자바 소스는 곧장 컴파일된 바이트코드로 바뀌며, 이것이 자바 VM이 있는 곳이라면 어디서나 돌아가는 실행 파일(EXE)도 되고 라이브러리(DLL, OBJ)도 된다. 물론, 여러 라이브러리들의 집합체인 JAR이라는 포맷도 따로 있기도 하고 말이다.

클래스 내부에 public static void main 메소드(멤버 함수)만 구현되어 있으면 곧장 실행 가능하다. C++은 C와의 호환을 위해 시작 함수가 클래스 없는 일반 main으로 동일하게 지정돼 있는 반면, 자바는 global scope이 존재하지 않고 모든 명칭이 클래스에 반드시 소속돼 있어야 하기 때문에 그렇다. javac 명령으로 소스 코드(*.java)를 컴파일한 뒤, java 명령으로 컴파일된 바이트코드(*.class)를 실행하면 된다.

다른 모듈을 끌어다 쓸 때도 import로 바이너리 파일을 곧장 지정하면 되니, 텍스트 파싱이 필요한 C++의 #include보다 효율적이다. 번거롭게 *.h와 *.lib (그리고 심지어 *.dll까지)를 일일이 따로 구비할 필요 없다.

요컨대 자바는 C++에 비해 굉장히 많은 자유도와 성능을 제약한 대신, C++보다 훨씬 더 손이 덜 가도 되고 빌드도 훨씬 빨리 되고 프로젝트 세팅도 월등히 더 간편하게 되게 만들어졌다. 함수 호출 규약, 인라이닝 방식, C++ symbol decoration, 링크 에러, CRT의 링크 방식, link-time 코드 생성 최적화 같은 온갖 골치 아프고 복잡한 개념들이 자바에는 전혀 존재하지 않는다.
C++이 벙커에 시즈 탱크에 터렛과 마인 등, 손이 많이 가는 테란이라면, 자바는 프로토스 정도는 되는 것 같다.

자바는 하위 호환성을 고려하지 않은 새로운 언어를 만든 덕분에 디자인상 깔끔한 것도 있지만, 상상도 못 할 편리함을 실현하기 위해 성능도 C++ 사고방식으로는 상상도 못 할 정도로 많이 희생한 것 역시 사실이다. 이는 단순히 메모리 garbage collector가 존재하는 오버헤드 이상이다.

그래서 요즘은 자바 바이트코드를 언어 VM이 그때 그때 실시간으로 네이티브 코드로 재컴파일하여, 자바로도 조금이라도 더 빠른 속도를 내게 하는 JIT(just in time)기술이 개발되어 있다. 비록 이 역시 한계가 있을 수밖에 없겠지만 한편으로는 구조적으로 유리한 점도 있다.

컴파일 때 모든 것이 결정되어 버리는 C++ 기반 EXE/DLL은 사용자의 다양한 실행 환경을 예측할 수 없으니 보수적인 기준으로 빌드되어야 한다. 그러나 자바 프로그램의 경우, VM만 그때 그때 최신으로 업데이트하여 최신 CPU의 명령이나 병렬화 테크닉을 쓰게 하면 그 혜택을 모든 자바 프로그램이 자동으로 보게 된다. 물론 C++로 치면 cout이 C의 printf보다 코드 크기가 작아지는 경지에 다다를 정도로 컴파일러가 똑똑해져야겠지만 말이다.

자바 얘기가 길어졌는데, 다음으로 C#에 대해서 좀 살펴보기로 하자.
C# 역시 네이티브 코드 지향이 아니라 닷넷 프레임워크에서 돌아가는 바이트코드 기반인 점, 복잡한 링크 메커니즘을 생략하고 C++의 지나치게 복잡한 문법과 모듈 구조를 간소화시켰다는 점에서는 자바와 문제 접근 방식이 같다.

단적인 예로, 클래스를 선언하면서 멤버 함수까지 클래스 내부에다 정의를 반드시 집어넣게 한 것, 그리고 생성자 함수의 호출이 수반되는 개체의 생성은 반드시 new를 통해서만 가능하게 한 것은 컴파일러와 링커가 동작하기 상당히 편하게 만든 조치이다. 이는 자바와 C#에 공통적으로 적용된다.

다만 C#은 자바처럼 엄격한 1소스 1클래스 체계는 아니며, 빌드 결과물로 엄연히 일반적인(=윈도우 운영체제가 사용하는 PE 포맷 기반인) EXE와 DLL이 생성된다. 물론 내부엔 기계어 코드가 아닌 바이트코드가 들어있지만 말이다.

C# 역시 클래스 내부에 존재하는 static void Main가 EXE의 진입점(entry point)이 된다. 그러나 C#은 자바 같은 1소스, 1클래스, 1모듈 구조가 아니기 때문에 여러 클래스에 동일한 static void Main이 존재하면 컴파일러가 어느 것을 진입점으로 지정해야 할지 판단할 수 없어서 컴파일 에러를 일으킨다. 링크나 런타임 에러가 아님. 진입점을 별도의 컴파일러 옵션으로 따로 지정해 주거나, Main 함수를 하나만 남겨야 한다.

여담이지만, C#의 진입점 함수는 자바와는 달리 첫 글자 M이 대문자이다. 전통적으로 자바는 첫 글자를 소문자로 써서 setValue 같은 식으로 메소드 이름을 지어 온 반면, 윈도우 세계는 그렇지 않기 때문이다(SetValue).
그리고 C#의 Main은 굳이 public 속성이 아니어도 된다. 어차피 진입점인데 접근 권한이 무엇이면 어떻냐는 식의 발상인 것 같다.

닷넷 실행 파일이 사용하는 바이트코드는 자바와 마찬가지로 기계 독립적인 구조이다. 그러나 그것의 컨테이너라 할 수 있는 윈도우 운영체제의 실행 파일 포맷(PE)은 여전히 CPU의 종류를 명시하는 필드가 존재한다. 그리고 32비트와 64비트에서 필드의 크기가 달라지는 것도 있다. 이것은 기계 독립성을 추구하는 닷넷의 이념과는 어울리지 않는 구조이다. 그렇다면 닷넷은 이런 상황을 어떻게 대처하고 있을까?

내가 테스트를 해 본 바로는 플랫폼을 ‘Any CPU’라고 지정하면, 해당 C# 프로그램은 명목상 그냥 가장 무난하고 만만한 x86 껍데기로 빌드되는 듯하다.
작정하고 x64 플랫폼을 지정하고 빌드하면 헤더에 x64 CPU가 명시된다. 뒤에 이어지는 바이트코드는 어느 CPU에서나 동일하게 생성됨에도 불구하고, 그 프로그램은 x86에서는 실행이 거부되고 돌아가지 않게 된다.

그러니, 64비트 네이티브 DLL의 코드와 연동해서 개발되는 프로그램이기라도 하지 않은 이상, C# 프로그램을 굳이 x64용으로 제한해서 개발할 필요는 없을 것이다. 다만, x86용 닷넷 바이너리는 관례적으로 닷넷 런타임인 mscoree.dll에 대한 의존도가 추가되는 반면 x64용 닷넷 바이너리는 그런 게 붙어 있지 않다. 내 짧은 생각으론, 64비트 바이너리는 32비트에서 호환성 차원에서 넣어 줘야 했던 잉여 사항을 생략한 게 아닌가 싶다.

DLL에 기계 종류와 무관한 리소스나 데이터가 들어가는 일은 옛날부터 있어 왔지만, 닷넷은 코드조차도 기계 종류와 무관한 독립된 녀석이 들어가는 걸 가능하게 했으니 이건 참 큰 변화가 아닐 수 없다. 네이티브 쪽과는 달리 골치 아프게 32비트와 64비트를 일일이 신경 쓸 필요가 없고, 한 코드만으로 x86(-64) 계열과 ARM까지 다 커버가 가능하다면, 정말 어지간히 하드코어한 분야가 아니라면, 월등한 생산성까지 갖추고 있는 C#/자바 같은 개발 환경이 뜨지 않을 수 없을 것 같다. C++과 자바, C#을 차례로 비교해 보니 그런 생각이 들었다.

Posted by 사무엘

프로그래밍을 하다 보면, 어떤 컨테이너 자료구조의 내부에 있는 모든 원소들을 순회하면서 각 원소에 대해 뭔가 동일한 처리를 하고 싶은 때가 빈번히 발생한다.
그 절차를 추상화하기 위해 C++ 라이브러리에는 algorithm이라는 헤더에 for_each라는 템플릿 함수가 있다. 다음은 이 함수의 로직을 나타낸 C++ 코드이다. 딱히 로직이라 할 것도 없이 아주 직관적이고 간단하다.

template<typename T, typename F>
void For_Each_Counterfeit(T a, T b, F& c)
{
    for(T i=a; i!=b; ++i) c(*i);
}

C++은 템플릿과 연산자 오버로딩을 통해 자료구조에 대한 상당 수준의 추상화를 달성했다.
iterator에 해당하는 a와 b는 그렇다 치더라도, 여기서 핵심은 c이다.
F가 무엇인지는 모르겠지만, 어쨌든 c는 함수 호출 연산자 ()를 적용할 수가 있는 대상이어야 한다.
그럼 무엇이 가능할까? 여러 후보들이 있다.

일단 C언어라면 함수 포인터가 떠오를 것이다. 함수 포인터는 코드를 추상화하는 데 지금까지 고전적으로 쓰여 온 기법이다.

void foo(char p);

char t[]="Hello, world!";
For_Each_Counterfeit(t, t+strlen(t), foo);

C++에서는 클래스가 존재하는 덕분에 더 다양한 카드가 생겼다. 클래스가 자체적으로 함수 호출을 흉내 내는 연산자를 갖출 수 있기 때문이다.

class MyObject {
public:
    void operator()(char x);
};

For_Each_Counterfeit(t, t+strlen(t), MyObject());

그리고 더욱 기괴한 경우이지만, 클래스 자신이 함수의 포인터로 형변환이 가능해도 된다.

class MyObject {
public:
    typedef void (*FUNC)(char);
    operator FUNC();
};

For_Each_Counterfeit(t, t+strlen(t), MyObject());

C++ 라이브러리에는 functor 등 다양한 개념들이 존재하지만, 그 밑바닥은 결국은 C++ 언어의 이런 특성들을 사용해서 구현되어 있다.
여기서 재미있는 점이 있다. 다른 자료형과는 달리 함수 포인터로 형변환하는 연산자 오버로드 함수는, 자신이 가리키는 함수의 prototype을 typedef로 미리 만들어 놓고 반드시 typedef된 명칭으로 선언되어야 한다는 제약이 있다. 이것은 C++ 표준에도 공식적으로 명시되어 있는 제약이라 한다.

이런 어정쩡한 제약이 존재하는 이유는 아마도 함수 선언문에다가 다른 함수를 선언하는 문법까지 덧붙이려다 보니, 토큰의 나열이 너무 지저분해지고 컴파일러를 만들기도 힘들어서인 것 같다. 이 부분에서는 아마 C++ 위원회에서도 꽤 고민을 하지 않았을까.
안 그랬으면 형변환 연산자 함수의 prototype은 아래와 비슷한 괴상한 모양이 됐을 것이다. 실제로 이 함수의 full name을 undecorate한 결과는 이것처럼 나온다.

    operator void (*)(char)();

비주얼 C++에서는 함수를 저렇게 선언하면 그냥 * 부분에서 '문법 에러'라는 불친절한 말만 반복할 뿐이지만, xcode에 기본 내장되어 있는 최신형 llvm 컴파일러는 놀랍게도 나의 의도를 간파하더이다. “함수 포인터로 형변환하려면 반드시 typedef를 써야 합니다”라는 권고를 딱 하는 걸 보고 적지 않게 놀랐다. 이런 차이도 맥북을 안 쓰고 오로지 비주얼 C++ 안에서만 틀어박혀 지냈다면 경험하기 쉽지 않았을 것이다. 우왕~

() 연산자 오버로딩은 this 포인터가 존재하는 C++ 클래스 멤버 함수이며 static 형태가 있을 수 없다.
그러나 함수 포인터로의 형변환 연산자 오버로딩은 this가 없으며 C 스타일의 static 함수와 같은 위상이라는 차이가 존재한다.
두 오버로딩이 모두 존재하면 어떻게 될까? 혹시 모호성 오류라도 나는 걸까?

그런 개체에 함수 호출 ()가 적용되는 경우, () 연산자가 먼저 선택되며, 그게 없을 때에 한해서 함수 포인터 형변환이 차선책으로 선택된다. 모호성 오류가 나지는 않는다.
포인터 형변환 연산자와 [] 연산자가 같이 있을 때 개체에 배열 첨자 참조 []가 적용되는 경우, 역시 [] 가 먼저 선택되고 그게 없을 때 포인터 형변환이 차선으로 선택되는 것과 비슷한 맥락이라 볼 수 있다.

그래서 클래스와 연산자 오버로딩 덕분에 저런 문법이 가능해졌는데, C++11에서는 그걸로도 모자라 또 새로운 문법이 추가되었다. 이른바 람다 함수.

For_Each_Counterfeit(t, t+strlen(t), [](char x) { /* TODO: add your code here */ } );

람다 함수는 코드가 들어가야 할 곳에 함수나 클래스의 작명 따위를 신경쓰지 않고 코드 자체만을 직관적으로 곧장 집어넣기 위해 고안되었다. 세상에 C++에서 OCaml 같은 데서나 볼 수 있을 법한 개념이 들어가는 날이 오다니, 신기하지 않은가?

덕분에 C++은 C언어 같은 저수준 하드웨어 지향성에다가 성능과 이념을 적당히 절충한 수준의 객체지향을 가미했고, 90년대 중반에는 템플릿 메타프로그래밍 개념을 집어넣더니, 이제는 함수형 언어의 개념까지 맛보기로 도입한 가히 멀티 패러다임 짬뽕 언어가 되었다.

함수를 값처럼 표현하기 위해서 lambda 같은 예약어가 별도로 추가된 게 아니다. C/C++은 태생상 예약어를 함부로 추가하는 걸 별로 안 좋아하는 언어이다. (그 대신 문법에 혼동이 생기지 않는 한도 내에서 기호 짬뽕을 좋아하며 그래서 사람이나 컴파일러나 코드를 파싱하는 난이도도 덩달아 상승-_-) 보아하니 타입을 선언하는 부분에서는 배열 첨자가 먼저 오는 일이 결코 없기 때문에 []를 람다 함수 선언부로 사용했다.

람다 함수는 다른 변수에 대입되어서 두고두고 재활용이 가능하다. 그래서 C/C++에서는 전통적으로 가능하지 않은 걸로 여겨지는 함수 내부에서의 함수 중첩 선언을 이걸로 대체할 수 있다.

어떤 함수 안에서 특정 코드가 반복적으로 쓰이긴 하지만 별도의 함수로 떼어내기는 싫을 때가 있다. 굳이 함수 호출 오버헤드 때문이 아니더라도, 해당 코드가 그 함수 내부의 지역변수를 많이 쓰기 때문에 그걸 일일이 함수의 매개변수로 떼어내기가 귀찮아서 그런 것일 수도 있다.
이때 흔히 사용되는 방법은 그냥 #define 매크로 함수밖에 없었는데 이때도 람다 함수가 더 깔끔하고 좋은 해결책이 될 수 있다. 람다 함수는 선언할 때 캡처라 하여 주변의 다른 변수들을 참조하는 메커니즘도 언어 차원에서 제공하기 때문이다.

그렇다면 의문이 생긴다.
람다 함수는 그럼 완전히 새로운 type인가?
기존 C/C++에 존재하는 함수 포인터와는 어떤 관계일까?
정답부터 말하자면 이렇다. 람다 함수는 비록 어쩌다 보니 () 연산을 받아 주고 함수 포인터가 하는 일과 비슷한 일을 하게 됐지만, 활용 형태는 함수 포인터하고 아무 관련이 없으며 그보다 더 상위 계층의 개념이다.

템플릿과 연동해서 쓰인다는 점에서 알 수 있듯, 람다 함수는 함수 포인터와는 달리 calling convension (_stdcall, _cdecl, _pascal 나부랭이 기억하시는가?)이고 리턴값이 나발이고간에 아무 상관이 없다. 그저 코드상에서 함수를 값처럼 다루는 걸 돕기 위해 존재하는 추상적인 개념일 뿐이다. 뭔가 새로운 type이 아니기 때문에 람다 함수를 변수에다 지정할 때는 auto만을 쓸 수 있다. 즉, 다른 자료형이 아닌 람다에 대해서는 auto가 선택이 아니라 필수라는 뜻이다.

auto square=[](int x) { return x*x; };
int n = square(9); //81

square는 템플릿 같은 함수가 아니다. 이 함수의 리턴값은 x*x로부터 자동으로 int라고 유추되었을 뿐이다. [](int x) -> int 라고 명시적으로 리턴 타입을 지정해 줄 수도 있다. 구조체 포인터의 멤버 참조 연산자이던 -> 가 여기서 또 화려하게 변신을 한 셈임. 우와!

또한, sizeof(square)을 한다고 해서 포인터의 크기가 나오는 게 아니다. 사실, 람다 함수에다가 sizeof를 하는 건 void에다가 sizeof를 하는 것만큼이나 에러가 나와야 정상이 아닌가 싶다. 그런 개념하고는 아무 관계가 없기 때문이다.

람다는 함수 포인터가 아니기 때문에, square에다가 자신과 프로토타입이 같은 다른 람다 함수를 대입할 수 있는 건 아니다. 함수 포인터의 역할과 개념을 대체할 뿐, 그 직접적인 디테일한 기능을 대체하지는 못한다. 그렇기 때문에 콜백 함수를 받는 문맥에서

qsort(n, arrsize, sizeof(int), [](const void *a, const void *b) { return *((int*)a) - *((int*)b); } );

구닥다리 C 함수에다가 최신 C++11 문법이라니, 내가 생각해도 정말 변태 같은 극단적인 예이다만,
이런 식으로 람다 함수를 집어넣을 수도 없다.

요컨대 람다 함수는 코드의 추상화에 도움을 주고 종전의 함수 포인터 내지 #define, 콜백 함수 등의 역할을 대체할 수 있는 획기적인 개념이다. C++ 철학대로 디자인된 여타 C++ 라이브러리와 함께 사용하면 굉장한 활용 가능성이 있다. 그러나 이것은 함수 포인터에 대한 syntatic sugar는 절대 아니라는 걸 유의하면 되겠다.

Posted by 사무엘

지금은 C++11이라고 개명된 C++ 확장 규격인 C++0x에는 잘 알다시피 여러 참신한 프로그래밍 요소들이 추가되었다. 몇 가지 예를 들면, 상당한 타이핑 수고를 덜어 줄 걸로 예상되는 auto 리뉴얼, 숫자와 포인터 사이의 모호성을 해소한 nullptr, 그리고 숫자와 enum 사이의 모호성을 해소한 enum class가 있다.

그런데 이것 말고도 C++11에는 아주 심오하고도 재미있는 개념이 하나 또 추가되었다. 복사 생성자에 이은 이동 생성자, 그리고 이를 지원하기 위한 type modifier인 &&이다. R-value 참조자라고 불린다. 이 글에서는 이것이 왜 도입되었는지를 실질적인 코드를 예를 들면서 설명하겠다.
다음은 생성자에서 주어진 문자열의 복사본을 보관하는 일만 하는 아주 간단한 클래스이다.

//typedef const char*  PCSTR;
class MyObject {
    PCSTR dat;
public:
    MyObject(PCSTR s): dat(strdup(s)) {}
    ~MyObject() { free( const_cast<PSTR>(dat) ); }
    operator PCSTR() const { return dat; }
};

C++은 언어 차원에서 포인터를 자동으로 관리해 주는 게 전혀 없다. 그렇기 때문에 저렇게만 달랑 짜 놓은 클래스는 함부로 값을 대입하거나 함수 호출 때 개체를 reference가 아닌 value로 넘겨 줬다간, 동일 메모리의 다중 해제 때문에 프로그램이 jot망하게 된다. C++ 프로그래머라면 누구라도 위의 코드의 문제를 즉시 알 수 있을 것이다.

그렇기 때문에, 포인터처럼 외부 자원을 따로 가리키는 클래스는 복사 생성자와 대입 연산자를 별도로 구현해 줘야 한다. 구현을 안 할 거면 하다못해 해당 함수들을 빈 껍데기만 private 형태로 정의해서 접근이 되지 않게 해 놓기라도 해야 안전하다.

MyObject(const MyObject& s): dat(strdup(s))
{
    puts("복사 생성자");
}
MyObject& operator=(const MyObject& s)
{
    free(dat); dat=strdup(s.dat); puts("복사 대입");
    return *this;
}

자, 그럼 이를 이용해 그 이름도 유명한 Swap 루틴을 구현해서 복사 생성자와 대입 연산자를 테스트해 보자.

template<typename T>
void Swap(T& a, T& b) { T c(a); a=b; b=c; }

int main()
{
    MyObject a("새마을호"), b("무궁화호");
    printf("%s(%X) %s(%X)\n", (PCSTR)a,(PCSTR)a, (PCSTR)b,(PCSTR)b);
    Swap(a,b);
    printf("%s(%X) %s(%X)\n", (PCSTR)a,(PCSTR)a, (PCSTR)b,(PCSTR)b);
    return 0;
}

프로그램의 실행 결과는 다음과 같은 식으로 나올 것이다.

새마을호(181380) 무궁화호(181390)
복사 생성자
복사 대입
복사 대입
무궁화호(1813B8) 새마을호(1813D0)

복사 생성자와 대입 연산자 덕분에 메모리 관리는 옳게 되었기 때문에, 이제 프로그램이 뻗는다거나 하지는 않는다.
그러나 이 방법은 비효율적인 면모가 있다. 개체의 값을 맞바꾸기 위한 세 번의 연산 작업 동안, 당연한 말이지만 메모리 할당과 해제, 그리고 문자열의 복사가 매번 발생했다. 그래서 비록 문자열 값은 동일하지만 그 문자열이 담긴 메모리 주소는 a와 b 모두 예전과는 완전히 다른 곳으로 바뀌었음을 알 수 있다.

이때 R-value 참조자를 쓰면, 이 클래스에 대해서 Swap 연산이 메모리를 일일이 재할당· 복사· 해제하는 게 아니라 a와 b가 가리키는 문자열 메모리 주소만 간편하게 맞바꾸도록 하는 언어적인 근간을 마련할 수 있다. 기존 참조자는 &로 표현하고, 이와 구분하기 위해 R-value 참조자는 &&로 표현된다. 참조자(&)는 포인터(*)와는 달리 다중 참조자(참조자의 참조자) 같은 개념이 없기 때문에, &&을 이런 식으로 활용해도 문법에 모호성이 생기지 않는다.

& 대신 &&를 이용해서 자신과 동일한 타입의 개체를 받아들이는 생성자와 대입 연산자를 추가로 정의할 수 있다. 이 경우, 이들 함수는 복사가 아닌 이동 생성자와 이동 대입 함수가 된다. 아래의 예를 보라.

MyObject(MyObject&& s)
{
    dat=s.dat, s.dat=NULL; puts("이동 생성자");
}
MyObject& operator=(MyObject&& s)
{
    //주의: 실제 코드라면 자기 자신에다가 대입하는 건 아닌지 체크하는
    //로직이 추가되어야 한다. if(&s!=this)일 때만 수행하도록.
    free(dat); dat=s.dat, s.dat=NULL; puts("이동 대입");
    return *this;
}

복사 버전과는 달리, strdup 함수 대신 그냥 포인터 대입을 썼음을 알 수 있다. 이것이 핵심이다.
그러면 s가 가리키던 메모리 영역이 내 것이 된다. 그 뒤 s가 가리키던 메모리는 NULL로 없애 줘야 한다. free 함수는 그 스펙상 자체적으로 NULL 체크를 하기 때문에, 소멸자 함수는 그대로 놔 둬도 된다.

즉, 이동 생성자와 이동 대입은 s의 값을 내 것으로 설정하긴 하나, 그 과정에서 필요하다면 s의 내부 상태를 건드려서 바꿔 놓을 수 있다. 그렇기 때문에 복사 생성자/대입과는 달리 s가 const 타입이 아니다.

이것만 선언해 줬다고 해서 Swap 함수의 동작 방식이 이동 연산으로 곧장 바뀌는 건 물론 아니다. 그랬다간 s의 상태가 바뀌고 프로그램 로직이 달라져 버리기 때문에, 컴파일러가 섣불리 동작을 바꿀 수 없다. 그렇기 때문에 Swap 함수의 코드도 move-aware하게 살짝 고쳐야 한다.

template<typename T>
void Swap(T& a, T& b)
{
    T c(static_cast<T&&>(a)); a=static_cast<T&&>(b); b=static_cast<T&&>(c);
}

즉, 개체를 생성하고 대입하는 곳에서, 가져오는 개체를 가능한 한 move로 취급하라고 명시적인 형변환을 해 줘야 한다. 이렇게 해 주고 나면 드디어 우리의 목표가 이뤄진다!

새마을호(181380) 무궁화호(181390)
이동 생성자
이동 대입
이동 대입
무궁화호(181390) 새마을호(181380)

물론, 저런 형변환 연산이 보기 싫은 사람은 <vector>에 정의되어 있는 std::move 함수로 이동 대입을 해도 되며, 보통 R-value 참조자를 설명해 놓은 인터넷 사이트들도 그 함수를 곧장 소개하고 있다. 하지만 그 함수의 언어적인 근거가 바로 이 문법이라는 건 알 필요가 있다.

생성이나 대입에서 R-value 참조자를 받지 않고 기존의 L-value 참조자만 받는 클래스에 대해서는, 이동 대입이나 생성도 자동으로 옛날처럼 복사 대입이나 생성 방식으로 행해진다.
다시 말해, Swap 함수의 로직을 저렇게 고치더라도 R-value 참조자가 구현되어 있지 않은 기존 타입들에 대한 동작은 전혀 바뀌지 않으며 컴파일 에러 같은 게 나지도 않는다. 그러니 호환성 걱정은 할 필요가 없다.

그리고 이미 눈치챈 분도 있겠지만, MFC의 CString처럼 자기가 가리키는 메모리에 대해서 자체적으로 reference counting을 하고 copy-on-modify 같은 테크닉을 구현해 놓았기 때문에, 어차피 복사 생성이나 call by value 때 무식한 오버헤드가 발생하지 않는 클래스라면, 구태여 이동 생성자나 이동 대입 연산자를 또 구현할 필요가 없다. 이동 생성/대입은 언제까지나 기존의 복사 생성/대입을 보조하기 위해서 도입되었기 때문이다.

특히 std::vector 같은 배열 컨테이너 클래스에다가 덩치 큰 개체를 집어넣거나 뺄 때 복사 생성자가 쓸데없는 오버헤드를 발생시키는 걸 막는 게 이 문법의 주 목적이다. 그렇기 때문에 딱히 smart한 복사 메커니즘을 갖추고 있지 않은 클래스를 STL 컨테이너에다 집어넣고 쓰는 C++ 코드라면, 적절한 이동 생성자와 대입 연산자를 구현해 주고 R-value 참조자를 지원하는 최신 C++ 컴파일러로 다시 빌드를 하는 것만으로도 성능 향상을 경험할 수 있다.

예전에는 배열 컨테이너 클래스들이 원소들의 일괄 삽입이나 삭제를 위해 무식한 memmove 함수를 내부적으로 쓰는 게 불가피했는데 이 역할을 이동 대입이 어느 정도 대체도 할 수 있게 됐다.
&&을 DLL symbol로 표기하기 위한 새로운 C++ type decoration도 별도로 물론 있다.

그런데 의문이 생긴다. &&의 이름이 왜 R-value 참조자인 것일까?
이 참조자는 참조자이긴 하지만, 오리지널 참조자처럼 L-value가 아니라 R-value를 취급하라고 만들어졌기 때문이다. L-value, R-value란 무엇인가? 대입문에서 좌변과 우변을 뜻한다. L-value란 값을 갖고 있으면서 동시에 대입의 대상이 될 수 있는 변수를 가리키며, R-value는 값을 표현할 수만 있지 그 자신이 다른 값으로 바뀔 수는 없는 상수, 혹은 임시 개체를 가리킨다고 보면 얼추 맞다.

아래의 코드에서 볼 수 있듯 기존 L-value 참조자는 dereference된 포인터와 같은 역할을 한다.

int& GetValue() { … }
GetValue() = 100;

int *GetValue() { … }
*GetValue() = 100;

그렇기 때문에 아래와 같은 특성도 존재한다.

void GetValue2(int& x) { x=… }

int a;
GetValue2(a); //a는 L-value이므로 OK
GetValue2(500); //에러. 당연한 귀결임

L-value 참조자가 상수값 내지 임시 생성 개체 같은 R-value를 함수의 인자로 받아들이려면, 해당 참조자는 const로 선언되어서 값의 변경이 함수 내부에서 발생하지 않는다는 보장이 되어야 한다. int&가 아니라 const int&로 말이다.

그런데 R-value 참조자는 const 속성 없이도 임시 개체나 상수값을 받아들이며, 그걸 뒤끝 없이 자유롭게 고칠 수 있다. 위의 GetValue2 함수가 int&&로 선언되었다면, 반대로 a를 전달한 게 에러가 나고 500을 전달한 건 괜찮다. a를 전달하려면 static_cast<int&&>(a)로 형변환을 해 줘야 한다. 그러면 마치 int&인 것처럼 실행되긴 한다.

R-value 참조자로 돌아온 함수의 리턴값은 말 그대로 R-value이기 때문에 대입 가능하지 않다. 그렇기 때문에 아래의 코드는 에러를 일으킨다. (R-value 참조자의 리턴값은 당연히 그 역시 R-value로 왔을 때에만 의미가 있을 것이다.)

int&& GetValue3() { … }
GetValue3() = 100; //에러

이런 R-value 참조자라는 괴상망측한 개념은 왜 도입된 것일까? 그리고 이게 앞서 이 글에서 언급한 이동 생성자/대입 연산하고는 도대체 무슨 관련이 있는 것일까?

R-value 참조자의 형태로 함수 인자로 넘어온 개체는 그 함수의 실행이 끝난 뒤엔 어차피 소멸되고 없어질 것이기 때문에 내부가 바뀌어도 상관없다. 즉, 이 참조자는 태생적으로 const 속성과는 어울리지 않는다. 오히려 const-ness가 보장되지 않아도 되는 제한적인 문맥에서, 쓸데없는 복사를 할 필요 없이 꼼수를 좀 더 합법적으로 구사할 수 있게 위해 이런 문법이 추가되었다고 보는 게 타당하다.

마지막으로 R-value 참조자가 유용하게 쓰이는 용도를 딱 하나만 더 소개하고 글을 맺겠다.
윈도우 API+MFC 기준으로, RECT 구조체를 받아서 이 값을 적당히 변형한 뒤에 이를 토대로 후처리를 하는 함수를 생각해 보자.

void Foo(const RECT& rc)
{
    RECT rc2 = rc; //rc는 const이기 때문에 복사본을 만들어야 함

    ::OffsetRect(&rc2, x,y); //변형
    ::DrawText(hDC, strMsg, -1, &rc2, 0);
}

void Foo(RECT&& rc)
{
    ::OffsetRect(&rc, x,y); //복사본 만들 필요 없이 rc를 곧바로 고쳐서 사용하면 됨
    ::DrawText(hDC, strMsg, -1, &rc, 0);
}

CRect r(100, 200, 400, 350);
Foo(r); //const RECT& 버전이 호출됨
Foo( CRect(0,0, 400,300) ); //임시 개체임. RECT&& 버전이 호출됨

RECT를 value로 전달했다면 당연히 복사가 일어나고, const reference로 전달했다면 역시 복사가 행해져야 한다. 그러나 애초에 함수에 전달되는 인자가 임시 개체였다면, 임시 개체에 대한 복사본을 또 만들 필요 없이 그냥 그 임시 개체를 바로 고쳐 쓰면 된다. 위의 코드의 의미가 이해가 되시겠는가?

R-value 참조자라는 게 왜 필요한지, 그리고 이게 왜 이동 생성/대입과 관계가 있는지 본인은 이해하는 데 굉장히 긴 시간이 걸렸다. 인터넷에 올라와 있는 다른 설명만 읽어서는 도통 이해가 되지 않아서 직접 코드를 돌리고 컴파일을 해 본 뒤에야 개념을 깨우쳤는데, 알고 나니 정말 이런 걸 생각해 낸 사람들은 천재라는 생각이 든다.;; C++은 참으로 복잡미묘한 언어이다.

Posted by 사무엘

Windows라는 PC용 운영체제는 1985년에 처음 나온 이래로 많은 변화를 겪었다.

1.0 시절에 윈도우는 잘 알다시피 독자적인 실행 파일 포맷을 갖고 있긴 했지만, 완전한 운영체제가 아니라 16비트 도스 위에서 추가로 구동되는 액세서리 멀티태스킹 환경에 불과했다. 또 개발 언어가 의외로 C가 아닌 파스칼이었기 때문에, 실행 파일 내부의 각종 export/import 심볼을 보면 대소문자 구분이 없이 다 대문자였고, 문자열도 null-terminated 형태가 아니라 글자수가 앞에 찍힌 형태로 저장되어 있었다.

상업적으로 최초로 대성공을 거둔 윈도우 3.0때부터(혹은 2.x때?) C언어 형태 기반으로 API가 재정비되었으나, 이런 파스칼의 흔적은 실행 파일 포맷이라든가 함수 호출 규약 같은 데에 여전히 일부 남아 있었다. API에 하위 호환성도 잘 지켜진 편이기 때문에 1.x~2.x용 실행 파일도 내부의 리소스 데이터의 구조만 살짝 고쳐 주면 3.x에서 바로 실행 가능할 정도였다.

그랬는데 1993년에 윈도우 NT가 개발되면서 프로그램의 내부 구조가 크게 바뀌었다. 16비트에서 32비트 환경으로 갈아탔으며, 멀티스레딩+선점형 멀티태스킹이라는 게 도입되었다. 이때 실행 파일의 포맷도 NE에서 PE 방식으로 바뀌었고, 이 전통이 오늘날까지 그대로 이어져 내려오고 있다.

마이크로소프트는 동일 코드를 거의 고치지 않아고도 재컴파일만으로 16비트 바이너리와 32비트 바이너리를 동시에 만들 수 있게 많은 배려를 했다. 특히 운영체제의 API 함수는 int 크기가 4바이트가 된 것 같은 불가피한 변화를 빼면 프로토타입이 거의 바뀌지 않았다.
그럼에도 불구하고 불가피하게 프로토타입이 크게 바뀐 함수가 의외로 GDI 계층에 많이 있다. MoveToEx 함수가 그 예이다.

16비트 윈도우 시절에 이 함수는

long MoveTo(HDC, int x, int y);

처럼 정의되어 있었다. 주어진 DC가 내부적으로 기억하고 있는 그리기 기준 위치를 x, y로 옮기고, 예전의 기준 위치를 리턴값으로 돌려줬다. 그때는 좌표계의 범위가 16비트이기 때문에, 두 개의 16비트 수치를 32비트 long 정수로 합산해서 표현하는 게 괜찮은 방법이었다.

그러나 이 디자인은 32비트 환경에서는 바뀌는 게 불가피해졌다. int 개개의 값이 32비트로 커졌고 32비트 윈도우는 32비트 좌표계를 지원하기 때문이다. 16비트 숫자야 범위가 너무 좁기 때문에 16비트 컴퓨터 시절에도 느리게나마 32비트 정수를 다루는 long 같은 타입이 있었지만, 32비트 둘을 합친 64비트 정수는, 언어 차원에서 표준으로 지정된 타입이 그 당시에 없었다.

그래서 32비트 환경에서는 예전의 기준 위치를 POINT라는 별도의 구조체의 포인터에다가 되돌리는 형태로 동작 방식이 바뀌어야 했고, MoveToEx라는 함수가 추가되었다.

BOOL MoveToEx(HDC, int x, int y, POINT *pPoint);

윈도우 API에 어떤 함수의 Ex 버전이 추가되더라도 MS는 어지간하면 옛날 버전 함수도 남겨 두는 편인데, MoveTo만큼은 그렇게 하지 않았다. 원래 있던 함수는 삭제되고 새로운 함수로 대체되었기 때문에, 16비트 코드를 포팅하는 사람은 이 함수의 호출 부분을 수동으로 리팩터링을 하지 않을 수 없게 되었다. 좌표계가 어차피 16비트 범위를 넘을 일이 절대 없다는 보장이 있고 기존 16비트 코드를 빠르게 포팅해야 하는 사람이라면, 그냥 이런 wrapper 함수를 자체적으로 만들 필요가 있을 것이다.

long MoveTo(HDC hDC, int x, int y)
{
    POINT pt;
    MoveToEx(hDC, x, y, &pt);
    return MAKELONG(pt.x, pt.y);
}

오리지널 버전을 왜 살려 두지 않았냐 하면, 저런 식으로 확장해야 하는 함수가 한두 개가 아니기 때문에, 오리지널 버전을 다 살려 뒀다간 윈도우 API가 심하게 너무 지저분해지기 때문이다.

GetViewportExtEx, GetWindowExtEx, GetViewportOrgEx, GetWindowOrgEx와 이들의 Set 버전들. 오늘날의 윈도우 API에 Ex 버전만 존재하고 오리지널은 남아 있지 않은 이유가 동일하다. 16비트 시절에는 간단하게 x, y좌표를 32비트 long으로 합쳐서 되돌리던 함수였는데 그것이 32비트 윈도우에서부터는 POINT나 SIZE 구조체를 통해서 결과값을 받도록 바뀌었다.

사실, GDI라는 게 화면 픽셀만을 취급한다면 좌표계가 16비트 범위만으로도 아주 충분할 것이다. 오늘날도 화면 해상도는 끽해야 1000~2000대를 벗어나지 않기 때문이다. 그러나 GDI는 화면뿐만 아니라 프린터도 다루고, 픽셀뿐만 아니라 장치 독립적인 더욱 정밀한 단위도 취급하기 때문에 궁극적으로는 좌표계의 크기를 32비트로 확장할 필요가 있었다.

다만, 과거의 윈도우 9x는 GDI와 USER 계층의 상당수가 16비트 코드를 그대로 답습하고 있었기 때문에, API는 저렇게 32비트 형태여도 내부적으로 여전히 16비트 좌표계의 한계를 지니고 있긴 했다. 그러니 실수로 32767을 넘어가는 40000쯤 되는 좌표로 선을 그으라고 하면, 숫자가 음수로 바뀌어 인식되어 선이 오른쪽 끝이 아닌 왼쪽 끝으로 가게 되었다. 이런 보정은 응용 프로그램이 알아서 해 줘야 했다. 암울했던 시절이다.

이런 점에서 윈도우 API를 커버하는 계층인 MFC가 편한 구석이 있다. 16비트 시절이나 32비트 시절이나 CDC 클래스의 멤버 함수의 프로토타입은 CPoint MoveTo(int x, int y)로 동일하다. POINT 자료구조를 생으로 함수값으로 되돌리게 한 것은 오버헤드가 따르지만, 그냥 이식성과 개발 편의에다 더 비중을 두고 클래스를 설계한 셈이다.

그럼, 세월이 흘러 32비트에서 64비트로 넘어가는 과정에서 생긴 큰 변화는 무엇일까?
뭐니뭐니해도 GetWindowLong 함수를 예로 들 수 있다. Set 버전도 포함.
얘는 원래 주어진 윈도우에 대해서 스타일, ID, 윈도우 프로시저 주소 등 다양한 수치 정보를 얻어 오는 일종의 다형적인(polymorphic) 함수이다. 리턴값이 일반 숫자일 수도 있고 포인터나 핸들일 수도 있다.

32비트 시절에는 컴퓨터가 표현하는 숫자의 크기는 32비트로 사실상 획일화되어 있었기 때문에, 문제될 게 없었다. int나 long을 바로 포인터로 typecast하거나 그 반대로 해도 정보가 손실될 일이 없었다.
그러나 64비트에서는 이것이 큰 문제로 작용하게 되었다. 윈도우 운영체제는 int와 long은 호환성 차원에서 32비트로 그대로 유지하고,포인터와 핸들만 64비트로 키우는 정책을 선택했기 때문이다.

그래서 개발자의 편의를 위해 비주얼 닷넷쯤의 플랫폼 SDK에서는 잘 알다시피 INT_PTR처럼 _PTR이라는 자료형 typedef가 추가되었다. 포인터의 크기와 같은 정수형이라는 보장이 있는 정수형을 따로 구분해서 표현하기 위해서이다. 윈도우 API도 원래는 GetWindowLong 하나만 있었는데 GetWindowLongPtr이라는 명칭이 추가되었다. 이것이 32비트 환경에서는 그냥 GetWindowLong로 도로 치환되는 매크로에 불과하지만, 64비트에서는 Ptr 버전만이 운영체제의 user32.dll에 실제로 존재하는 함수이다.

다시 말해, 32비트에서는 기존 Long과 새로운 LongPtr 버전을 둘 다 쓸 수 있고 LongPtr이 내부적으로는 Long으로 도로 바뀌어 처리되는 반면, 64비트에서는 LongPtr만 써야 하고 Long을 쓰면 에러가 난다.

이 함수가 받는 매개변수도 32비트 범위로 충분한 GWL_STYLE, GWL_ID 같은 상수는 바뀐 게 없는데, 포인터와 크기가 같은 윈도우 프로시저나 인스턴스 핸들 같은 걸 지정할 때는 GWL_*말고 GWLP_*라는 명칭이 새로 추가되었다. 둘은 의미하는 값도 차이가 없는데 왜 이런 조치를 취한 것일까?

이는 단순히 프로그래머의 편의를 위해서이다.

int n = (int)GetWindowLong(hWnd, GWL_WNDPROC);

64비트에 환경에서는 윈도우 프로시저의 크기 (8바이트)가 int의 크기(4바이트)보다 더 크기 때문에, 이런 식으로 32비트 관행을 전제를 하고 작성된 코드는 64비트 환경에서 아예 컴파일이 되지 않게 하기 위해서이다.

INT_PTR n = (INT_PTR)GetWindowLongPtr(hWnd, GWLP_WNDPROC);

이렇게 짜 주면 32비트와 64비트에서 모두 안전하게 잘 동작하는 코드가 된다.

memory mapped file을 만드는 CreateFileMapping이나 MapViewOfFile 함수는 메모리의 크기를 64비트 범위로 잡을 수 있어서 그 값을 32비트 기계에서 처리하기 편하게끔 두 개의 32비트 숫자로 쪼개서 받아들인다. 64비트 윈도우에서는 굳이 그렇게 할 필요가 없지만 함수의 프로토타입이 바뀌지 않았다. 어차피 64비트 윈도우라고 해서 당장 4GB를 능가하는 어마어마한 양의 메모리를 한 번에 잡는 일은 실제로 거의 없기 때문이다.

GlobalAlloc, VirtualAlloc, HeapAlloc 같은 메모리 할당 함수들은 메모리의 양을 잡는 숫자의 자료형이 SIZE_T이다. 즉, 32비트 환경에서는 32비트, 64비트 환경에서는 64비트로 결정된다는 뜻. SIZE_T는 UINT_PTR과 의미상 사실상 동급인 셈이다.
하지만 파일을 읽고 쓰는 ReadFile와 WriteFile은 정보를 전송하는 단위가 SIZE_T도 아니고 그냥 DWORD(32비트)로 고정되어 있다.

다만, 32비트 환경에서라도 32비트 크기의 범위를 능가하는 방대한 파일을 취급해야 할 일이 있기 때문에 파일의 크기를 얻거나(GetFileSize), 파일의 특정 지점을 탐색하는(SetFilePointer) 함수는 역시 32비트 필드를 두 개 받아서 64비트 숫자를 전달할 수 있게 되어 있다. 윈도우 2000부터는 숫자를 32비트 단위로 쪼갤 필요 없이 64비트 숫자를 한 번에 전달받는 Ex 함수가 운영체제 차원에서 추가되었다.

MFC는 운영체제에 그런 Ex 함수가 추가되기 전부터 CFile::Seek나 CFile::GetLength는 언제나 64비트 정수를 다뤄 왔으니 속 편한 경우라 하겠다.

GlobalMemoryStatus 함수는 현재 컴퓨터의 전체 메모리 양과 남은 메모리 양을 되돌리는 함수인데, 램 용량이 4GB를 넘어서는 날이 올 거라고 과거에 상상이 가능했을까. 구조체의 각 멤버가 32비트 크기로 고정되어 있다가 이것이 64비트로 확장된 Ex 함수가 역시 윈도우 2000 때부터 추가되었다. 64비트 운영체제에서는 오리지널 함수를 없애 버려도 될 법도 해 보이는데 이건 오리지널과 Ex가 여전히 남아 있다.

16비트 시절에는 윈도우 메시지와 함께 전달된 두 개의 부가 정보 중 WPARAM은 16비트이고 LPARAM은 32비트 크기였다. 그러던 것이 32비트 환경에서는 둘 다 32비트가 되었다. 16비트와 같은 사고방식이라면 64비트 환경에서는 WPARAM은 32비트이고 LPARAM만 64비트로 승격해도 될 것 같으나 그렇지 않다. 둘 다 64비트이다.

machine word보다 더 작은 크기로 정보를 제한해서 담을 필요가 전혀 없을 뿐더러, 이미 32비트 시절에 WPARAM과 LPARAM을 구분하지 않고 포인터와 핸들을 담는 관행이 10년 넘게 지속되었을 텐데 다시 그 구분을 넣는다는 건 불가능한 지경이 되었기 때문이다.

한 플랫폼에서만 10년 넘게 프로그래밍을 하니까 이제는 그 API를 처음에 설계한 사람의 마음을 읽고 시대에 따른 변천사를 이해하는 경지에 도달하는 걸 느낀다. ^^

Posted by 사무엘

잘 알다시피 <날개셋> 한글 입력기는 Windows용 한글 IME이다(IME이기만 한 건 아니지만). 이 분야는 경쟁 프로그램이 거의 없다시피하기 때문에, MS가 직접 공급하는 IME를 제외하면 3rd party 한글 IME 중에서는 <날개셋> 한글 입력기가 가히 독주를 하는 중이다. 그 이유로는,

첫째, 모바일용도 아니고 PC용으로는 한글 입력 방식이 딱히 더 만들 게 없다고 여겨지고 있어서인 것 같다. 그리고 딱히 돈이 되는 것도 아니니까 말이다. 싸제 IME가 활발히 쓰이고 있는 중국어· 일본어 IME의 개발 환경과 비교했을 때 이것이 크게 다른 점이다.

그리고 둘째로는, 윈도우용 IME라는 게 여타 운영체제의 IME와 비교해 보더라도 그 아키텍처와 스펙이 미치도록 폐쇄적이기 때문이다. 비록 프로토콜이 공개돼 있는 건 있지만, 그것만 참고해서는 쌩쌩 잘 돌아가는 한글 IME를 절대로 만들 수 없다. 문서화되지 않은 무수히 많은 상황에 대한 대비를 해야 되는데 이걸 이제 와서 혼자 처음부터 만든다는 건 불가능에 가깝다.

그럼에도 불구하고 <날개셋> 한글 입력기 말고 ‘싸제’ 한글 IME가 전혀 없는 건 아니다. 본인은 MS가 개발하지 않은 한글 IME를 최소한 두 종류를 더 알고 있다.

※ 새나루

윈도우 DDK에 등재되어 있는 FakeIME라는 일본어 예제 IME를 고쳐서 만들어진 한글 IME이다. 오픈소스 진영에서 만들어진 프로그램답게 소스 공개이다. 개발자들은 본인처럼 아예 대놓고 국어 정보학 쪽으로만 발을 들인 것도 아닌데 이쪽으로 조예가 굉장히 깊은 고수 프로그래머이다.

싸제 IME답게 여러 실험적인 기능이 많아서 실속이 있으며, 그러면서도 <날개셋>보다 덩치 작고 가볍다는 이점이 있다. 특히 <날개셋>이 개발 방향의 특성상 의도적으로 더 지원하지 않는 다음 기능들 때문에 새나루를 선호하는 사람도 있다.

키보드 드라이버 차원에서 드보락 글자판과의 연동: 쉽게 말해, 단축키까지 드보락 식으로 나오면서 그 상태에서 한글 입력까지 지원.

글자가 아니라 단어 전체를 조합으로 잡아서 단어 단위로 한자 치환: 일부 한자 혼용론자가 무척 좋아하는 기능이라 한다. MS IME로는 이 기능은 TSF A급 프로그램에서만 가능하며, <날개셋> 한글 입력기 역시 훗날 이 기능을 추가한다 하더라도 MS IME처럼 TSF A급에서만 지원할 것이다.

이 외에도 잘은 모르겠지만, 안 마태 키보드 드라이버도 입력 스키마를 살짝 변조한 수준에 머물러 있는 <날개셋>보다 새나루가 좀 더 지원을 잘 하는 게 있는 듯하다.

다만, 새나루의 개발자는 <날개셋>의 개발자처럼 한글 입력기 하나에만 완전 목숨을 건 타입은 아니다 보니, 프로그램의 유지· 보수와 버전업이 <날개셋>만치 애착을 갖고 꼬박꼬박 되고 있는 건 아니어 보인다. 하긴, 무료 소프트웨어가 이 정도라도 개발되어 온 게 감지덕지지.

※ Unicode CJK IME

이건 아는 분이 얼마 없지 싶다. 이건 무려 남북 합작으로 개발된 프로그램이다. 주 개발은 북한의 평양 정보 센터(PIC)에서 했으며, 남한의 한국 과학 기술 정보 연구원과 고려 대학교 민족 문화 연구원은 프로그램을 설계하고 각종 한자 데이터베이스를 구축했다. PIC는 서체도 만들고 ‘단군’이라는 워드 프로세서도 개발한 적이 있을 정도로 문자 처리 쪽에 기술이 상당한 수준이다. 그러니 IME도 만들었다.

세벌식은 전혀 지원하지 않지만, 남북 합작 IME 답게 북한 두벌식을 지원한다. 그리고 한양 PUA 방식의 옛한글을 지원하며, 문자표, 부수로 한자 입력, 자체 한자 사전 등의 기능을 내장하고 있다.

제목에서 알 수 있듯, 이 제품은 한글 IME뿐만이 아니라, 동일한 UI 엔진 기반으로 개발된 중국어· 일본어 IME와 한 세트를 구성하고 있다. 북한에서 그런 것까지 만들었다. 하지만 이들 IME의 성능(사전 크기 및 어절 분할 정확도)은 본인이 판단하기에 운영체제가 기본 제공하는 중국· 일본어 MS IME보다 못하다.

이런 프로그램들과는 달리, <날개셋> 한글 입력기는 처음에는 전용 에디터로만 개발되고 있었다. 2.x 시절까지만 해도 본인은 내가 스스로 한글 IME를 만들 수 있을 거라고 생각도 못 하던 처지였다. 그랬는데 2003년은 참으로 드라마틱하게도 한글 IME 개발의 원년으로 등극하게 되었다.

새나루는 2003년 말에 첫 버전이 나왔다. 그리고 본인이 접한 Unicode CJK IME 역시 2003년 6월자 버전이었다(다만, 그 후로 유지 보수는 중단된 듯). 그리고 그 해 가을에 출시된 MS 오피스 2003은 한자 변환 기능이 크게 강화되어 단어 단위 한자 변환이 처음으로 도입된 버전이었다. 이게 다 우연인 걸까?

이런 일련의 사건을 계기로 본인은 운영체제의 IME 스펙을 처음으로 공부하기 시작했으며, <날개셋> 한글 입력기를 운영체제의 IME로 거듭나게 하려는 연구를 난생 처음으로 시작했다. 마침 2003년 하반기이면 <날개셋> 한글 입력기 역시 3.0이 개발 중이었고, 입력기의 내부 구조를 싹 뒤집어 엎고 있었다. 나의 대학 3학년 시절, 이때가 <날개셋> 한글 입력기의 미래를 결정하는 개발이 이뤄지던 시절이었으니, 흥미롭지 않을 수 없다.

그래서 <날개셋> 한글 입력기에 좀 이렇다 할 외부 모듈이 난생 처음으로 탑재된 건, 2004년 9월에 나온 3.02 버전이다. 한글 입력기를 표방하면서 정작 윈도우용 IME가 나온 것은 새나루나 남북 합작 IME보다 시기적으로 늦다.

첫 버전은 당연히 정말 불안정했고 볼품없는 퀄리티였다. 아직 운영체제의 IME 시스템의 내부 구조를 제대로 이해 못 한 상태에서 최소한의 글자 찍기만 가능하던 상태였다. 이 때문에 직후 버전인 3.1에서 당장 무더기 버그 패치가 이뤄졌으며, 그 후로 외부 모듈이 큰 안정화 단계를 마치기까지는 1년이 넘는 시간이 더 필요했다.

그러나 첫 진입 단계에서 이런 시행착오를 충분히 겪은 뒤엔, 워낙 탄탄한 자체 한글 입력 시스템을 갖추고 있던 <날개셋> 한글 입력기가 완성도 높은 윈도우용 IME로 완전히 자리잡게 되었다. TSF 인터페이스를 이용해 bksp 달라붙기 같은 <날개셋> 고유 기능까지 그럭저럭 재연해 냈고, 심지어 윈도우 95부터 오늘날의 7까지 모든 운영체제를 지원하는 최적화까지 덤으로 구현했기 때문이다.

<날개셋> 한글 입력기는 이런 내력을 거쳐 지금과 같은 모듈들이 잘 개발되었다. 하지만 IME(외부 모듈)이 첫 개발되던 그 시절을 본인은 지금도 잊을 수 없으며, IME 모듈의 개발에 영향을 끼친 위의 두 프로그램들에도 나름 애착을 갖고 있다.

Posted by 사무엘

한 달쯤 전에 비주얼 베이직 리뷰를 쓴데 이어 오늘은 델파이와 해당 계열 RAD 툴의 리뷰를 좀 써 보겠다.
비주얼 베이직뿐만이 아니라 델파이와 C++ 빌더(C++ Builder)는 본인이 지금 같은 골수 비주얼 C++ 유저가 되기 전에, 도스에서 윈도우 프로그래밍으로 넘어가던 과도기 시절에 잠깐 써 본 개발툴이다. 고등학교 시절의 추억이 담겨 있다.

일단 파스칼이라는 언어 자체가 본인이 베이직에서 C/C++로 넘어가기 전에 과도기적으로 잠깐 공부했던 언어이다. 당시 정보 올림피아드 공부용으로 파스칼이 아주 깔끔하고 좋다는 말이 있기도 했고 말이다. 이 언어는 정말로 베이직과 C 사이의 과도기 역할을 하면서 본인의 프로그래밍 패러다임의 전환에 굉장한 도움을 주었다.

도스용 볼랜드 파스칼 역시 상당히 잘 만든 개발툴이었다. 그래서 본인은 이걸로 뭔가 이렇다할 프로그램을 개발해 보지 못한 게 좀 아쉽다. 개발툴의 본좌(?)이던 마이크로소프트와 볼랜드는 둘 모두 도스에서는 16비트의 한계를 벗어나질 못했으니 말이다. 그리고 지금 역시 <날개셋> 한글 입력기처럼 극도의 최적화를 추구해야 하는 프로그램은, 비주얼 C++만치 더 적격인 툴이 없는 것도 어쩔 수 없는 현실이다.

1990년대 초중반에 마이크로소프트가 '비주얼' 브랜드로 새로운 개발툴을 내놓은 것처럼 볼랜드는 오브젝트 파스칼 기반의 완전히 새로운 RAD 툴을 내놓았다. 그것이 바로 델파이. 게다가 1995년에 첫 출시된 1.0은 전무후무하게 16비트 윈도우용이었다.

델파이는 원래 AppBuilder라는 제품명이 붙을 예정이었고 Delphi는 코드명일 뿐이었다. 내 기억이 맞다면 이에 대해서 재미있는 일화가 전해진다.
잘 알다시피 IT계엔 그 이름도 유명한 Oracle이라는 데이터베이스 엔진(DBMS)가 있다. 이거 참 센스 있는 작명인게, DB에다가 SQL을 때려서 쿼리가 수행되는 것을 마치 신탁을 내리는 것에다 비유한 것이다. “수천만 개의 레코드 중에서 요것과 연계하여 이런 조건을 만족하는 놈을 눈앞에 0.1초 안에 대령하라.” 검색 엔진에다 심마니라는 이름을 붙인 것과 비슷한 맥락의 작명이라 하겠다.

그런데 신탁이 내려지는 곳이 어디던가? 신전이다. 그리고 고대 그리스에는 델파이라는 도시에 아폴로 신전이 있었다.
델파이는 DB와 연동하는 업무용 프로그램을 파스칼 언어를 기반으로 빠르고 편리하게 개발해 내라고 만들어진 개발툴이다. 그래서 DB 쿼리라는 신탁이 내려지는 장소에다 빗대어 델파이라는 코드명이 정해졌고, 이게 곧 제품명이 되었다. (뭐, 굳이 DB를 안 쓰더라도 각종 유틸리티나 에디터, 툴을 만드는 용도로도 좋지만 말이다.)

이런 이유로 인해, 델파이는 지금까지도 신전이나 집 비슷한 모양을 한 아이콘을 갖고 있다. 델파이의 C++ 버전이고 델파이보다는 훨씬 덜 유명한 C++ Builder는 집+크레인처럼 생긴 건축 기계 모양 아이콘이다. C++ 빌더는 다른 건 델파이와 비슷한데 역시 C++의 특성상 빌드 속도는 훨씬 더 느리며, RAD 툴의 용도에 맞게 C++ 문법을 자기 식대로 확장한 게 좀 있다. 또한 C++답게 경쟁사의 MFC 라이브러리도 내장하고는 있다.

그런 곳에서는 C++의 위상이 좀 므흣한 게, 닷넷으로 치면 마치 C++ managed extension 같은 존재이다. 닷넷에서는 아예 확실하게 C#을 쓰고 필요한 곳에나 unsafe 코드를 가끔씩 집어넣고 말지, 네이티브 기계어 개발이 아니라면야 C++이 얼마나 메리트가 있겠나 싶다. C/C++을 쓸 정도이면 아예 Win32 API만을 이용한 하드코어 저수준 개발을 하지, 애초에 RAD용으로 만들어진 게 아닌 언어에다가 그 정도로 추상화 계층을 거친 RAD 껍데기를 거추장스럽게 씌울 필요가 있겠나 하는 생각이다.

볼랜드에서는 자기네 RAD 툴에다가도 닷넷 기술을 연동하여 C# Builder 같은 툴을 만들기도 했지만 이건 얼마 못 가 접었다. 다들 비주얼 C#을 쓰지 굳이 볼랜드 툴을 쓰지 않았기 때문. 볼랜드는 그런 자신의 RAD 영역을 더욱 발전시켜서 마치 qt 같은 크로스 플랫폼 개발 프레임워크를 표방하며 리눅스용으로 카일릭스(Kylix)도 내놓고, 지금은 맥 OS X 범용 개발 환경도 내놓았는데, 아이디어는 분명 좋다만 결과는 과연 어떨까 궁금하다. 카일릭스는 수 년 전에 망했고 개발이 중단됐다.

하긴, 말이 나왔으니 말인데 얘들은 개발사의 명칭이나 주체가 여러 번 바뀌었다(개명· 인수 합병). 볼랜드이다가 한때는 Inprise, Codegear를 거쳐 지금은 Embarcadero임.

이런 저런 사정이 많았으나 델파이는 결국 오늘날까지도 그냥 윈도우 플랫폼 한정으로 강세인 것으로 보인다. 나름 네이티브 코드(오옷!)를 가히 C++로는 엄두를 못 낼 전광석화의 속도로 생성하는 RAD 툴이니, 생산성은 확실히 우위이다. 프레임웍에 속하는 코드가 단일 exe에 모조리 static 링크되어 들어가기 때문에, Hello world 급의 프로그램도 Release 빌드의 exe는 1MB 이상은 먹고 들어간다.

비주얼 C++ 2008 이상부터는 MFC를 static link해도 그 정도는 먹고 시작한다. 과거의 6.0 시절에는 MFC의 static link 오버헤드 크기가 200~300KB대였는데, 재미있게도 그 당시의 델파이 2~3도 exe의 기본 크기가 그 정도였으니 옛날이나 지금이나 오버헤드가 서로 비슷하다.

이런 이유로 인해, 델파이로 개발된 프로그램은 실행 파일을 실행 파일 압축기로 압축한 채 배포되는 경우가 종종 있다. 하지만 압축된 실행 파일은 코드 실행 영역이 동적으로 생성되고 고쳐지기 때문에, 동일 EXE가 중복 실행되었을 때 코드 영역이 동일한 물리 메모리를 공유하여 메모리를 절약하는 효과를 못 보지 싶다. 실행 파일 압축기가 집어넣어 준 압축 해제 stub이 그런 걸 똑똑하게 감지하여 처리하지 않는다면 말이다. 뭐, 요즘은 어차피 메모리도 차고 넘치는 시대이긴 하지만...;;

내 기억이 맞다면, C++ Builder는 델파이와는 달리 수 MB짜리 vcl.dll (Visual Component Library) 런타임이 필요한 작은 exe를 생성했었지 싶다. 즉, 정적 링크가 아니라 동적 링크 방식.

그런데 얘들의 프레임웍 라이브러리는 덩치만 큰 게 아니라 윈도우 API를 나름 체계적으로 잘 커버하고 있다. MFC는 윈도우 API에다 아주 최소한의 껍데기만 씌운 것에 가까운 반면, 볼랜드의 라이브러리는 운영체제 API에는 존재하지 않는 여러 추상적인 계층을 더 만들고, 심지어 같은 에디트 컨트롤도 single line (TEdit)과 multi line (TMemo) 버전을 따로 만들었다. MFC는 그냥 CEdit 하나로 끝인데 말이다. 내부 구현이 옵션만 다르게 지정된 동일한 에디트 컨트롤이니까 말이다.

라디오 버튼이나 체크 버튼도 under the hood는 그냥 버튼 컨트롤일 뿐이기 때문에 MFC는 CButton 하나로 끝이다. 그러나 볼랜드의 라이브러리는 응당 TRadioButton과 TCheckBox로 클래스가 따로 나뉘어 있다.
볼랜드의 프레임워크는 DC고 GDI 객체고 나발이고 생각할 것 없이 자기네가 마련한 TCanvas라는 개체를 통해 마음대로 색깔을 바꾸고 픽셀 단위 그래픽 접근이 가능한 반면, MFC에서는 그런 자비를 찾아볼 수 없다. 그런 추상화 계층을 마련하는 오버헤드가 exe의 실행 파일 크기 내지 런타임 DLL로 나타난다고 생각하면 됨.

이런 전통이 사실 볼랜드의 옛 C++ 라이브러리인 OWL (Object Windows Library)부터 어느 정도 전해져 오고 있었다. 델파이가 나오기 전, 볼랜드 C++/파스칼이 윈도우용으로 있던 시절 얘기이다. OWL이 좀 더 객체 지향 철학을 살려서 더 잘 만들어진 라이브러리이긴 했으나, 언제부턴가 IE가 넷스케이프를 누르듯이 MFC가 OWL을 떡실신시켜 버렸다.

세월이 세월이다 보니 델파이도 도움말 레퍼런스는 MS 비주얼 스튜디오의 Document Explorer를 쓰고 있어서 뜻밖이라는 생각이 들었다. 하긴, 옛날 버전은 아예 WinHelp를 쓰고 있었는데, 자기네만의 도움말 시스템을 새로 만드는 건 너무 뻘짓이고 그냥 chm을 쓰기엔 레퍼런스의 분량이 너무 방대한데, 저렇게 하는 게 나은 선택이다.

델파이의 근간 언어인 파스칼은 내부적으로 문자열을 포함하는 방식이 원래 C/C++과는 다르다. 그러나 운영체제의 각종 API들이 오로지 C/C++ 스타일의 null-terminated 문자열만을 취급하기 때문에 델파이 프로그래머도 C/C++ 스타일 문자열이라는 개념을 몰라서는 안 된다. 사실 파스칼과 C/C++은 함수 호출 규약조차도 달라서 과거에는 C/C++에서도 함수 선언할 때 STDCALL뿐만이 아니라 PASCAL이라는 속성이 있을 정도였다.

파스칼에도 포인터가 있긴 하다. 하지만 C/C++만치 배열과 포인터를 아무 구분 없이 남발할 수 있는 건 아니며 쓰임이 제한적이다. a[2]뿐만이 아니라 2[a]까지 가능한 건 가히 C/C++의 변태적인 특성이다만, 파스칼은 등장 초기에는 동적 배열이라는 개념 자체가 아예 없었다고 한다.
타입 선언에서 포인터를 의미하고 실제 수식에서는 포인터가 가리키는 값을 얻어오는 연산자가 C/C++은 *인데 파스칼은 ^이다.
그리고 이미 있는 변수의 주소를 얻어 오는 address-of 연산자는 C/C++은 &이고, 파스칼은 @이다.

델파이로 개발된 프로그램은 윈도우 비스타/7의 Aero 환경에서 창을 최소화해 보면 창이 작업 표시줄 쪽으로 미끄러지듯 fade out이 되지 않고 그냥 혼자 싹 없어지곤 했다. 나타나는 비주얼이 살짝 다르다. 델파이로 빌드된 다른 프로그램들을(특히 구버전) 살펴보면 차이를 알 수 있다.

그랬는데 최신 2011년도 델파이 XE2로 프로그램을 하나 빌드해 보니까 드디어 여타 프로그램처럼 제대로 최소화된다. 개선이 된 듯하다.
델파이가 유니코드와 64비트를 제대로 지원하기 시작한 것도 생각보다 최근이라고 들었다만.. 앞으로 이 툴이 어디까지 발전하고 MS의 비주얼 툴과는 다른 독자적인 지위를 유지할 수 있을지가 지켜보는 건 흥미로운 일일 것이다.

* 2014년 7월 1일 추가함.
델파이 1.0은 특정 업종 종사자들만 사용하는 딱딱한 개발툴인 주제에 무슨 게임을 방불케 하는 화려한 설치 화면을 자랑했다.

설치 프로그램이 full screen 모양으로 실행되는 게 유행이던 시절의 즐거운 추억이다. 본인도 중학생이던 시절 저 화면을 직접 본 적이 있다. 정말 개발툴 역사상 전무후무한 디자인이 아닐까 싶다.

속도계는 어떤 축적된 분량이 아니라 단위 시간당 변화량 개념이기 때문에,
굳이 이런 프로그램에 넣더라도 차라리 지금 파일의 전송 속도를 나타내는 용도가 더 적절할 것 같다만..;;
어쨌든 저 계기판에서 속도계가 전체 설치 진행 상황을 나타낸다.

굉장한 창의력과 잉여력이 아닐 수 없다. 그때는 MS Office 9x 프로그램에도 간단한 핀볼이나 3D 레이싱 게임이 이스터 에그로 들어가 있었을 정도이니 뭐...
단, 델파이의 경우 설치 중에 저 배경에서 차가 실제로 주행하여 배경이 입체적으로 스크롤된다거나 하지는 않는다. ^^ 그건 일말의 아쉬운 점이다.

Posted by 사무엘

살다 보니 C#이나 파이썬도 아니고 비주얼 베이직으로 작성된 코드를 C++로 포팅해야 할 일이 있었다. C/C++로 갈아탄 뒤로는 베이직 코드는 다시는 볼 일이 없을 줄 알았는데 이거 정말 몇 년 만이냐.

들여다봐야 하는 코드는 닷넷도 아니고 비주얼 베이직 6으로 만들어진 코드였다. 하지만 GUI가 아니라 계산 알고리즘을 포팅하는 것이기 때문에 포팅이 크게 어려운 건 없었다. VB6에서 닷넷으로 넘어가면서 완전히 뒤집어엎어진 건 API 체계이지, 언어 자체가 그렇게 많이 바뀐 건 우려한 것만치 많지 않아 다행이었다. 자바와 자바스크립트의 관계에 필적하는 이질감은 아닌 것 같다.

언어가 바뀐 것은,
- 첫째, statement이던 것이 C 언어의 영향을 받아 다 일관된 함수 호출 형태로 바뀜. 그래서 매개변수 전체를 괄호로 싸야 됨. (파이썬도 3.0에서는 print가 statement에서 함수로 바뀜)

- 둘째, 타입이 예전보다 더 엄격해지고, 모든 변수는 반드시 사용 전에 선언을 해 줘야 함. 베이직은 원래 그런 걸 안 하는 언어이다가 하는 걸로 바뀌었다 보니, 변수를 선언하는 키워드가 Var이 아니라 Dim...이다. 원래는 배열을 선언할 때만 쓰는 키워드였지.
이런 추세를 정면으로 역행하는 GWBASIC의 잔재인 DefINT A-Z 같은 명령문은 당연히 퇴출이다.

- 셋째, 그리고 객체지향 패러다임에 맞춘 API의 전면 재구성이다. 예전엔 그냥 global 단위로 곧바로 호출하던 함수도 다 분야가 나뉘어서 클래스나 namespace에 소속된 메소드로 바뀌었다. 그래서 수학 함수도 바로 Sqrt라고 하면 안 되고 Math.Sqrt라고 써 줘야 하며, Math를 자주 쓴다면 Using 선언을 한 뒤에 생략해야 한다. 하긴, 비베에는 예전부터 With 키워드는 있긴 했다만.

이 정도.
요즘 언어들은 C/C++ 영향을 받아서 다들 대소문자 구분을 하는 게 유행이기 때문에, 혹시 비주얼 베이직도 그렇게 바뀌지 않았으려나 생각했다만...
의외로 명칭에 대소문자 구분을 안 하는 건 VB6이나 닷넷이나 마찬가지이다.

베이직은 원래 좀 가볍고 동적인 언어였는데, MS의 닷넷 입맛대로 대수술을 거치다 보니 그냥 C#의 표현력에 필적하는 전형적인 절차형 언어가 된 것 같은 느낌이 든다. 예전의 베이직 같은 느낌은 파이썬이 더 잘 간직하고 있는 듯.

배열 첨자도 ()로 싸고, 함수 호출 인자도 ()로 싸는 건 베이직의 특징이다. 언뜻 보기에 굉장히 혼동될 것 같은데 C++처럼 [] () 따로 연산자 오버로딩이라도 해야 하는 게 아니라면 의외로 둘이 문법 차원에서 혼동될 일은 없다. 참고로 본인은 ::와 .의 구분이 없는 객체지향 언어들에 대해서도 의아해한 적이 있었는데 이 구분 역시, 포인터만 없다면 거의 필요하지 않다.

그러고 보니 베이직은 대입도 =, 동등 비교도 =이다. A=B=1이라고 하면 C언어 식으로 치자면 A=B==1처럼 해석된다. 원래 베이직의 대입문은 Let A=1 처럼 써 줘야 맞는데 Let이 C언어의 auto만큼이나 캐잉여로 전락하는 바람에 지금 같은 꼴이 된 것이다. 그러고 보니 Let을 Dim처럼 변수 선언 키워드... 아니 C++0x의 auto처럼 쓰는 것도 괜찮을 것 같다?

Dim A as Double
Dim I as Integer

뿐만 아니라

Let A = 0.52 '자동으로 실수 확정
Let I = 5    ' 자동으로 정수 확정

이렇게도 되게 말이다. 타입이 이랬다저랬다 바뀌는 Variant가 아님. 기발하지 않은지? ㄲㄲ

베이직처럼 구문 분석이 쉬운 언어는 IDE의 인텔리센스나 코드 자동 완성 같은 기능이 C++의 그것과는 비교할 수 없이 안드로메다급으로 훨씬 더 빠르고 똑똑하고, 돌아가는 게 손에 착착 달라붙는다. 도스 시절의 퀵베이직이 이미 인텔리센스만 없을 뿐이지 그런 꿈의 프로그램 개발 환경을 어느 정도 제공하고 있었다. 빌드 속도는 두말 할 나위도 없음.

그러나 C++ 코드는 실시간으로 코드 변경 사항을 IDE가 따라잡으려면, 비주얼 스튜디오든 Source Insight든, 어쨌든 background에서 소스를 다 까 보는 작업을 하지 않으면 안 된다. 그래서 어떻게든 처리 속도를 올리려고 덕지덕지 남기는 부가 정보 데이터가 많다. 함수 이름을 바꾼 게 C/C++은 복잡한 절차를 거쳐 최소한 수 초 뒤에 IDE의 ClassView에 반영되는 반면, 베이직은 ‘즉시’이다.

이런 생산성과, C++ 특유의 졸라 가볍고 효율적인 네이티브 코드라는 두 마리 토끼를 모두 잡은 프로그래밍 언어 + 개발 환경은 정녕 없는 것일까.
하긴, 윈도우 환경에서 베이직 언어로 네이티브 코드를 생성하는 컴파일러는 MS 제품 중에는 없고 파워베이직이라는 브랜드가 있다. 하지만 인지도가 안습한 수준.

Posted by 사무엘

서식을 지원하지 않는 단순한 텍스트 에디터를 워드 프로세서로 발전시키려면 무슨 작업이 필요할까?
뭐니뭐니해도 글자마다 서식을 달리 지정할 수 있어야 한다. (서체, 속성, 크기, 색깔 등등)
그런데 그걸 구현하는 과정에서 개념적으로 굉장히 중요한 결정을 내려야 하는 게 있다. 바로, 장치 독립적인(device-independent) 레이아웃을 구현하는 것이다.

장치 독립이란, 표시 화면의 해상도(=확대 배율)와 관계없이 글자들의 비율과 위치가 일정하게 유지되는 걸 말한다. 쉽게 말해 위지윅(WYSIWYG)이다. 요즘 워드 프로세서에서는 필수인 이 기능을 지원하기란 장치 종속 레이아웃보다 훨씬 더 어렵다.
우리에게 잘 알려져 있는 장치 종속 레이아웃과 장치 독립 레이아웃의 예는 다음과 같다.

장치 종속적 레이아웃: 웹브라우저 화면. MS 엑셀. MS 워드의 웹/개요 모드, Draft/normal view. 워드패드
장치 독립적 레이아웃: MS 워드의 인쇄 모드(print layout) view. 아래아한글, Acrobat PDF, 그리고 모든 프로그램들의 '인쇄 미리보기 (print preview)'

차이를 아시겠는가?

WWW
iiiiiiiiiiiii

가변폭 글꼴로 두 줄에 W와 i를 비슷한 폭이 되는 개수로 찍은 뒤(당연히 i의 개수가 훨씬 더 많아짐),
화면 배율을 아주 작게 줄였다가 아주 크게 확대해 보라.
W와 i의 폭의 편차가 크면 장치 종속적인 레이아웃이고,
대체로 전반적인 배율은 잘 유지되지만 그 대신 작은 크기에서 i들끼리의 픽셀 간격이 들쭉날쭉하다면(저해상도에서 보정을 위해 어쩔 수 없이) 그건 장치 독립적인 레이아웃이다.

엑셀을 실무에서 오래 써 본 분들은 이미 아시겠지만, 엑셀은 심지어 Page layout view에서도 위지윅이 전혀 보장되지 않기 때문에 화면에서 보는 글자의 폭과 인쇄해서 보는 글자의 폭의 차이를 유의해야 한다.
화면으로 보기 좋게 글자수나 폭을 맞춰 놓은 것은 인쇄를 하거나 심지어 확대 배율만 바꿔 봐도 모조리 어긋나 버리기 때문이다.
편집 화면이 아니라 오로지 '화면 인쇄'만이 장치 독립성이 보장되는 결과를 보여준다.
엑셀은 대용량의 데이터를 수월하게 다루기 위해서, 성능상의 이유로 위지윅 편의는 희생한 셈이다.

요즘 워드 2007은 처음 시작했을 때 인쇄 모드 view로 시작하지만, 옛날, 한 97~2000 버전까지만 해도 print layout이 아니라 normal view가 기본 모드였다. 아래아한글은 비슷한 개념으로 '쪽윤곽' 옵션이란 게 있어서 둘의 차이는 화면에 용지의 여백이 나타나 보이는지의 여부가 고작이지만, 워드의 normal view는 print layout view보다 훨씬 더 이질감이 컸다. 그림이나 표 같은 틀이 제 위치에 표시되지 않고 다단(column)이나 세로쓰기 같은 건 아예 무시되었으니까...;; 그리고 근본적으로 normal view는 앞서 말했듯이 위지윅이 보장되지 않는다.

이런 view가 기본 mode였던 이유는 두말 할 나위도 없이.. normal view가 문서를 훨씬 덜 정교하게 대충 렌더링하기 때문에, 처리 속도가 훨씬 더 빠르기 때문이었다.
normal에서 신나게 긴 글을 편집하고 있다가 print layout으로 처음으로 모드를 바꾸면, 워드는 “페이지를 정돈하고 있습니다. 잠시 기다려 주십시오”라고 뜸을 들이곤 했다.

장치 독립적인 레이아웃에서는 여백이나 글자 크기 따위를 나타낼 때 픽셀이 아니라 어느 매체에서도 동일한 절대적인 단위가 쓰인다. 그래서 아래아한글이라든가 PDF 같은 문서 파일 포맷 스펙을 보면 그런 개념을 찾을 수 있으며, 아래아한글의 경우는 1/n 인치가 최소 단위였지 싶다.

운영체제 API는, 해상도가 서로 넘사벽급으로 다룬 모니터와 프린터를 모두 동일 코드만으로 수월하게 다루기 위해서 다양한 추상적인 좌표계와 확대 배율을 지원하며, WM_PAINT뿐만이 아니라 WM_PRINT 같은 (잘 알려지지 않은) 메시지도 제공하고 있다.
MFC가 OnPaint말고 OnDraw라는 화면· 프린터 통합 메소드를 제공하는 것 역시 다 이유가 있어서인 것이다
.
흠, 그러고 보니 나도 포스트스크립트나 '텍' 같은 전자 조판 언어를 공부하고 싶긴 한데, 접할 기회가 없구나.;;

Posted by 사무엘

1.

이 블로그는 좀 특이한 구석이 있다.
보통, 덕력이 좀 높은 블로거는 전문 분야 블로그와 일상 잡담 블로그를 분리해서 운영한다.
하지만 본인은 그렇게 하지 않으며 모든 관심 분야에 대한 글을 한 블로그에다 몰아서 올린다.
블로그를 따로 운영해야 할 정도로 덕력이 아주 높은 것도 아니어서 말이다..... 어? ㄲㄲㄲㄲ

난 사람들이 자기 관심 분야 블로그에만 가는 걸 원하지 않는다.
내 근황이 궁금하고 나에 대해 알고 싶어서 내 블로그에 온 사람이라면, 좋든 싫든 프로그래밍 관련 글도 보고, 철-_-도 관련 글도 보고, 한글 관련 글, 기독교 관련 글도 보길 원한다.
독자 여러분은 어떻게 생각하실지 모르겠지만 어쨌든 본인은 내 식대로 이런 식으로 블로그를 운영해 나갈 것이다. ㅋㅋ
<날개셋> 한글 입력기 카테고리가 몇 달째 글이 없으니 오늘은 또 오랜만에 개발 근황을 전하도록 하겠다.

2.

<날개셋> 한글 입력기의 다음 버전은 6.2로 확정했다. 나흘 뒤인 8월 21일 아침에 나올 예정이다. 현재 코딩은 거의 마쳤고 테스트와 도움말 작성 중이다.
편집기를 안 쓰는 분에게는 그리 큰 해당 사항이 없겠지만, 6.2에 대해서는 지금까지 오랜 숙원이었던 에디팅 엔진의 최적화 소식부터 먼저 전해야겠다.
무려 7년 전, 3.0 시절 이래로 변함없이 남아 있던 에디팅 엔진을 뒤집어엎었다. 옛날 코드의 로직을 재구성하여 더 정교하게 다시 만드는 게 쉬운 일이 아니었다.

예전 버전이 얼마나 비효율적이었는지를 단적으로 설명하자면 이렇다.
수십만 줄에 달하는 텍스트를 불러와서 맨 앞줄에서 엔터를 눌러서 줄을 삽입하거나 텍스트를 붙여넣으면 그 줄부터 문서 끝까지 내부적으로는 행번호가 다 renumbering된다. -_-;;
그리고 undo 한번 할 때마다 그 텍스트 레이아웃이 전부 다시 짜진다.

이제는 아무리 큰 문서를 불러와도 텍스트 레이아웃과 재배치는 영향을 받은 문단에서만 일어나며, renumbering도 없어졌다. Ctrl+Z를 마음껏 눌러도 된다.
다른 작업 우선순위에 밀리고 또 밀려서 7년 동안 못 하고 있던 일을 이제야 해냈다.
3.0을 만들던 당시는 세벌식 모아치기와 새로운 한글 입력 오토마타에 치중하느라, 에디팅 엔진은 비록 구닥다리 2.x에 비해서야 혁신이었지만 그래도 시간 관계상 대충 발로 짠 부분이 있었던 것이다.

이번 버전은 파일 저장도 매 줄마다 디스크에 쓰는 게 아니라, 수 MB 단위로 버퍼에다 미리 저장한 후 한꺼번에 디스크에 쓰게 함으로써 속도를 크게 향상시켰다. 이렇게 하는 게 이 정도로 큰 차이를 만들 줄은 몰랐다.
<날개셋> 변환기의 파일 변환 속도도 훨씬 더 빨라졌다.
학교에서 실제로 수~수십 MB에 달하는 옛한글 말뭉치 파일을 다뤄 보고서야 성능을 개선할 필요를 느꼈다.

3.

그리고 <날개셋> 편집기는 이제 legacy format(한컴 2바이트 코드 및 한양 PUA)으로 클립보드를 읽고 쓰는 기능이 없어지고, 편집 메뉴에 '선택하여 붙여넣기'(Paste special) 기능도 없어진다. Paste special은 무려 <날개셋> 한글 입력기 2.0때부터 있었던 기능이지만, 이 프로그램이 텍스트에다 서식을 넣을 수 있는 워드 프로세서도 아니고 사실 필요 없는 기능이다. 유니코드 하나만 신경 쓰면 되니까 말이다.

그 대신 이 기능들은 <날개셋> 변환기로 이동한다. 다만, 지금까지 한컴 2바이트 코드를 읽는 것 말고 '쓰는' 기능은 제2수준 한자를 지원하지 않았었는데, '쓰는' 것도 가능해진다. 클립보드 변환 기능까지 그대로 지원되긴 하지만, 아래아한글 97이나 <날개셋> 무려 2.x와 텍스트 데이터를 변환하는 상황이 아니라면 이제 쓸 일은 없을 것이다. 그러니 호환성 유틸리티인 변환기로 기능 이전.
하지만 유니코드가 등장하기 전에 아래아한글이 국어 정보 처리에 끼친 영향력을 감안하면, 한컴 2바이트 코드 지원을 완전히 없애 버릴 수는 없다.;;

또한, 옛한글을 한양 PUA <-> 유니코드 5.2 형식으로 변환하는 기능은 '텍스트 필터'로도 들어가서 편집기나 외부 모듈이 즉석에서 사용 가능하게 된다. 한양 PUA의 인지도는 아직까지도 무시할 수 없기 때문에..;;
이걸 감안하면, 비록 편집기의 한양 PUA 지원 기능은 겉으로는 일관성 차원에서 사라지지만, 동일 기능이 더 유용한 다른 형태로 대체되는 셈이다.

덤으로, <날개셋> 변환기는 옛한글 변환은 지금까지 UTF16 방식의 파일밖에 지원하지 않았다가 이제 드디어 UTF8도 지원할 예정이다. 그리고 명령줄에서는 하위 디렉터리의 모든 파일을 재귀적으로 찾아서 변환하는 /S 옵션이 추가된다.

4.

이렇듯, <날개셋> 한글 입력기의 다음 버전은 편집기와 변환기가 바뀐 게 많고 외부 모듈은 변화 사항이 상대적으로 적다고 볼 수 있다. 그래도 외부 모듈이 바뀐 걸 나열하자면,

첫째, 한글 글자판을 찾을 때 무조건 맨 위의 0번부터 그 아래가 아니라, 6.0에서 추가된 개념인 '기본 입력 항목'부터 먼저 고려하기 시작했다. (진작에 이렇게 했어야지..)
둘째, 편집기와 외부 모듈을 같이 쓰는 경우, 편집기에서 프로그램의 UI 언어를 바꾸면 외부 모듈도 아쉬운 대로 그걸 따라가게 했다.

이 외에, 프로그램 전반적으로는
수식에서 ? : 연산자와 콤마 연산자가 변수를 되돌리면 거기에 바로 대입이 가능하게 문법이 확장되었으며,
정 재민 님의 제안과 도움 덕분에 몇몇 글꼴들이 최신 유니코드 규격대로 업데이트되었다.
그리고 천지인· 나랏글과 더불어 스마트폰의 3대 복수 표준 입력 방식 중 하나가 된 팬텍 SKY 방식도 예제 입력 설정 파일을 만들어서 추가했다.

텍스트 필터 중에 '일괄 치환 필터'라고, 여러 건의 바꾸기 작업을 한꺼번에 수행하고 심지어 줄바꿈 문자까지 찾기-바꾸기 문자열에 포함할 수 있는 강력한 필터가 있는데,
여기에 있던 사소한 버그를 잡고, 이 필터에 '반복 적용' 옵션을 추가했다.
이걸 잘 활용하면 [   a   ], [ b  ] 같은 문자열도 싹 다 [a], [b] 같은 식으로 일괄적으로 공백 정리를 할 수도 있다. 이런 기능을 넣을 생각을 지금까지 왜 안 했는지 모르겠다.
적은 노력에 비해서 무척 유용할 수 있는 기능을 찾아내서 구현하는 건 참 즐거운 일이다.

끝으로, 타자연습은,
문장 연습 중에 오타를 내고서 Ctrl+Z를 눌렀을 때, 텍스트가 없어진 뒤에도 텍스트 위의 오타 마크가 사라지지 않던 버그를 잡았다.
그리고 게임은 이제 레벨이 올라갔을 때 자동 저장을 해 주지 않는다. 게임 중에 사용자가 단축키를 눌렀을 때만 해당 단계의 점수, 방어력, 주인공으로 나중에 게임을 이어서 할 수 있게 그 상태가 저장된다. 따라서 해당 단계의 초반에 저장을 하든, 끝날 때가 다 돼서 저장을 하든 그건 상관없다.

<날개셋> 타자연습의 게임 저장 체계는 어찌 보면 페르시아의 왕자 1의 그것과 비슷해졌다고 볼 수 있다.
(레벨의 첫 시작 시점만 저장할 수 있고, 한 시점만 저장 가능하다는 점에서)

5.
끝으로 여담,
<날개셋> 편집기처럼 텍스트 에디터를 처음부터 새로 만든다는 건 결코 쉬운 일이 아니다.
특히 유니코드의 complex script를 완벽하게 지원하려면 이미 거의 워드 프로세서 수준에 도달한다. 커서 이동, 마우스 포인터 위치로부터 문자열 위치 판단, 문단 정렬 같은 기본 중의 기본 작업들조차 완전 어려운 작업이 되기 때문이다. 내 프로그램은 그런 자질구레한 건 개발의 주목적이 아니기 때문에 죄다 깔끔하게 무시하고 개발되는데도 이 작업만으로도 코드의 양이 만만찮다.

WinAPI.co.kr의 운영자로 유명한 김 상형 님은 이런 텍스트 에디터를 개발하는 튜토리얼을 제공하고 있으니 초보 개발자들에게 무척 유익하다. 요즘 세상에 저 정도 프로젝트를 대인배스럽게 공개하는 분은 정말 드문데... 관심 있으신 분은 참고하기 바란다.

<날개셋> 입력기와 타자연습의 다음 버전도 어김없이 예전 버전과의 API 호환성은 깨질 예정이다. =_=;;; 따라서 둘을 원활히 같이 쓰려면 둘을 모두 업데이트해야 한다.
이제는 좀 바꿀 일이 없겠지 싶은 요소들도 계속 바뀐다. 그만큼 <날개셋> 한글 입력기는 여전히 활발하게 개발이 진행 중이고 살아 있는 프로젝트라는 뜻이기도 하다.

당초 계획했던 한자 관련 기능을 추가 못 하고, 입력기 커널에 내가 원하는 기능을 여건상 못 넣었는데, 이건 올해 하반기에 나올 또 다음 버전에서 기약을 해야겠다.

Posted by 사무엘