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

지금으로부터 30년쯤 전에 도스용으로 만들어졌던 프로그래밍 툴 중에는 자기 언어로 만들어진 예제 프로그램으로 그럴싸한 게임을 제공하는 경우가 있었다.
QBasic의 경우, 포트리스 내지 Scorched Earth와 비슷한 형태의 턴 기반 슈팅인 '고릴라'가 유명했으며.. 길다란 뱀을 사방으로 적절히 조종하면서 아이템(?)을 먹는 퍼즐인 nibbles도 있었다.

아이템을 먹을수록 뱀은 길이가 더 길어지며, 머리가 벽은 물론이고 자기 몸통과도 부딪치지 않도록 조종을 잘 해야 한다. 그리고 레벨이 올라갈수록 뱀의 이동 속도가 더 올라가고 장애물도 더 많아져서 게임 진행이 더 어려워진다.
영문판 원판은 80*25 텍스트 화면에서도 아스키 그래픽 문자를 적절히 이용해서 글자 한 칸을 상하로 쪼개어 세로 공간을 두 배로 늘리는 편법을 구현했다. 하지만 한글판에서 제공된 nibbles는 문자 코드의 한계로 인해 그런 게 다 삭제되었다.

그런데 가만히 생각해 보니 마소 말고 볼랜드 개발툴에서 제공한 예제 프로그램 중에는 가히 이 분야의 끝판왕이 있었다. 번듯한 체스 게임이 컴퓨터 AI까지 포함해서 소스가 통째로 제공되었던 것이다.

이거 기억하는 분 계신가..?
그런데 이게 bgidemo보다 훨씬 덜 유명하고, 본인도 지난 수십 년 동안 얘의 존재를 까맣게 잊고 있었던 이유는.. 아무래도 아무 버전에서나 쉽게 볼 수 있는 예제는 아니었기 때문이지 싶다.
즉, 보급형인 Turbo가 아니라 기함급인 Borland라는 브랜드가 붙은 C++ 내지 Pascal을 설치하고, Windows 개발 환경에다 자체 프레임워크 라이브러리까지 다 선택해야 얘를 구경하고 돌려볼 수 있다.

이 예제 프로그램의 이름은 볼랜드에서 개발한 C++용 Windows API 프레임워크의 이름을 딴 OWL Chess였다.
하지만 내 기억이 맞다면 Turbo Vision 기반의 도스용 체스 예제도 있었다. 체스판과 말을 그래픽 모드가 아니라 텍스트 모드에서 꽤 기괴한 색과 특수문자를 동원해서 표현했던 걸로 기억하는데.. 정확한 내역은 너무 오래돼서 잘 모르겠다.

Windows용 OWL Chess는 이런 식으로 동작했던 걸로 본인은 기억한다.

• 16비트 전용이다. 32비트 에디션에도 포함됐다거나, Delphi 및 C++ Builder 같은 후대의 컴포넌트 기반 RAD툴로 리메이크 됐다는 소식은 내가 아는 한 없다. 그러니 얘는 Windows XP에서 실행됐을 때도, 저 스크린샷에서 보다시피 프로그램의 제목 표시줄에 테마가 적용돼 있지 않다.
• 역시 저 스크린샷에서 묘사된 바와 같이, 창 크기는 고정 불변이다. 요즘처럼 모니터가 크고 화면 해상도가 높은 시대엔 크기 조절이 안 되는 프로그램은 사용자에게 좋은 인상을 주기 어려울 것이다.
• 키보드 포커스가 딴데로 넘어가서 프로그램이 비활성화 되면 즉시 게임판이 가려지고 pause 모드로 바뀐다.
• 컴퓨터 AI는 1990년대의 바둑 같은 보드 게임 AI들이 그랬던 것처럼 규칙 기반으로 move를 평가하고, 재귀적으로 수읽기를 하면서 알파-베타 가지치기로 복잡도를 제어하는 식으로 구현됐다. 생각하는 데 시간이 많이 걸리긴 하지만, 멀티스레드라는 것도 없던 시절에 이 동작이 찔끔찔끔 idle time processing만으로 잘 만들어져 있다. 컴퓨터의 생각이 현재 어느 정도까지 진행됐는지가 수시로 현란하게 시각적으로 표시되기 때문에 지겹지 않다.

하긴, 1990년대 초중반에는 프로그래밍깨나 공부 좀 한 사람들이 도스의 그래픽 모드에서 아기자기한 오목· 장기 게임을 구현해서 PC 통신 자료실에 무료로 공개한 게 많았다. 아, 심지어 화투 치는 고도리...도 그 시절부터 있었다.
또한 그 시절에 유명한 프로그래밍 기술 간행물이던 '비트 프로젝트' 시리즈에도 초창기엔 Borland C++로 개발한 Windows용 장기 게임이 있었다.

지금이야 국내에서 유료 판매까지 되고 있는 장기 게임 프로그램으로는 '장기도사'가 있다. 하지만 그 전에는 '바다장기'라는 프로그램도 있었는데, 얘가 내 기억이 맞다면 저 원조 OWL Chess의 소스를 기반으로 만들어진 듯했다.
프로그램의 외형과 동작이 굉장히 비슷하게 느껴졌었기 때문이다. 또한 바다장기도 검색을 해 보면 16비트스러운 스크린샷밖에 안 나오는 게 더욱 비슷하다.

그래도 서양의 체스와 동양의 장기가 완전히 동일한 게임은 아닐 텐데, 체스 AI를 장기 AI로 룰을 개조하는 건 건 아무나 할 수 있는 일이 아니었을 것이다. 그리고 그 원판 AI 코드도 move를 기술하고 평가하는 룰 계층만 바꿔 주면 어지간한 보드 게임의 AI에 모두 대응 가능하도록 상당히 추상적이고 깔끔하게 잘 만들어져 있었던 모양이다. 바다장기는 AI를 '추론 엔진'이라는 용어를 써서 표현했다.

일개 예제 프로그램의 체스 AI가 전문 상업용 AI에 비할 바는 아니겠지만.. 이 정도만 해도 어디인가? 지금 저 프로그램의 소스를 다시 볼 수 있으면 보드 게임 AI의 구현과 관련해서 많은 통찰을 얻을 수 있을 텐데 아쉽다. 얘의 소스만 어디 github에 따로 올라와도 될 텐데 말이다.
본인은 체스는 룰조차도 모르지만.. 그래도 학창 시절에 오목과 스크래블이라는 보드 게임 AI를 연구했던 이력이 있는 사람이어서 이런 쪽에 더욱 흥미를 느낀다.

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 사무엘

한 달쯤 전에 비주얼 베이직 리뷰를 쓴데 이어 오늘은 델파이와 해당 계열 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++은 null-terminated 문자열이라는 단순하고 독특한 체계를 사용하는 반면, 다른 언어들은 그렇지 않다.
그렇기 때문에, 문자열 상수가 실행 파일 내부에 어떤 형태로 박혀 있는지를 추적하면, 이 프로그램이 무슨 언어로 만들어졌겠는지 추측이 어느 정도 가능하다.

과거의 도스 시절에는 볼랜드 사에서 개발한 터보 시리즈의 컴파일러가 인기가 많았다. C/C++과 파스칼이 기억에 남는다. 이 볼랜드 제품은 당시 타사의 컴파일러가 제공하지 않던 두 가지 독자적인 기능이 있었다. 하나는 깔끔하게 잘 만들어진 IDE(에디터)였고, 다른 하나는 BGI(볼랜드 그래픽 인터페이스)라고 일컬어지는 그래픽 API였다.

한 IDE에서 프로그램을 바로 빌드-실행-디버그할 수 있으니 프로그램 개발 생산성이 뛰어나고 굉장히 편리하다. 이에 덧붙여, 그래픽은 그렇잖아도 printf 같은 표준화된 API 규격이 전무해서 ‘싸제’ 라이브러리에 의존할 수밖에 없던 영역인데, 자체 개발 라이브러리가 있다 보니 볼랜드의 컴파일러는 폭발적인 인기를 모을 수밖에 없었다.
bgidemo라고 유명한 그래픽 API 예제 프로그램도 있었는데 기억하는 분이 있으려나 모르겠다. QBasic용 예제 프로그램인 nibbles, gorilla 게임과 비슷한 시기에 만들어진 그 시절 추억이다.

아래의 스크린샷은 이 BGI 라이브러리를 사용해서(=링크해서) 만들어진 어느 EXE 파일 내부를 들여다본 모습이다. 그래픽 라이브러리이다 보니 내부적으로 출력하는 에러 메시지 문자열, 가령 No error, (BGI) graphics not installed, 심지어 Out of memory in flood fill 같은 친숙한 문자열이 내장되어 있음을 알 수 있다. 그런데 동일한 문자열들 사이에 한 놈은 ▲, →, ← 같은 이상한 기호가 듬성듬성 끼어 들어가 있다. 왜 그럴까?

기호가 없는 프로그램은 C언어(=터보 C)로 만들어진 프로그램이다. 왼쪽의 16진수값을 보면 알겠지만, 이들은 모든 문자열들이 그냥 0번 문자로 구분되어 있다.
그러나 기호가 있는 프로그램은 파스칼로 만들어진 프로그램이다. ▲, →, ←은 다음에 뒤따르는 문자열의 길이를 의미한다. 예를 들어 “▲Graphics hardware not detected”를 보면 ▲의 코드 번호는 0x1E, 즉 30인데 그 에러 메시지의 길이는 30바이트임을 알 수 있다. 얘네는 반대로 문자열들 사이에 0번 문자가 전혀 존재하지 않는다.

실제로 C/C++ 말고 String이 built-in type으로 존재하는 언어들은 이렇게 글자 수를 따로 저장해 놓는 방식으로 문자열들을 관리한다. 베이직으로 만들어진 프로그램도 QuickBasic이든 PowerBasic이든 문자열 상수들을 들여다보면 비슷한 결과를 얻을 수 있다. 그래서 이런 언어는 문자열의 길이를 구하는 함수의 시간 복잡도가 O(1)인 반면, C언어만 strlen의 시간 복잡도는 O(n)이다.

베이직 언어들은 문자열의 길이가 16비트 정수로 저장되던 반면, 터보 파스칼은 문자열 길이를 달랑 8비트 크기로 저장하여, 문자열의 길이가 256자를 넘을 수 없다는 한계가 존재했다. 흠;;

파스칼로 만든 프로그램을 들여다보면 Runtime error 같은 문자열도 존재한다. 이 역시 C/C++로 만들어진 프로그램에서는 디버그 빌드가 아닌 이상 있을 수 없는 개념이다. C/C++은 배열 첨자 범위의 검사조차도 안 할 정도로 런타임 에러라는 개념 자체가 존재하지 않는-_- 언어이기 때문이다. 그저 컴퓨터 다운(도스 시절)이 아니면 segmentation/page fault(요즘 같은 보호 모드 운영체제에서)-_-만이 존재할 뿐. -_-;;

그 반면, %d, %s이라든가 Null pointer assignment 같은 문자열이 있다면 그건 99.9% C 라이브러리가 들어갔다는 뜻이고 그 프로그램은 C/C++로 작성되었다고 유추할 수 있다.

덧붙이는 말

1. 볼랜드는 BGI 라이브러리만큼이나 텍스트 모드용 GUI? TUI? 툴킷으로 Turbo Vision이라는 라이브러리를 개발한 것으로도 유명했다. MS가 도스용 비주얼 베이직을 잠시나마 개발했다면 볼랜드에는 이런 게 있었던 셈. 당장 터보 C++과 파스칼의 IDE부터가 이를 사용해서 개발되기 시작했다. 비록 C/C++과 파스칼에서 모두 지원되긴 했지만 이 언어의 주 개발 및 지원 언어는 파스칼이었지 싶다. MS가 베이직을 좋아한다면, 볼랜드는 전통적으로 파스칼을 더 좋아하는 회사였다. (그러니까 훗날 델파이까지 만들었지)

지금은 세월이 세월이다 보니 소스가 완전히 풀려서 이이 프로젝트는 오픈소스 진영에서 관리되고 있다. 내 기억이 맞다면 DJGPP의 IDE인 Rhide가 이 Turbo Vision의 오픈소스 버전으로 개발되었다.
그리고 우리나라에서 PC 경진대회가 정보 올림피아드로 최초로 바뀌었던 1996년(13회), 대회의 채점 프로그램이 Turbo Vision 기반으로 개발되어 있던 걸 본인은 분명히 봤다.

2. 오늘날 윈도우용 네이티브 EXE/DLL이 만들어지는 출처는, 내 감으로는 비주얼 C++이 적게 잡아도 70% 이상, 그 뒤에 소수의 오픈소스 프로젝트용으로 gcc, 그리고 끝으로 델파이 정도가 고작인 것 같다. 볼랜드는 그 후로 다른 회사에 인수되면서 이름도 여러 번 바뀌고(InPrise, CodeGear, Embarcadero 등...;;) 우여곡절을 많이 겪었는데 걔네 입장에서는 옛날의 영광이 그리울 법도 할 것 같다.

3. BGI 라이브러리와 파워베이직--얘 역시 전신이 볼랜드 사의 터보 베이직이긴 했지만--의 그래픽 라이브러리는 이상하게도 VGA mode 13h를 지원하지 않아서 개인적으로 아쉬웠었다. (퀵베이직은 지원했는데...) 해상도가 너무 낮아서 한글· 한자 같은 문자를 찍는 데는 부적격이었지만 256색 덕분에 게임 만들 때는 필수이던 그래픽 모드이다. 그게 지원됐으면 그 당시 게임 만들기가 훨씬 더 수월했을 텐데 말이다.

Posted by 사무엘

C는 작고 쪼잔하고 오덕스럽게 만들어진 언어이다(이런 특성을 상당수 물려받은 C++도 포함). 문법에서도 이런 면모가 발견되는데, 가능한 한 예약어 개수를 줄이고 연산자와 기호만으로, 그리고 이 토큰이 쓰인 주변 문맥을 통해서 구문의 의미가 파악되도록 언어를 설계한 것이다.

비슷한 계열의 구조화 프로그래밍 언어인 파스칼과 비교하면 문법이 얼마나 극단적으로 다른지 알 수 있다. begin end 대신 간단히 { } 이다. function, procedure처럼 서브루틴을 나타내는 예약어가 따로 존재하지 않는다. 그냥 자료형과 ()가 함수를 나타내며, 아예 void라는 예약어가 따로 존재한다. var 같은 예약어도 없이 변수 선언이 바로 가능하다. forward 같은 예약어가 없어도 함수의 선두 선언이 가능하며, 별도의 array 예약어가 없이 배열을 선언할 수도 있다. 순수 가상 함수를 선언하는데  pure 같은 별도의 예약어를 추가한 게 아니라 그냥 함수 = 0이란 표현으로 대체한다. 이게 바로 C++의 사고방식이다.

이렇게 극도로 함축적인 문법 덕분에, 프로그래머는 일단 타이핑을 덜 해도 되니 좋다. 1970년대에는 언어도 기계 저수준 프로그래밍을 위해 한없이 쪼잔해져야만 했던 때임을 기억할 필요가 있다. 그 시절에 무슨 인텔리센스라든가 코드 자동 완성 같은 사치스러운 기능이 있었단 말인가?

하지만 이런 언어 구조 때문에 C, 특히 C++은 코드를 알아보고 구문 분석하기가 무척 까다로운 언어가 되고 말았다. 사람에게만 힘든 게 아니라 컴파일러 입장에서도 말이다. 단순히 암호 같은 포인터 참조와 연산자 남발 때문에 알아보기 어려운 차원이 결코 아니다.

전산학적으로 말하면 C/C++의 문법은 문맥 자유 문법이 아니다. 가령 C++ 언어의 global scope에서,

a b(c, d);
위의 문장은 C++의 경우 함수의 선언일까, 아니면 개체의 선언일까?

a<100> b;
그리고 위의 문장은 템플릿을 이용한 개체일까, 아니면 비교 연산일까?

즉, a~d의 타입이 무엇이냐에 따라 구문의 의미, 즉 파싱 방법이 완전 극단적으로 달라진다. 마치 보는 방식에 따라 GOOD으로도 보이고 EVIL로도 읽히는 중의적인 그림처럼 말이다.
C++의 문법은, 의미를 파악하기 위해 파싱을 하는데 각 토큰의 의미를 모르면 제대로 파싱을 할 수 없는 그런 구조인 것이다!

그렇기 때문에 C++ 코드는 IDE 차원에서 간단한 인텔리센스나 자동 완성 기능만 구현하기 위해서라도 코드를 전부 읽어서 사실상 컴파일을 해 봐야 한다. 게다가 전처리기를 거쳐서 #define 심볼까지 일일이 벗기면서 말이다. C#이나 자바는 C++과 매우 유사한 구문을 갖고 있고 똑같이 { } 블록 구조이지만, 문맥 자유 문법을 갖추고 있으며, 의미 분석이 C++보다 훨씬 더 간단하다.

파스칼은? 더 말이 필요 없다. 소스 코드를 단 한 번만 읽으면서 앞으로 되돌아갈 필요조차 없이 구문 분석 + 코드 생성이 다 되는 구조이다! 물론 같은 의미를 표현하더라도 C/C++보다 거추장스럽고 프로그래머가 불편한 게 더 많긴 하지만 말이다.

자바와 C#이 C++에 존재하는 모호성을 없앤 것 중 하나는 new 연산자이다.
생성자 함수 호출을 동반하는 개체는 무조건 new로 선언하게 되어 있기 때문에, new가 동반되지 않은 a b(c, d) 같은 구문은 일단 개체 선언은 절대 아니고 함수 선언이라고 보장할 수 있는 것이다.

C/C++의 문법을 더욱 문맥 의존적이고 지저분한 판타지로 바꾼 것 중 하나는 type casting이다. 별도의 type casting 연산자나 예약어가 존재하는 게 아니라 그냥 앞에다가 타입 이름을 써서 괄호로 싸는 걸로 형변환이 되게 만들어 버렸으니 원...  (a)+b 라는 구문에서 +는 a가 무엇이냐에 따라서 이항 연산자일 수도 있고 아닐 수도 있다. 포인터의 의미를 겸하고 있는 * 까지 가면 더욱 복잡해진다.

게다가 C++에서는 생성자 변환 스타일까지 허용되니 더욱 지저분해졌다! (type)value 뿐만 아니라 type(value)까지 된다는 소리. 이런 어정쩡한 문법 때문에, 소스 코드에서 명시적인 형변환이 일어나는 곳만 딱 찾기도 곤란하다는 점 역시 큰 문제였다.

보다못해 1990년대 중반에는 C++에 4종류의 별도의 형변환 연산자가 예약어로 추가됐다. static_, dynamic_, reinterpret_, const_로 시작하는 cast 연산자가 그것이다. 취지는 좋은데 C언어 철학과는 전혀 어울리지 않을 정도로 예약어 길이가 너무 긴 게 흠이다.

C++은 C언어의 호환성을 존중하여 설계되었지만, 그렇다고 해서 C의 strict superset으로 설계된 것도 아니다. 일부 문법은 바뀌거나 더 엄격해졌기 때문에, 어떤 C 코드는 C++ 언어 문법으로는 컴파일이 되지 않는다. C 영역과 C++ 영역을 엄밀하게 분리한 것도 아니고 그냥 어중간하게 C에다가 OOP 개념을 집어넣다 보니 문법은 더욱 복잡해지고, 특히 동일한 개념을 나타내는 문법이 여럿 존재하는 등( (int)a, int(a)라든가, 포인터와 참조자 중복처럼 ㅋㅋ), 참을 수 없는 지저분함에 환멸을 느끼는 프로그머도 존재할 정도이다.

그래도 오늘날까지 컴퓨터와 직통으로 네이티브 대화가 가능한 가장 강력하고 효율적인 언어라는 장점, 오로지 그거 하나 때문에 C/C++은 메이저급 언어로 군림 중이다. 더 깔끔하고 수학적으로 엄밀한 프로그래밍 언어를 좋아하는 사람이라면 이런 현실을 결코 달갑게 여기지 않겠지만 말이다.

Posted by 사무엘