1. 스마트 포인터의 필요성

C/C++에서 포인터로 참조하는 동적 메모리가 안전하게 관리되기 위해서는.. 가장 간단하게는 포인터의 생명 주기와 그 포인터가 가리키는 메모리 실체의 생명 주기가 동일하게 유지돼야 할 것이다. 어느 한쪽이 소멸되면 다른 쪽도 소멸돼야 한다. C++에서는 이 정도 절차는 포인터를 클래스로 감싸고 그 클래스의 생성자와 소멸자 함수를 구현함으로써 자동화할 수 있다.

하지만 이것만으로 문제가 다 해결되는 건 아니다. 어떤 메모리에 대한 포인터의 ownership이 더 깔끔하게 관리되고 통제돼야 한다. 멀쩡한 주소값이 딴 걸로 바뀌어서 원래 가리키던 메모리로 접근 불가능해지거나(leak..), 이미 해제된 메모리를 계속 가리키고 있다가 사고가 나는 일도 없어야 한다.

그런 일을 예방하려면 여러 포인터가 동일 메모리를 참조하는 것을 완전히 금지하고 막든가, 아니면 reference count 같은 걸 따로 둬서 그런 상황에 대비를 해야 한다. 실행시켰을 때 뻑이 날 만한 짓은 아예 컴파일이 되지 않고 거부되게 해야 한다.
이런 메모리 관리를 자동으로 해 주는 클래스가 표준 C++ 라이브러리에도 물론 구현돼 있으며, 크게 두 가지 관점에서 존재한다.

  • 배열 지향: POD 또는 비교적 단순한 오브젝트들의 동적 배열로, 원소들의 순회, 추가· 삭제와 전체 버퍼 재할당 같은 동작에 최적화돼 있다. 원소 전체 개수와 메모리 할당량 정보가 별도로 들어 있으며, 문자열 클래스도 어찌 보면 배열의 특수한 형태라고 간주할 수 있다. [] 연산자가 오버로딩 돼 있다.
  • 오브젝트 지향: 단일 오브젝트 중심으로 메모리 할당 크기보다는 소유자(ownership) 관리에 더 최적화돼 있다. 그래서 구현 방식에 따라서는 원소 개수 대신 레퍼런스 카운트 정보가 있곤 한다. 담고 있는 타입 형태로 곧장 활용 가능하게 하기 위해, ->와 * 같은 연산자가 반드시 오버로딩 돼 있다.

C/C++은 배열과 포인터의 구분이 애매하니 helper class는 각 분야에 특화된 형태로 따로 구현되었다는 것을 알 수 있다.
배열 버전이야 std::vector라는 유명한 클래스가 있고, 오브젝트를 담당하는 물건을 우리는 smart pointer라는 이름으로 오랫동안 불러 왔다.

Windows 진영에서도 ATL 내지 WTL 라이브러리에는 일반 포인터뿐만 아니라 COM 인터페이스를 감싸서 소멸자에서 Release를 해 주고, 대입 연산자 및 복사 생성자에서 AddRef 따위 처리를 해 주는 간단한 클래스가 물론 있었다.
소멸자는 예외 처리가 섞여 있을 때 더욱 빛을 발한다. 함수의 실행이 종료되는 경로가 여럿 존재하게 됐을 때 goto문을 안 쓰고도 메모리 단속이 꼼꼼하게 되는 것을 언어와 컴파일러 차원에서 보장해 주기 때문이다. 그리고 이 정도 물건은 C++ 좀 다루는 프로그래머라면 아무라도 생각해 내고 구현할 수 있다.

2. 초창기에 도입됐던 auto_ptr과 그 한계

C++은 이런 스마트 포인터도 표준화하려 했으며, 그 결과로 auto_ptr이라는 클래스가 C++98 때부터 도입됐다. 선언된 헤더는 #include <memory>이다.
그러나 auto_ptr는 오늘날의 최신 C++의 관점에서 봤을 때는 썩 좋지 못한 설계 형태로 인해 deprecate됐다. 이미 이걸 사용해서 작성돼 버린 레거시 코드를 실행하는 것 외의 용도로는 사용이 더 권장되거나 지원되지 않게 되었다.

그 대신, C++11부터는 용도를 세분화한 unique_ptr, shared_ptr, weak_ptr이라는 대체제가 등장했다. 이거 마치 C-style cast와 C++ *_cast 4종류 형변환의 관계처럼 보이지 않는가? =_=;;

auto_ptr은 한 메모리를 오직 한 포인터만이 참조하도록 하고 포인터가 사라질 때 소멸자도 호출해 주는 최소한의 기본 조치는 잘 해 줬었다. auto_ptr<T> ptr(new T(arg1, ...)) 같은 꼴로 선언해서 사용하면 됐다. 하지만...

(1) 단일 포인터와 배열의 구분이 없었다.
물론 스마트 포인터는 전문적인 배열 컨테이너 클래스와는 용도가 다르니, 원소의 삽입· 삭제나 원소 개수 관리, 메모리 재할당 처리까지 할 필요는 없다.

하지만 클래스의 소멸자에서 호출해 주는 clean-up을 별도의 템플릿 인자로 추상화하지는 않았고 그냥 delete ptr로 고정해 놓았기 때문에.. 당장 delete와 delete[]조차도 구분할 수 없어서 번거로웠다. 다시 말해 auto_ptr<T> ptr(new T[100]) 이런 식으로 써먹을 수는 없다.

(2) 포인터의 ownership을 관리하는 것까지는 좋으나.. 그게 복사 생성자 내지 대입 연산자에서 우항 피연산자를 변조하는 꽤 기괴한 형태로 구현돼 있었다.
무슨 말이냐 하면.. auto_ptr<T> a(ptr), b에서 b=a 또는 b(a)라고 써 주면.. b는 a가 가리키는 값으로 바뀜과 동시에 a가 가리키는 값은 NULL로 바뀌었다. 즉, 포인터와 메모리의 일대일 관계를 유지시키기 위해, 소유권은 언제나 복사되는 게 아니라 이동되게 한 것이다.

그렇게 구현한 심정은 이해가 되지만, 대입 연산에서 A=B라고 하면 A만 변경되어야지, B가 바뀌는 건 좀 납득이 어렵다.
복사 생성자라는 것도 형태가 T::T(const T&)이지, T::T(T&)는 아니다. 차라리 임시 객체만 받는 R-value 이동 전용 생성자라면 T::T(T&&)이어서 우항의 변조가 허용되지만, 복사 생성자는 그런 용도가 아니다.

(3) 위와 같은 특성이랄지 문제로 인해.. auto_ptr은 call-by-value 형태로 함수의 인자나 리턴값으로 그대로 전달했다간 큰일 났다.
메모리의 소유권이 호출된 함수의 인자로 완전히 옮겨져 버리고, 그 함수가 끝날 때 그 메모리는 auto_ptr의 소멸자에 의해 해제돼 버리기 때문이다. 이 문제를 컴파일러 차원에서 잡아낼 수 없다. (뭐, 이미 free된 메모리를 이중으로 해제시키는 사고는 나지 않는다. 깔끔한 null pointer 접근 에러가 날 뿐.)

auto_ptr을 함수 인자로 전달하려면 그냥 call-by-reference로 하든가, 아니면 그 원래의 T* raw 포인터 형태로 전해야 했다.
아니, 함수 인자뿐만 아니라 값을 그대로 함수의 리턴값으로 전할 때, 혹은 vector 및 list 같은 컨테이너에다 집어넣을 때 등.. 임시 객체가 발생할 만한 모든 상황에서 동일한 문제가 발생하게 된다.

이게 제일 치명적이고 심각한 문제이다. 여러 함수를 드나들고 컨테이너에다 집어넣는 것도 raw pointer와 다를 바 없이 가볍게 되라고 smart pointer를 만들었는데 그러지 못한다면.. 이걸 만든 의미가 없다. 그러면 한 함수 안에서 달랑 소멸자 호출만 자동화해 주는 것 말고는 쓸모가 없다.
또한, 매번 call-by-reference로 전하는 건 엄밀히 말해 포인터의 포인터.. 즉, 포인터를 정수가 아니라 구조체 같은 덩치 큰 물건으로 취급하는 거나 마찬가지이고..

이런 이유로 인해 auto_ptr은 좋은 취지로 도입됐음에도 불구하고, 현재는 이런 게 있었다는 것만 알고 최신 C++에서는 잊어버려야 할 물건이 됐다.
(1) C 라이브러리 함수라든가(gets...) (2) C++ 키워드뿐만 아니라(export) (3) C++ 라이브러리 클래스 중에서도 흑역사가 생긴 셈이다.

auto_ptr이 무슨 보안상의 결함이 있다거나 성능 오버헤드가 크다거나 한 건 아니다. 21세기 이전에는 C++에 R-value 참조자 같은 문법이 없었으니 복사 생성자에다가 move 기능을 집어넣을 수밖에 없었다. 나중에 C++에 언어 차원에서 smart pointer의 불편을 해소해 주는 기능이 추가된 뒤에도 이미 만들어진 클래스의 문법이나 동작을 변경할 수는 없으니 새 클래스를 따로 만들게 된 것일 뿐이다.

3. unique_ptr

auto_ptr의 가장 직접적인 대체제는 unique_ptr이다.
얘는 최신 C++에서 새로 추가된 문법을 활용하여 단일 개체와 배열 개체를 구분할 수 있다. unique_ptr<T>와 unique_ptr<T []>로 말이다. 신기하다..;;
그리고 템플릿 가변 인자 문법을 이용하여 new를 생략하고 std::make_unique<T>(arg1, arg2..) 이렇게 객체를 생성할 수도 있다. 얘는 C++14에서야 도입된 더 새로운 물건이다.

unique_ptr은.. 말 많고 탈 많던 복사 생성자와 대입 연산자가 막혀 있다. 함수에 날것 형태로 전달하거나 컨테이너에 집어넣는 등의 시도를 하면.. 그냥 컴파일 에러가 나게 된다. 그래서 안전하다.
이전의 auto_ptr이 하던 것처럼 소유권을 옮기는 것은 R-value 이동 생성자라든가 std::move 같은 다른 방법으로 하면 된다.

어떤 클래스에 대해서 복사 생성자와 대입 연산자가 구현돼 있지 않으면 컴파일러가 디폴트, trivial 구현을 자동 생성하는 편이다. 각 멤버들에 대한 memcpy 신공 내지 대입 연산자 호출처럼 해야 할 일이 비교적 직관적으로 뻔히 유추 가능하기 때문이다. 하지만 클래스에 따라서는 그런 오지랖이나 유도리가 바람직하지 않으며 이를 금지해야 할 때가 있다. 인스턴스가 단 하나만 존재해야 하는 singleton 클래스, 또는 저렇게 반드시 1핸들, 1리소스 원칙을 유지해야 하는 클래스를 구현할 때 말이다.

그걸 금지하는 가장 전형적이고 전통적인 테크닉은 해당 함수를 private으로 선언해 버리는 것이 있다. (정의는 당연히 하지 말고)
하지만 이것도 friend 함수에서는 안 통하는 한계가 있기 때문에 최신 C++에서는 액세스 등급과 별개로 상속 받았거나 디폴트 구현된 멤버 함수의 사용을 그냥 무조건적으로 금지해 버리는.. = delete라는 문법이 추가되었다. 순수 가상 함수를 나타내는 = 0처럼 말이다! unique_ptr은 이 문법을 사용하고 있다.

그럼 unique_ptr은 컨테이너에 집어넣는 게 전혀 불가능한가 하면.. 그렇지 않다.

vector<unique_ptr<T> > lc;
lc.push_back( unique_ptr<T>(new T) );

처럼 push_back이나 insert에다가 T에 속하는 변수를 줄 게 아니라 저렇게 애초부터 R-value 임시 객체를 주면 된다.
그러면 임시 객체의 ownership이 컨테이너 안으로 자연스럽게 옮겨지고, 컨테이너 안의 unique_ptr만이 유일하게 T를 가리키고 있게 된다.

얘는 auto_ptr보다 상황이 훨씬 더 나아졌고 이제 좀 쓸 만한 smart pointer가 된 것 같다.
사실, 작명 센스조차도.. auto는 도대체 뭘 자동으로 처리해 준다는 건지 좀 막연한 구석이 있었다. 그게 unique/shared로 바뀐 것은 마치 '인공지능'이라는 막연한 용어가 AI 암흑기를 거친 후에 분야별로 더 구체적인 기계학습/패턴인식 같은 말로 바뀐 것과 비슷하게 들리기도 한다. ㅎㅎ

4. shared_ptr와 weak_ptr

그럼 다음으로, shared_ptr을 살펴보자.
얘는 마치 COM의 IUnknown 인터페이스처럼 reference counting을 통해 다수의 포인터가 한 메모리를 참조하는 것에 대한 대비가 돼 있다. 그래서 unique_ptr과 달리, 대입이나 복사를 자유롭게 할 수 있다.

(1) 날포인터는 그냥 대책 없이 허용하기 때문에 ownership 문제가 발생하고.. 아까 (2) auto_ptr은 무조건 ownership을 옮겨 버리고, (3) unique_ptr은 깔끔하게 금지하는데 (4) 얘는 참조 횟수를 관리하면서 허용한다는 차이가 있다. 소멸자는 가리키는 놈의 reference count를 1 감소시켜서 그게 0이 됐을 때만 실제로 메모리를 해제한다.

그래서 shared_ptr은 크기 오버헤드가 좀 있다.
unique_ptr은 일반 포인터 하나와 동일한 크기이고 기술적으로 machine word 하나와 다를 바 없는 반면, shared_ptr은 reference count 데이터를 가리키는 포인터를 추가로 갖고 있다. 일반 포인터 두 개 크기를 차지한다.

이는 static_cast보다 dynamic_cast가 오버헤드가 더 큰 것과 비슷한 모습 같다. 그리고 멤버 포인터가 다중 상속 하에서의 this 오프셋 보정 때문에 추가 정보를 갖고 있다면, 얘는 ownership 관리 때문에 추가 정보를 갖고 있다는 점이 비교된다.

끝으로, weak_ptr이라고, shared_ptr로부터 얻어 올 수 있는 포인터도 있다. 얘는 이름에서 유추할 수 있듯이 reference count를 건드리지 않으며 소멸자에서도 아무 처리를 하지 않는 포인터.. 즉 일반 포인터와 차이가 사실상 없는 물건이다. 순환 참조 문제를 예방하려면 A에서 B를 참조한 뒤에 B에서 또 A를 참조할 때는 레퍼런스 카운트를 건드리지 않아야 하기 때문이다.

그런데도 일반 포인터 대신 굳이 이런 자매품도 따로 만든 이유는 언어 차원에서의 무결성 보장처럼 for the sake of completeness 때문으로 보인다. 무결성 보장이란 게 무슨 말인지 예를 들자면, weak_ptr은 가리키는 주소가 반드시 shared_ptr로부터 유래되었고, unique_ptr과는 절대 섞이지 않는다는 것 말이다.

물론 COM 인터페이스도 아니고 일반 포인터에서 굳이 weak_ptr이 필요할 정도로 극단적인 상황은 현실에서는 거의 없을 것이다. 상상조차 잘 안 된다. 포인터 A가 다른 클래스 B를 가리키는데, 그 클래스 B 내부에 포인터 A가 소속된 다른 객체를 가리키는 포인터가 들어 있다던가.. 뭐 그런 상황 정도이다.
다만, 순환 참조는 단순히 A→B→A뿐만 아니라 A→B→C→A 같은 더 복잡한 형태로도 발생하고, 일단 발생한 것을 감지하기란 몹시 난감하다. 그러니 weak_ptr이라는 개념 자체는 반드시 필요하다.

이상이다. 그냥 생성자와 소멸자를 적절히 구현해 주고 ->와 *만 오버로딩 해 주면 끝일 것 같은 smart pointer도 깊게 들어가면 내막이 생각보다 더 복잡하다는 것을 알 수 있다.
Rust 언어는 garbage collector 기반이 아니면서 더 독특한 방식으로 메모리 소유권을 관리한다던데 그 내막이 어떠했던지가 다시 궁금해진다.

5. 여담

(1) = delete는 다시 봐도 참신하기 그지없다. delete라는 키워드가 연산자 말고 이런 용도로도 활용되는 날이 오더니!
배열 첨자 연산자이던 []와 구조체 참조 연산자이던 ->가 람다 선언에서 의미가 완전히 확장된 것만큼이나 참신하다.
하긴, 옛날에 템플릿이 처음 등장했을 때.. 그저 비교 연산자일 뿐이었던 <와 >가 완전히 새로운 여닫는 형태로 사용되기 시작한 것도 정말 충격적인 변화였을 것이다.

(2) 글쎄, 멤버 함수의 접근을 금지하는 방법이 저렇게 도입됐는데, 어떤 클래스에 대해서 Java의 final이나 C#의 sealed처럼 상속이 더 되지 않게 하는 옵션은 C++에 도입되지 않으려나 모르겠다. C++은 타 언어에 없는 protected, private 상속이 존재하지만 상속 자체를 금지하는 옵션은 없어서 말이다.

특히 내부 구조가 아주 간단하고 가상 함수가 존재하지 않는 것, 특히 소멸자가 가상 함수 형태로 별도로 선언되지 않은 클래스는 상속을 해도 어차피 polymorphism을 제대로 살릴 수 없다. 그냥 단순 기능 확장에만 의미를 둬야 할 것이다.
Java는 모든 함수가 기본적으로 가상 함수일 정도로 유연한데도 이와 별개로 상속을 금지하는 옵션이 있는데.. 그보다 더 경직된 언어인 C++은 의외로 그런 기능이 없다.

(3) C/C++의 사고방식에 익숙한 프로그래머라면 포인터란 곧 메모리 주소이고, 본질적으로 machine word와 동일한 크기의 부호 없는 정수 하나일 뿐이라는 편견 아닌 편견을 갖고 있다.
하지만 객체지향이라든가 함수형 등 프로그래밍 언어 이론을 조금이라도 제대로 구현하려면 숫자 하나만으로 모든 것을 표현하기엔 부족한 포인터가 얼마든지 등장하게 된다.

앞서 다뤘던 shared_ptr이라든가 다중 상속을 지원하는 멤버 함수 포인터..
그리고 자기를 감싸는 문맥 정보가 담긴 클래스 객체 포인터라든가 람다 함수 포인터 말이다.
C++은 전자를 기본 지원하지 않기 때문에 모든 클래스들이 Java 용어로 치면 개념적으로 static class인 거나 마찬가지이다.
그리고 후자를 기본 지원하지 않기 때문에 람다는 캡처가 없는 놈만 기존 함수 포인터에다 담을 수 있다.

그런 것들이 내부적으로 어떻게 구현되고 구현하는 시공간 비용이 어찌 되는지를 프로그래머라면 한 번쯤 생각할 필요가 있어 보인다.

(4) C++에서 class T; struct V; 처럼 이름만 전방 선언된 incomplete type에 대해서는 제일 단순한 직통 포인터, 그리고 무리수가 좀 들어간 멤버 포인터 정도만 선언할 수 있다. T나 V의 실체를 모르니 이런 타입의 개체를 생성하거나, 포인터를 실제로 참조해서 뭔가를 할 수는 없다.
그런데 이런 불완전한 타입을 가리키는 포인터를 상대로 delete는 가능할까? 난 이런 상황에 대해 지금까지 한 번도 생각해 본 적이 없었다.

sizeof(T)의 값을 모르더라도 포인터가 가리키는 heap 메모리 블록을 free하는 것은 얼마든지 가능하다. 애초에 malloc/void가 취급하는 것도 아무런 타입 정보가 없는 void*이니 말이다.
그러니 operator delete(ptr)은 할 수 있지만, 해당 타입에 대한 소멸자 함수는 호출되지 못한다.

컴파일러는 이런 코드에 대해서 경고를 띄우는 편이다. Visual C++의 경우 C4510이며, delete뿐만 아니라 delete[]에 대해서도 동일한 정책이 적용된다.

Posted by 사무엘

2019/10/09 08:35 2019/10/09 08:35
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1671

그리고.. 이튿날 아침에는 계속해서 봉화로 이동하기 시작했다. 새벽에는 계절이 바뀌기라도 했나 싶을 정도로 공기가 차가워져 있었다.

사용자 삽입 이미지

주변엔 계속해서 이런 풍경이 펼쳐졌다.
그러고 보니 옛날 도로는 가드레일 말고 저렇게 노란 경계석이 쓰였던 것 같은데 요즘은 어느 샌가 보기 힘든 풍경이 돼 있다.

사용자 삽입 이미지

중간에 마을 어귀를 흐르는 요런 맑은 개울을 발견해서 차를 세우고 물놀이를 했다.
이럴 때 햇볕이 쨍쨍하고 날씨가 더 더웠으면 물놀이의 효과가 더 커졌겠지만, 폭염과 가뭄 때문에 개울이 말라 버리는 것보다야 이렇게라도 물에 들어가는 게 훨씬 더 낫다. 비 덕분에 여기 모든 개천· 개울들은 물이 콸콸 세차게 흐르고 있어서 참 보기 좋았다.
그렇잖아도 어제 땀을 많이 흘려서 몸이 온통 끈적거리는 상태였는데 싹 개운해졌다.

사용자 삽입 이미지사용자 삽입 이미지

그리고.. 일월산 자생화 공원이라는 곳을 발견해서 들렀다가 갔다. 주변에 나밖에 없는 오지에서 자연을 즐긴다는 건 참 멋진 일이다. 지구가 금성 화성과 달리 초록별이라는 사실에 경이로움과 고마움을 느끼게 된다.

사용자 삽입 이미지

영양에서 봉화로 가려면 역시 산을 하나 넘어야 하더라. 길은 어느 샌가 꼬불꼬불한 산길로 바뀌었다.
터널 안에 들어갈 때는 일반적으로는 헤드라이트를 켜는 게 맞는데, 현실에서는 '끄시오'라고 안내된 표지판도 많이 보인다. 화장실에서 휴지는 변기에 "넣으시오/넣지 마시오"만큼이나 사람을 헷갈리게 만드는 사항인 것 같다.

저 영양 터널을 지난 다음에는 행정구역이 봉화로 바뀌고, 봉화 터널과 어느 공군 부대가 뒤이어 등장했다. 그리고 오르막이 끝나고 내리막이 시작됐다.

6. 봉화군 탐험기

본인은 이번 여행의 마지막 일정으로, 봉화에서 영동선 양원 역을 답사하고 봉화 시가지로 돌아갔다.

사용자 삽입 이미지
사용자 삽입 이미지사용자 삽입 이미지

상· 하행 합쳐도 차가 몇 분에 한 대 다닐까말까인 이 꼬불꼬불 산길을 떠나고 싶지 않았다. 그래서 수시로 정차하고 사진 찍고 시동 끄고 사색에 잠기곤 했다.

사용자 삽입 이미지

산을 하나 넘어서 내려오니 또 강이 펼쳐졌다. 이 강은 온통 흙탕물이었다.

사용자 삽입 이미지사용자 삽입 이미지

그리고 영동선 철길 위를 지나갔다. 참 공교롭게도 본인이 아래를 내려다보고 있는 타이밍에 맞춰서 여객도 아니고 화물 열차가 하나 지나갔다. 얼마나 무거운 짐을 끄는지, 전기 기관차 중련에다가 보조 중형 디젤 기관차까지 편성한 상태였다.

사용자 삽입 이미지

드디어 양원 역이 자리잡고 있다는 어느 마을 어귀에 도착했다. 마을 앞에도 맑은 물이 졸졸 흐르고 있었다.
양원 역은 행정구역상 봉화이지만 동쪽 맨 끝이기 때문에 거의 울진 근처이며, 가는 길에 울진의 서쪽 끝을 경유하기도 했다. 봉화 시가지와는 수십 km 이상 떨어져 있었다.

사용자 삽입 이미지

그런데 마을에 도착했다고 끝이 아니었다. 양원 역으로 가려면 거기서도 산을 하나 타넘어야 했다~!
엔진 회전수 4000rpm을 고속도로에서 고속으로 밟을 때도 찍고, 여기서 2단 엔진 브레이크로도 찍었다. 1단 말고 2단으로 말이다.
그렇게 산을 넘은 뒤에도 저 길로 들어가야 했는데.. 차가 지나갈 수는 있지만 거기서 주민에게 민폐를 끼치지 않고 딱히 차를 세울 만한 공간이 없었다. 그래서 차는 이 부근에서 세우고 여기서부터 몇백 m 남짓은 걸어가야 했다.

사용자 삽입 이미지사용자 삽입 이미지

지도를 보니 이 강은 낙동강 상류라고 한다. 물이 콸콸 세차게 흐르고 있었다. 저 교각은 무슨 옛날에 있었던 다리의 흔적 같다.
양원 역이 이 정도로 답 없는 오지에 있는지는 미처 몰랐다. 저기를 건너간 다음에야..

사용자 삽입 이미지

드디어 얘를 실물로 보게 되었다.
예전에 태백선· 함백선 부근에서 조동 역과 함백 역을 보던 느낌이었다.

사용자 삽입 이미지

양원 역은 전국에서 유일하게.. 지역 주민들이 교통이 너무 불편해서 현기증이 나니 제발 열차 좀 정차시켜 달라고 아우성 치고 정부에 청원 넣고, 아무 국고 지원 없이 스스로 돈을 모아서 역 건물을 지어서 승인 받은 역이다. 진정한 의미의 민자역사인 셈이다. 단지, 자본주의 논리가 아니라 지역 주민 복지를 위한 민자역사인 것이고.. 그게 지금으로부터 무려 30년 전의 일이다.
전날 옥천에서 정 지용 시인 관련 안내문에서도 1988이라는 숫자를 봤는데, 양원 역의 개업 시기도 1988년 4월이라니 우연 치고는 절묘하다. (지용회: 1988년 3월)

얼마나 한이 서렸으면 양원 역에 첫 열차가 정차하던 날 사람도 감격하고 산과 강도 감격했댄다.
옛날엔 열차가 여기 마을을 통과할 때 짐보따리부터 미리 던져 놓은 뒤 더 먼 승부 역에서 여기까지 걸어서 돌아와서 그 짐을 챙겼다니..

지금으로서는 상상하기 어렵겠지만, 옛날에는 열차에 화장실이 비산식이었고(오물이 선로로 그대로...; ), 주행 중일 때 차량의 출입문이나 창문을 수동으로 조작할 수 있었다.
그럼 근성 있는 사람이라면 짐만 미리 던져 놓는 게 아니라, 자기 자신까지 훌쩍 뛰어내릴 법도 해 보이는데.. 그러기에는 아무리 젊고 민첩한 사람이라도 좀 위험했을 것 같다.

사용자 삽입 이미지사용자 삽입 이미지

영락없이 컨테이너 가건물 같은 규모이지만 컨테이너가 아니다. 시멘트를 얹어서 정식으로 지은 건축물이다.

사용자 삽입 이미지사용자 삽입 이미지

이 궁서체 안내판까지도 주민들이 직접 만든 거라고 한다.
현재는 여기가 유명세를 타면서 정규 여객열차뿐만 아니라 V-train(백두대간 협곡)과 O-train(중부내륙 순환)이라는 관광 열차도 정차하는 곳이 되었다. 그러니 역 건물과 안내판 말고 저 승강장은 코레일에서 만들었다는 티가 난다.
순환선이기 때문에 O이고, 그리고 계곡 모양을 형상화해서 V라니.. 코레일 수뇌부에서 머리 좀 쓴 것 같다. 이름을 참 기발하게 지었다.

사진을 찍지는 못했지만 마침 저기에 열차가 정차하는 것을 봤다.
이번 여행 동안 경부선과 영동선을 지나는 열차를 종종 목격했는데, 모두 전기 기관차 기반이었다. 디젤 기관차는 전혀 보지 못했다.

사용자 삽입 이미지사용자 삽입 이미지
사용자 삽입 이미지

서쪽의 봉화 시가지로 가는 길에 또 절경을 발견하여 풍경 사진을 찍었다.

사용자 삽입 이미지

그리고 오후가 돼서야 봉화 시가지에 도착했다. 이 강은 낙동강의 지류인 내성천이다.
여기서 식사를 하고 보급을 받는 것으로 2일간의 여행에 종지부를 찍었다.
올해도 어김없이 정말 즐거운 시간을 보냈다. 앞으로는 3년 주기로 남해안, 서해안, 동해안을 한 번씩 가는 것으로 어렴풋이 계획을 잡았다.

Posted by 사무엘

2019/09/13 08:33 2019/09/13 08:33
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1661

1. 재부팅 이벤트

본인은 지금까지 Windows가 시스템 종료/재시작/로그아웃 될 때.. 메시지에 즉각 응답하면서 정상적으로 돌아가는 프로그램이라면 종료 처리도 당연히 정상적으로 되는 줄로 알고 있었다.
사용자가 [X] 버튼이나 Alt+F4를 눌러서 종료할 때와 완전히 동일하게 말이다. WM_CLOSE에 이어 WM_DESTROY, WM_NCDESTROY가 날아오고, WM_QUIT이 도달하고, message loop이 종료되고, MFC 프로그램으로 치면 ExitInstance와 CWinApp 소멸자가 호출되고 말이다.

왜냐하면 시스템이 종료될 때 발생하는 현상이 언뜻 보기에 정상적인 종료 과정과 동일했기 때문이다. 저장되지 않은 문서가 있는 프로그램에서는 문서를 저장할지 확인 질문이 뜨고, 운영체제는 그 프로그램 때문에 시스템 종료를 못 하고 있다고 통보를 한다. 좋게 WM_CLOSE 메시지를 보내는 걸로 반응을 안 하는 프로그램에 대해서만 운영체제가 TerminateProcess 같은 강제 종료 메커니즘을 동원할 것이다.

그런데 알고 보니 그게 아니었다.
정상적인 종료라면 ExitInstance 부분이 실행되어야 할 것이고 프로그램 설정들을 레지스트리에다 저장하는 부분도(본인이 구현한..) 실행돼야 할 텐데, 내 프로그램이 실행돼 있는 채로 시스템 종료를 하고 나니까 이전 설정이 저장되어 있지 않았다.

꼭 필요하다면 WM_ENDSESSION 메시지에서 사실상 WM_DESTROY 내지 ExitInstance와 다를 바 없는 cleanup 작업을 해야 할 듯했다. 뭐, 날개셋 한글 입력기에서 이 부분이 반영되어 수정돼야 할 건 딱히 없었지만 아무튼 이건 내 직관과는 다른 부분이었다.

시스템이 종료될 때 발생하는 일은 딱히 디버거를 붙여서 테스트 가능하지 않다. =_=;; 로그 파일만 기록하게 해야 하고, 매번 운영체제를 재시작해야 하니 가상 머신을 동원한다 해도 몹시 불편하다. 꽤 오래 전 일이 됐다만, 날개셋 외부 모듈이 특정 운영체제와 특정 상황에서 시스템 종료 중에 운영체제 시스템 프로세스 안에서 죽는 문제가 발생해서 디버깅을 한 적이 있었다. 몹시 골치 아팠었던 걸로 기억한다.

2. 파일의 동등성 비교

파일 이름을 나타내는 어떤 문자열이 주어졌을 때,

  • 상대 경로(현재의 current directory를 기준) vs 절대 경로
  • 과거 Windows 9x 시절이라면 ~1 같은 게 붙은 8.3 짧은 이름 vs 원래의 긴 이름
  • 대소문자 (Windows는 대소문자 구분이 없으므로. 그런데 이것도 A~Z 26자만 기계적으로 되나? 언어별로 다른 문자의 대소문자는?)
  • 그리고 옵션으로는 정규 DLL search path와 환경 변수

이런 것들을 몽땅 다~ 감안해서 다음과 비스무리한 일을 하는 가벼운 API가 좀 있으면 좋겠다. 보다시피 동일한 파일을 표현하는 방법이 굉장히 다양하기 때문이다.

  • 두 개의 파일 명칭이 서로 동일한 파일인지 여부를 판단. 당연히 파일을 직접 open/load하지 않고 말이다.
  • 그 파일의 대소문자 원형을 유지한 절대 경로. 일명 '정규화된' 이름을 되돌린다. 이게 동일한 파일은 물리적으로, 절대적으로 동일한 파일임이 물론 보장된다.
    참고로 Windows API 중에서 얼추 비슷한 일을 한다고 여겨지는 GetFullPathName이나 GetModuleFileName 함수는 절대 경로 말고 파일의 대소문자 원형 복원이 제대로 되지 않는다.
  • 혹은 그 파일의 시작 지점이 디스크에서 물리적으로 어디에 있는지를 나타내는 64비트 정수 식별자를 구한다. 포인터가 아니지만 파일의 동등성 여부 판단은 가능한 값이다. 정수를 넘어 UUID급이어도 무방함.

본인은 비슷한 목적을 수행하기 위해, 그냥 두 파일을 CreateFileMapping으로 열어 보고 리턴된 주소가 동일하면 동일한 파일로 간주하게 한 적이 있었다. 핸들 말고 MapViewOfFile 말이다. 본질적으로 동일한 파일이라면 운영체제가 알아서 같은 주소에다 매핑을 하고 레퍼런스 카운트만 증가시킬 테니까..
Windows 9x에서는 주소가 시스템 전체 차원에서 동일하겠지만 NT 계열에서는 한 프로세스 내부에서만 동일할 것이다.

하지만 내가 필요한 건 파일의 내용이 아니라 그냥 두 파일의 동등성뿐인데 이렇게 매핑을 하는 건 overkill 삽질 같다는 인상을 지울 수 없었다.
비슷한 예로, LoadLibrary도 같은 파일에 대해서는 같은 리턴값이 돌아온다. HMODULE도 오늘날은 핸들이 아니라 메모리 map된 주소이니까.. 다만, 오버헤드를 줄인답시고 LoadLibraryEx + LOAD_LIBRARY_AS_DATAFILE 이렇게 열어서는 안 된다. 그러면 로딩 방식이 크게 달라지더라.

3. JNI에서 문자열 처리하기

Java 언어는 JNI라고 해서 자기네 바이트코드 가상 머신이 아닌 C/C++ 네이티브 코드를 호출하는 통로를 제공한다.
프로그램 자체를 C/C++로 짜던 시절에는 극한의 성능을 짜내야 하는 부분에 어셈블리어를 집어넣는 게 관행이었는데.. 이제는 일반적인 코딩은 garbage collector까지 있는 상위 계층에서 수행하고, 극한의 성능을 짜내야 하는 부분에서만 C/C++ 코드를 호출한다는 게 흥미롭다.

JNI는 그냥 언어 스펙에 가까운 광범위한 물건이다. Windows 환경에서는 그냥 Visual C++로 빌드한 DLL이 export하는 함수를 그대로 연결할 수도 있다. 물론 그 DLL을 빌드하기 위해서는 Java SDK에서 제공하는 jni 인터페이스 헤더와 static 라이브러리를 사용해야 한다.
한편, 안드로이드 앱 개발에서 쓰이는 NDK는 JNI 스펙을 기반으로 자체적인 C++ 컴파일러까지 갖춘 네이티브 코드 빌드 도구이다.

Java의 문자열은 JNI에서는 jstring이라고 내부 구조를 알 수 없는 자료형의 포인터 형태로 전달된다. C++에서는 UTF-8과 UTF-16 중 편한 형태로 바꿔서 참조 가능하다.
UTF-8로 열람하려면 JNIEnv::GetStringUTFChars를 호출하면 된다. 길이를 알아 오려면 GetStringUTFLength부터 호출한다. 전해받은 문자열 포인터는 ReleaseStringUTFChars로 해제한다.

그 반면, UTF-16 형태로 열람하려면 위의 함수 명칭에서 UTF를 빼면 된다. GetStringChars, GetStringLength, ReleaseStringChars의 순이다. Java가 내부적으로 문자를 2바이트 단위로 처리하기 때문에 이들이 주로 취급하는 자료형은 jchar*이다. 그러니 얘는 char16_t 자료형과 호환된다고 간주해도 좋다. 참고로 wchar_t는 NDK 컴파일러의 경우 4바이트로 처리되더라.

UTF-16이나 UTF-8이나 다 UTF이긴 마찬가지인데, Java는 변별 요소인 8을 생략하고 함수 이름을 왜 저렇게 지었나 개인적으로 의구심이 든다. 물론 GetStringChars는 Java가 내부적으로 문자열을 원래부터 2바이트 단위로 처리하다 보니 우연히 UTF-16과 대응하게 됐을 뿐, 대놓고 UTF-16을 표방했던 건 아닐 것이다. 뭐, 이제 와서 그 체계를 바꾸는 건 불가능하고 "자바 문자열 = 2바이트 단위"는 완전히 고정되고 정착했지만 말이다.

또한 GetStringChars는 GetStringUTFChars와 달리 굉장히 치명적으로 불편한 단점이 하나 있다. 바로.. 변환된 문자열이 NULL-terminated라는 보장이 없다는 것이다!
그래서 본인은 이 포인터를 사용할 때 메모리를 n+1글자만치 또 할당해서 null문자를 추가해 주는 매우 번거로운 두벌일을 하고, 아예 클래스를 이렇게 따로 만들어야 했다. 좀 개선의 여지가 없으려나 모르겠다.

class CJstrToString16 {
    JNIEnv *_ev;
    jstring _jstr;
    const jchar *_ret;
    char16_t *_arr;
public:
    CJstrToString16(JNIEnv *ev, jstring js): _ev(ev), _jstr(js) {
        jsize n = ev->GetStringLength(js);
        _ret = ev->GetStringChars(js, NULL);
        _arr = new char16_t[n+1];
        memcpy(_arr, _ret, n*sizeof(char16_t));
        _arr[n] = 0; //고작 요거 하나 때문에..
    }
    ~CJstrToString16() {
        ev->ReleaseStringChars(_jstr, _ret);
        delete[] _arr;
    }
    operator const char16_t*() const { return _arr; }
};

4. Visual C++의 STL

C++은 타 프로그래밍 언어들과 달리, 심지어 전신인 C와도 달리, 언어가 개발되고 나서 자신의 특성을 잘 살린 라이브러리가 언어 차원에서 붙박이로 곧장 제정되지 않았던 모양이다. 그래서 각 컴파일러들이 중구난방으로 파편화된 형태로 라이브러리를 제공해 오다가.. 표준화라는 게 1990년대 말이 돼서야 논의되기 시작했다.

템플릿이 추가되어 C++에서도 제네릭, 메타프로그래밍이라는 게 가능해진 뒤부터 말이다. 처음에는 자료구조 컨테이너 위주로 STL이라는 이름이 붙었다가 나중에는 그냥 C++ library가 된 걸로 본인은 알고 있다.

Windows용으로 가장 대중적인 C++ 컴파일러야 두 말할 나위 없이 MS Visual C++이다. 얘는 거의 20여 년 전 6.0 시절부터 P.J. Plauger라는 사람이 구현한 C++ 라이브러리를 제공해 왔다. C 라이브러리와 달리 C++ 라이브러리는 소스가 비교도 안 될 정도로 복잡하고 난해하다는 것(암호 같은 템플릿 인자들..=_=), 그리고 저렇게 마소 직원이 아닌 개인 이름이 붙어 있다는 게 인상적이었다. 2000년대 초까지만 해도 휴렛-패커드라는 회사명도 주석에 기재돼 있었다.

P.J. Plauger는 현재는 Dinkumware라고 C++ 라이브러리만 전문적으로 관리하고 라이선스 하는 회사를 설립해 있다. 나이도 생각보다 지긋한 듯..
그런데 이런 세계적인 제품에 들어가는 라이브러리가.. 성능이 의외로 시원찮은가 보다. Visual C++이 제공하는 컨테이너 클래스가 유난히도 느리다고 까이는 걸 여러 사이트에서 봐 왔다.

최근에는 본인 직장의 상사마저도 같은 말씀을 하시기에 "헐~!" 했다. 업무상 필요해서 string, set, map 등을 써서 수십, 수백 MB에 달하는 문자열을 분석하는 프로그램을 돌렸는데, 자료 용량이 커질수록 속도가 급격히 느려져서 자료구조를 직접 새로 짜야 할 판이라고 한다.

난 개인적으로는 C++ 라이브러리를 거의 사용하지 않고, 더구나 그걸로 그 정도까지 대용량 작업도 해 보지 않아서 잘 모르겠다. 그 날고 기는 전문가가 만든 코드에 설마 그런 결함이 있으려나? 아니면 컴파일러의 최적화 문제인지?

글쎄.. 이런 게 있을 수는 있다. MFC의 CString은 그냥 포인터와 크기가 동일하며 값으로 전할 때의 reference counting도 처리한다. 그러나 std::string은 자주 쓰이는 짧은 문자열을 번거로운 heap 메모리 할당 없이 빠르게 취급하기 위한 배열까지 내부에 포함하고 있다. 이런 특성을 모르고 std::string도 함수에다 매번 value로 전달하면 성능에 악영향을 줄 수밖에 없다.

그런 식으로 임시 객체가 쓸데없이 생겼다가 사라지는 구조적인 비효율이 C++ 라이브러리에 좀 있는 걸로 들었다. R-value 참조자 &&가 도입된 것도 vector의 내부 처리에서 그런 삽질을 예방하는 근거를 언어 차원에서 마련하기 위해서라지 않는가? 그리고 Visual C++이 그런 비효율을 보정하는 성능이 좀 시원찮다거나 한 것 같다. 전부 다 그냥 추측일 뿐이다.

그러고 보니 cout<<"Hello world"가 printf("Hello world")보다 코드 오버헤드가 작아지는 날이 과연 올지 모르겠다. 이것도 그냥 떡밥인 건지..?? =_=;;

Posted by 사무엘

2019/04/09 08:32 2019/04/09 08:32
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1606

1. 32비트 컴파일러: 16비트 메모리 접근의 한계를 극복하기

예전에도 언급한 적이 있지만.. 1993년 말에 발매되었던 Doom 게임은 그야말로 충격적인 3차원 그래픽 덕분에 게임 업계에 큰 충격을 선사했다. 업계 종사자들은 기술 수준 자체뿐만 아니라 "얘는 어셈블리어를 거의 사용하지 않고 순수 C만으로 개발되었습니다"라는 존 카맥의 말에 더 큰 충격을 받게 됐다.

훗날(1997년) Doom의 소스 코드가 공개되면서 이 말은 사실임이 밝혀졌다.
Doom은 무슨 16비트 Windows 같은 쑤제 어셈블리어 튜닝 위주로 개발된 게 아니라, Windows NT처럼 굉장히 이식성 있게 개발되었다. 그러니 Doom 엔진 기반의 수많은 게임과 mod들이 온갖 플랫폼으로 이식되어 만들어질 수 있었다.

단지, 오리지널 도스용의 경우, 컴파일러를 그 당시에 흔하던 볼랜드나 MS 같은 16비트용을 쓴 게 아니라 Watcom이라는 다소 생소한 32비트 고성능 제품을 썼을 뿐이다.
그리고 어셈블리어를 안 쓰더라도 고정소수점이라든가, IEEE754의 특성을 이용해서 3차원 그래픽용 실수 연산(삼각함수, 제곱근, 벡터 정규화...)을 왕창 빠르게 수행하는 각종 tweak들은 응당 최대한 구사해서 성능을 끌어올렸다.

그러니 Doom은 아직 상대적으로 생소하던 32비트 컴파일러라든가 DOS/4G 도스 익스텐더 같은 물건의 인지도를 끌어올려 줬다. 이렇게 Doom을 통해 Watcom 컴파일러까지 알렸던 id 소프트웨어에서는 훗날 퀘이크를 만들어서 이번에는 오픈소스 진영의 걸출한 도스용 32비트 컴파일러이던 djgpp를 알리게 되었다.

운영체제 자체를 OS/2나 Windows NT처럼 통째로 32비트로 쓰기에는 아직 기계값이 너무 비싸고 특히 메모리가 부족했다. 그러니 도스에서 돌아가는 일부 대형/고사양 프로그램이 자체적으로 도스의 한계를 극복하고 보호 모드로 진입하는 솔루션을 내장했던 것이다.

생각해 보니 국내에서도 아래아한글 2.1이 전문용은 Watcom C/C++을 이용한 32비트 전용으로 만들어졌다. 얘는 발매 시기가 심지어 Doom보다도 3개월 남짓 더 앞섰다(1993년 9월 vs 12월). 그러니, 터보 C, 볼랜드 C++ 하던 그 시절에도 32비트 컴파일러에 대해서 알 사람은 이미 다 알기는 했던 모양이다.

다만, 아직도 286 똥컴이 많이 굴러다니고 서민용 운영체제들은 아직도 16비트 도스와 Windows가 주류인데, 내 프로그램을 386 전용으로 개발하는 것에 대한 득과 실을 신중하게 따져야 했다. 오죽했으면 아래아한글도 후속 버전인 2.5와 3.0에서는 일반용/전문용 구분이 없어지고 그냥 hwp86.exe와 hwp386.exe 두 에디션을 모두 내장하는 것으로 형태가 바뀌었다. 추가 글꼴과 사전 컨텐츠는 '확장팩'으로 분리되고 말이다.

아래아한글은 Phar Lap 도스 익스텐더를 사용했다. 아래아한글이 그 시절의 도스용 게임처럼 DOS/4G(W) 로고를 띄우면서 실행되었다면 무척 볼 만했을 것이다.
86과 386 에디션은 성능 말고는 덧실행 프로그램이 지원되는지의 여부가 가장 큰 차이점이었다. 덧실행은 16/32비트용이 따로 나오지 않고 32비트 전용이었기 때문이다.

화면 보호기들, 그리고 확장팩에서 제공되었던 프라임 영한사전도 다 덧실행 프로그램이었다.
먼 옛날 1.2 시절에는 별도의 액세서리로 테트리스 게임이 있었는데 나중에 그게 덧실행으로 컴백한 걸 보니 개인적으로 감회가 새로웠었다.

이렇게 1990년 중반에 도스용 프로그램들의 32비트화 추세와 달리, 마소는 진작부터 PC에서 도스를 Windows로 대체하려는 큰 그림을 갖고 있어서 그런지.. 도스용으로 32비트 컴파일러를 결코 내놓지 않았다. 정작 자기들은 그 기술을 내부적으로 보유하고 사용했으면서 말이다.
Visual C++ 1.5x는 16비트 도스/Windows 바이너리들을 빌드할 수 있었는데, 명령 프롬프트에서 돌아가는 컴파일러와 링커 같은 툴들은 그냥 32비트 프로그램이 아니라 32비트 PE 기반의 콘솔 프로그램이었다.

Windows NT 같은 데서는 직통으로 실행 가능하고, 도스에서 실행되면 stub으로 embed된 도스 익스텐더가 컴을 보호 모드로 진입시키고 CreateFile/GlobalAlloc 같은 Win32 API를 제공해서 프로그램을 실행했다.
스레드를 만들지는 못했겠지만 컴파일러· 링커가 사용하는 Win32 API야 뭐 파일이나 메모리 I/O 정도밖에 없었을 것이고, 이건 도스 익스텐더가 감당 가능했다. 결국 한 바이너리만으로 도스와 Windows에서 모두 사용 가능.

이건 뭐 콘솔 프로그램계의 Win32s나 마찬가지인 엄청난 기술인데.. 마소의 Visual C++에서 이런 이중 바이너리를 만드는 걸 end-user에게 지원한 적은 내가 알기로 없다.
마치 C# 네이티브 코드 컴파일러만큼이나 대외적으로 공개되지 않고 마소 내부에 봉인된 기술인 것 같다.

2. 슈퍼 VGA 라이브러리: 표준 VGA의 한계를 극복하기

IBM 호환 PC라고 불리는 물건에서 IBM이 주도하는 PC의 단일/표준 규격이라는 건 286 AT 이후로 없어졌다. 그러니 286 이후로 최초의 386 PC는 IBM이 아닌 컴팩에서 출시되기까지 했다.
그리고 그래픽 카드도 절대불변 단일 표준은 1987년의 구닥다리 VGA가 마지막이다. 표준 VGA는 800*600 해상도조차 지원하지 않았으며, 그나마 색깔이 아쉬운 대로 다양해진 256색은 겨우 320*200에서밖에 지원되지 않아서 업무라기보다는 그냥 게임 전용 모드로만 쓰였다.

그 뒤로 VGA보다 더 높은 해상도와 더 많은 색상을 지원하는 규격은 그야말로 온갖 싸제 SVGA 제조사들이 난립하면서 파편화 천국이 됐다. VESA 같은 규격이 괜히 필요해진 게 아니다.

이게 불과 1990년대 초반의 일이니, 앞에서 언급한 보호 모드가 어떻고 DPMI가 제정되던 때와 시기적으로 비슷하다. 하긴, 1990년에 나온 그 옛날 프로그램인 Deluxe Paint조차도 처음 실행될 때 맨 아래에 1024*768 256색 SVGA 모드가 있긴 했다. 물론 당대에 그걸 선뜻 고를 수 있을 정도의 금수저 컴퓨터를 소유한 사용자는 매우 소수였을 것이다.

마소의 베이직 컴파일러야 SCREEN 명령으로 SVGA 지원은 전무했다. API 구조가 완전히 다른 3rd-party 라이브러리를 구해서 써야 했다.
볼랜드의 경우는 상황이 약간 낫다. 비록 자체적으로는 VGA까지밖에 지원하지 않았지만, 일종의 그래픽 드라이버인 bgi 파일이 내부 스펙이 공개돼 있고 확장 가능했기 때문에 이걸 기반으로 SVGA 라이브러리를 만든 곳이 있긴 했다.

검색을 해 보니 Jordan Hargraphix 소프트웨어가 이 업계의 독자적인 큰손이었던 모양이다. 이미 1991년 무렵부터 유명했다.
바이오스를 거치지 않고 일명 VGA mode X라고 불리는 320*240, 400*300 같은 변형 모드까지 다 지원했다.
그때는 소프트웨어가 잘못된 명령을 내려서 컴퓨터만 뻗게 하는 게 아니라 모니터를 손상시키는 것도 가능했던 시절이다. (주사율 변조..) 옛날에 CGA도 160*100 같은 tweak mode가 있었다고 하는데 그것만큼이나 신기한 일이 아닐 수 없다.

다만, BGI라는 그래픽 API는 무려 1980년대 후반에 개발된 것이며, 아무리 bgi 드라이버를 새 하드웨어에 맞게 확장한다 해도 256색 이상의 색을 지원하는 것은 구조적으로 불가능했다고 한다. 트루컬러 SVGA를 지원하려면 완전히 새로운 독자 라이브러리를 써야 했다.
BGI는 색상을 관리하는 게 RGB값 기반이 아니라 팔레트 인덱스 기반으로 고정돼 있었던 모양인데, 16비트 시절에 이는 충분히 수긍이 간다. 쟤가 무슨 Windows GDI 급으로 하드웨어 통합과 추상화를 표방한 물건은 아니었으니 말이다.

도스용 아래아한글은 16비트 바이너리의 경우 Turbo/Borland 컴파일러로 개발되었다. 하지만 아주 초창기인 1.x 시절부터 그래픽 라이브러리를 독자 구현했는지, 볼랜드의 보급 BGI 라이브러리를 사용한 흔적이 전혀 없는 것이 매우 흥미롭다.
이건 비슷한 시기에 도스용 한메 타자 교사도 마찬가지다. 얘도 MS C로 개발되었지, 의외로 볼랜드 출신이 아니다.

Posted by 사무엘

2019/03/23 08:31 2019/03/23 08:31
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1600

1. ? :에서 피연산자의 타입 동기화 방식

C/C++에서 포인터는 컴퓨터가 내부적으로 메모리를 다루는 메커니즘을 아무 보정 오버헤드 없이 쌩으로 노출하고 관리를 프로그래머에게 전적으로 맡기는 물건이다. 그러니 강력한 대신 매우 위험하기도 하며, 사용자의 실수가 들어가기 쉽다.

이런 한계를 극복하기 위해 C++에는 생성자와 소멸자, 템플릿, 연산자 오버로딩을 적극 활용하여 다양한 형태로 포인터를 컴파일 시점에서 자동 관리해 주는 클래스가 존재한다. 소멸자에서 자신에 대한 delete 내지 Release를 자동으로 클래스가 있으면 한결 편할 것이다. 대입도 기존 오브젝트가 없어지고 다른 걸로 대체되는 거나 마찬가지이니, 레퍼런스 카운팅 관리 같은 걸 해 주고 말이다.

함수가 실행이 실패해서 도중에 return을 해야 하는데 지금까지 할당했던 자원(메모리, 파일)들을 반환은 해야 하니.. 부득이하게 goto문을 쓰느라 코드가 지저분해지는 거 공감하실 것이다. 이런 간단한 것 하나만 생각해도 C++이 C에 비해 코딩을 얼마나 더 편리하게 해 주는지 알 수 있다.

본인은 날포인터를 써서 만들어졌던 옛날 코드를 그런 wrapper 클래스 형태로 리팩터링 했다. 가령, FOO *p = .... p->Release() 하던 것을 CAutoPtr<FOO> p 하나로 대체하는 식이다. 자원을 수동으로 해제하는 코드를 최대한 줄였다.

그런데 하루는 큰 문제 없이 이렇게 고쳐지고 컴파일 됐던 프로그램이 도저히 이해되지 않는 부분에서 뻗는 걸 발견했다.
한참을 디버깅한 끝에 알고 보니... 문제는 A ? B: C 연산자 안이었다. 원래 B와 C 모두 FOO* 타입인데, B만 CAutoPtr<FOO>로 바뀌었던 것이다. 다른쪽 C는 구조체의 멤버이다 보니 타입을 고칠 수 없었고 말이다.

내가 의도한 건 B가 operator FOO*()를 통해 FOO*로 암묵적으로 형변환되는 것이었다. 이 ? : 식은 함수의 인자로 전달되는 문맥에서 쓰였으며, 이 인자의 타입도 그냥 FOO*였다.
그러나 이때 B와 C의 타입을 동기화하기 위해 컴파일러가 한 일은.. CAutoPtr<FOO>(C), 다시 말해 C를 CAutoPtr로 승격시키고 임시 객체를 생성하는 것이었다. 그러고 나서는 그 CAutoPtr에 대해서 역으로 operator FOO*()를 호출하여 리턴값을 함수에다 전달했다.

이 클래스는 생성자에서는 딱히 하는 일 없이 인자로 주어진 메모리 주소를 대입만 하고, 소멸자에서 그 주소가 가리키는 영역을 해제했다.
그러니 임시 객체는 소멸자에서 멀쩡한 메모리를 예기치 않게 해제했으며, 이 부작용 때문에 프로그램이 죽은 것이었다. 아하, 이런 내막이 있었다니... 무릎을 쳤다.

그런데 이 문제를 깔끔하게 해결할 방법은 없는지 본인의 C++ 지식 범위에서는 답이 떠오르지 않는다. 이때는 부득이하게, B에다가 static_cast, (FOO*), operator FOO*() 같은 명시적 형변환을 지저분하게 집어넣어 줘야만 하는 걸까? (리팩터링 전에 날포인터만 쓰던 시절에는 할 필요 없던..)

아니면 CAutoPtr의 생성자를 어째 잘 만들어서 저런 형변환을 허용하지 않고 최소한 에러로 처리시킬 방법이라도 없나 궁금하다. 암시적인 R-value 임시 객체가 생기는 것만 금지하고 막으면 될 거 같은데..??
explicit을 지정하는 것만으로는 충분치 않고, 복사 생성자나 R-value 생성자 같은 걸 어설프게 건드리면 정상적인 객체 생성에 대해서도 에러가 발생하게 되더라.

FOO*를 받아들이는 상황에서도 컴파일러가 B와 C를 모두 일단 클래스로 만든 뒤에 다시 operator FOO*를 호출하는 것은 일종의 언어 차원에서의 디자인 원칙인 것 같다. C++이 함수 오버로딩도 인자의 개수와 타입만으로 판단하지, 리턴값의 타입은 전혀 감안하지 않는 것처럼 말이다. 일을 단순하게 만들기 위해 수식 내부의 토큰을 해석하는 데 수식 바깥 전체의 타입을 굳이 고려하지는 않기로 한 듯하다.

또한, template<T> void Foo(T, T) 이런 함수를 선언한 뒤, 템플릿 인자 없이 함수의 두 인자에다가 CAutoPtr<FOO>와 FOO*를 집어넣는 것은 통하지 않더라. 컴파일러가 어설프게 타입 유추와 동기화를 시도하지 않고 깔끔하게 에러를 내뱉었다. Foo<FOO*> 이렇게 T가 무엇인지를 명시적으로 써 줘야 했다. ? :와는 다른 동작으로 보인다.

? : 연산자에 대해서 본인은 먼 옛날에 대입 연산과 관련된 파싱 방식이 이해되지 않는 게 있어서 글을 쓴 적이 있는데.. 이번엔 다른 분야에서 알쏭달쏭한 게 생겼다. 흥미롭다.

A ? B:C에서 둘 중 하나가 기반 클래스이고 다른 하나가 파생 클래스라면, 이 수식의 결과값이 지칭하는 타입은 B와 C 어느 것이 걸리건 무관하게 당연히 더 범용적인 기반 클래스로 결정된다. 그런데 이것도 다중· 가상 상속이 개입하면 굉장히 골치아픈 문제가 될 것 같다. 파생 클래스가 자신의 실질적인 기반 클래스로 돌아가는 게 trivial한 일이 아니게 되기 때문이다.

2. 클래스 static 멤버 함수에서 non-static 멤버의 sizeof 구하기

C++에서 클래스의 static 멤버 함수는 그 정의상 this 포인터를 갖고 있지 않다. 명칭의 scope resolution만 빼면 기술적으로 일반 global 함수와 전혀 다를 바 없다. 그렇기 때문에 이런 함수의 내부에서 클래스의 non-static 멤버는 당연히 참조할 수 없다.

그런데 sizeof 연산자는 어떨까? 얘는 런타임 때의 메모리 값을 전혀 참조하지 않고, 컴파일 타임 때 결정되는 타입만을 기반으로 답을 구해 주는 답정너 연산자이다. 그러니 this 같은 게 전혀 필요하지 않다. 그럼에도 불구하고 아래의 코드는 옛날 컴파일러에서는 에러가 발생하며 컴파일 되지 않는다. (VC++ 기준 C2070 Illegal sizeof operand)

class Sample {
    int MEMB[4]; //일반 타입이건 배열이건 포인터건 모두 무관
public:
    static void Talk() {
        printf("%d\n", sizeof(MEMB));
    }
};

저 안에서 MEMB의 크기를 어떻게든 구하려면?
sizeof( ((Sample*)NULL)->MEMB) 라고 써 줘야 했다. 마치 구조체 내부에서 특정 멤버의 오프셋을 구할 때처럼.. Sample의 포인터를 야메로라도 만들어야 한 것이다.
sizeof의 피연산자는 실제로 실행되지는 않으니 저런다고 프로그램이 뻗지는 않는다. 하지만 미관상 깔끔하지 못하고 부자연스러운 건 어쩔 수 없다.

그런데 2015쯤 Visual C++ 후대 버전에는 sizeof(MEMB)라고 직통으로 요청하는 게 가능해졌다. 그래, sizeof 정도는 static 함수에서라도 non-static 멤버를 피연산자로 삼을 수 있는 게 이치에 맞다.
클래스 밖에서 sizeof(Sample::MEMB)라고 요청해도 된다. 다만, 위의 코드에서는 MEMB가 비공개 멤버이기 때문에 클래스 밖에서는 컴파일 에러가 나게 된다.

흥미로운 점은, VC++ 2010/2012의 경우 빌드용 메인 컴파일러와 인텔리센스용 컴파일러의 동작이 서로 다르다는 것이다.
전자는 저 문법을 지원하지 않고 에러 처리하지만, 인텔리센스 컴파일러는 그걸 인식하는지 코드에 빨간줄을 긋지 않는다. 두 말할 나위 없이 마소에서 자기 컴파일러를 C++ 표준 내지 인텔리센스용 EDG 컴파일러의 동작을 참고하여 추후에 개선한 셈이다.

3. 멤버 함수를 가리키는 템플릿 인자

수 년 전에 본인은 템플릿 인자에 단순 함수 포인터나 functor가 아니라 C++ 멤버 함수도 들어갈 수 있는 걸 발견하고 이게 신기하다고 글을 올린 적이 있다. (☞ 관련 링크)

요약하자면 template<typename T> class Foo에다가는 멤버 변수처럼 T bar를 선언한 뒤,
Foo<int(PCSTR)> f를 선언하고 template<> int Foo<int(PCSTR)>::Bar(PCSTR p) 라고 specialize된 함수 몸체를 정의하면 된다. 그러면 n = f.Bar("kekeke")를 할 수 있다.

그런데.. 이건 역시 너무 사기적이고 사악했는지.. 후대의 컴파일러에서는 지원이 끊기고 봉인됐다.
Visual C++의 경우 딱 2010까지만 지원되며, 2012부터는 C2207 a member of a class template cannot acquire a function type 에러와 함께 컴파일이 거부된다.

그리고 사실은 2010도 인텔리센스 컴파일러는 마소 컴파일러보다 시대를 앞서 갔는지, 이걸 에러로 처리하고 있었다. 단지, 에러가 발생하는 지점이 서로 다르다.
인텔리센스는 template<> int Foo<int (PCSTR)>::bar(PCSTR s) 요렇게 멤버 함수 몸체를 정의하는 부분에서 에러를 찍지만 VC++ 후대 컴파일러는 Foo<int(PCSTR)> obj; 이렇게 템플릿을 찍어내는 과정에서 에러를 찍더라.

템플릿의 인자가 :: 연산자와 함께 다른 명칭의 일부로 들어갔을 때, 그 전체 명칭이 타입명인지 변수명인지가 오락가락 한다는 이유로 typename이라는 키워드가 도입됐다.
그것처럼 템플릿 인자가 non-static한 멤버의 변수가 될 수도 있고 함수도 될 수 있는 건 무질서도가 너무 크긴 하다. static 멤버라면 함수라도 단순 포인터로 간편하게 취급할 수 있지만 non-static 멤버 함수는 그렇지 않으니까..

그러면 저 문법은 완전히 사용 금지됐는지, 아니면 멤버 함수를 템플릿 인자로 전하는 다른 방법이 있는지 그건 잘 모르겠다. 일단 멤버 포인터라는 물건 자체가 워낙 무시무시한 놈이어서 말이다.

4. friend 키워드의 클래스 명칭 인식 방식

어떤 헤더 파일 내부에.. global scope에서 class A가 먼저 선언되었다. 그 다음으로 namespace에 소속된 클래스 B가 선언되었고, B는 내부에서 class A를 friend로 선언했다 (friend class A).
Visual C++은 이 코드에서 우리 namespace에 속하지는 않지만 밖에서 먼저 정의되어 있는 A를 인식했으며, A의 멤버 함수가 B의 비공개 멤버에 접근하는 것을 허용했다.
그러나 xcode, 안드로이드 NDK 등 타 플랫폼의 C++ 컴파일러들은 A를 인식하지 못하고 에러를 내뱉었다.

이 문제의 해결 방법은 간단하다. 그냥 A라고 하지 말고 friend class ::A라고 써 주면 된다.
그럼 Visual C++은 함수 인자의 ADL 같은 것도 아닌 상황에서 왜 유도리를 발휘한 건지 궁금해진다. 심지어 이건 인텔리센스도 동일하게 맞는 문법으로 인정해 줬다.

어떤 클래스 B가 다른 클래스 A를 friend로 선언할 때, A의 명칭은 진짜 아무거나 적어 줘도 된다. friend 선언 당시에 A가 class A; 라고 달랑 전방 선언(forward)만 됐건, 아니면 심지어 전혀 선언되지 않은 듣보잡 이름이어도 된다. friend부터 맺은 뒤에 다음에 A를 선언해도 된다.
단, Visual C++의 경우, 친구 클래스 A를 인식하는 방식에서 다음과 같은 추가적인 특성이 있었다.

  • 앞의 경우처럼 A가 아닌 ::A라고 명시하려면 A는 그 전에 어떤 형태로든 global scope 어딘가에 선언이 돼 있어야 하더라. 그렇지 않으면 Visual C++이라도 에러가 난다.
  • A가 B와 동일한 namespace에 존재한다면 아무 문제 없다. B에서 friend class A만 해 준 뒤, A는 B의 앞에 있건 뒤에 있건 자유롭게 인식 가능하다.
  • A가 그냥 global scope에 있고 B와 동일한 namespace 소속이 아닌데 friend class A만으로 A가 인식되려면 A는 B보다 먼저 선언되어 있어야 한다. 안 그러면 B의 친구는 namespace에 소속돼 있는 가상의 A로 간주되고, ::A는 제외된다.

다시 말해 자신과 다른 namespace 소속의 클래스를 친구로 지목하려면 친구 대상을 반드시 먼저 선언해 주고 :: 연산자도 동원하는 등, 통상적인 friend에 비해 문법에 약간 제약이 걸린다는 걸 알 수 있다. Visual C++은 표준을 따르고 있는 건지는 잘 모르겠지만 그 과정에서 약간 더 유도리를 제공하고 있는 것 같다.

Posted by 사무엘

2019/01/10 08:37 2019/01/10 08:37
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1574

C++에는 using이라고.. class, namespace, template, virtual, operator 이런 것보다는 좀 생소하고 덜 쓰이는 키워드가 있다.
일반적인 프로그래머라면 타이핑 수고를 덜기 위해서 using namespace std; 정도 선언할 때나 사용했던 게 전부일 것이다.

얘는 C의 키워드로 치면 그나마 typedef와 성격이 얼추 비슷해 보인다. typedef는 여러 토큰으로 구성된 복잡한 타입 명칭을 한 단어(식별자) 한 토큰으로 축약해 준다.
타입 명칭이란 건 unsigned long처럼 예약어만으로도 두 단어 이상으로 구성될 수 있으며, 포인터형 *이라든가 const/volatile modifier 등이 붙어서 더욱 복잡해질 수 있다.

그러니 이런 걸 축약하는 기능은 단순히 토큰을 기계적으로 치환하는 #define 전처리기 계층이 아니라 컴파일러 계층에서 반드시 필요하다. 가령, PSTR a, b를 char *a, *b로 자동으로 인식되게 바꾸는 것은 #define만으로는 문법적으로 불가능하기 때문이다. 더구나 함수의 포인터 타입은.. 가리키는 함수가 받아들이는 인자들의 개수와 타입을 일일이 그런 식으로 나열해야 한다~!

C에서는 구조체형 변수를 선언할 때 반드시 struct를 일일이 붙여서 struct ABC 이런 식으로 선언해야 했다. struct를 생략하고 바로 ABC 한 단어만으로 쓰려면 이것조차도 typedef를 해 줘야 됐다.
그러니 C에서는 구조체를 typedef struct _ABC { ... } ABC; 이렇게 두벌일을 하면서 선언하는 게 관행이었으나..

C++에서는 객체지향 이념이 강화되면서 번거롭게 typedef를 안 해도 struct/class를 생략하고 곧바로 그 타입을 쓸 수 있게 됐다. 사실 이게 당연하고 더 자연스러운 조치가 아닌가 생각한다.

뭐 아무튼 typedef는 그런 중요한 역할을 하는 물건이다.
typedef를 통해 새로 만들어진 명칭은 사람이 보기에만 서로 다를 뿐, 컴파일러의 입장에서는 서로 완전히 동치이다. 전문 용어로 표현하자면 syntactic sugar이다.

내부적으로 담고 있는 물건은 동일하지만(똑같은 정수??) 서로 다른 타입으로 취급되어서 명시적인 형변환 없이는 서로 덥석 대입되지 않는 파생 타입.. 이런 걸 생성할 수 있으면 좋을 텐데 C/C++에서는 그게 쉽지 않다.
그러니 unsigned short/int와는 미묘하게 다른 wchar_t 같은 타입은 컴파일러가 언어 차원에서 직통으로 지원해 주지 않으면 사용자가 만들어 내기 난감하다.

그리고 HWND, HMODULE처럼 서로 호환되지 않는 다양한 핸들 타입도 내부적으로는 dummy 구조체의 포인터형을 일일이 typedef하는 편법을 동원해야 선언할 수 있다.
마치 include guard 삽질을 대체하기 위해 #pragma once가 사실상의 표준 형태로 등극한 것처럼.. 저것도 앞으로는 C++ 언어 차원에서 개선되어야 할 점이 아닌가 한다. 정수형에 대해서는 부분적이나마 type safety를 강화하려고 정수와 무작정 호환되지 않는 enum class 같은 것도 2010년대 들어서 도입된 바 있다.

아무튼, typedef는 통상적인 사유로 인해 길어진 type 명칭을 한데 줄이며, 축약된 명칭을 현재의 scope에다 도입해 준다.
그런데 using도 긴 명칭을 줄여 준다는 점에서는 역할이 비슷하다. 단지 그 배경이 typedef와는 완전히 다를 뿐이다.
바로, 지금 문맥과는 다른 namespace에 속한 명칭을 일일이 namespace를 명시하지 않고도 곧장 참조 가능하게 해 준다. 뭐, 개념은 그러하지만 구체적인 세부 문법과 용례는 생각보다 복잡하며, 본인 역시 이를 다 정확하게 알지는 못한다.

using은 크게 선언(declaration)과 지시(directive)라는 두 형태로 나뉘어서 문법적으로 서로 다르게 취급된다. 전자는..

using std::vector;

이런 식으로 구체적인 명칭을 써 주는 형태이다. 위의 경우 이 scope에서는 이제 앞에 std::를 안 붙여도 vector 클래스를 쓸 수 있게 된다. 사용되는 곳이 클래스의 내부라면 굳이 namespace 말고 기반 클래스 같은 타 클래스의 이름이 들어와도 된다.

std::vector를 vector로 줄여 쓰는 것은 기존의 #define이나 typedef로 가능하지 않다. 특히 typedef의 경우,

typedef std::vector<int> vector; //????

템플릿 인자가 모두 주어져서 온전한 type으로 실현된 놈이라면 저렇게 단축 명칭을 부여할 수 있겠지만, 그렇지 않은 추상적인 명칭을 축약하지는 못하기 때문이다. C++의 상속과 연계를 위해 dynamic_cast가 도입된 것처럼, C++에서 도입된 다단계 scope과의 연계를 위해 예전에는 없던 완전히 새로운 명칭 축약 기능이 필요해진 셈이다.

그리고 후자인 using 지시는.. using namespace라는 두 단어로 시작하여 이 namespace에 속하는 모든 명칭들을 곧장 자동 개방해 버린다.
선언이건 지시건 하는 일은 별 차이가 없다. 이것도 그냥 와일드카드에 속하는 ... 이나 * 를 써서 using std::...; 같은 선언으로 통합해 버려도 될 것 같은데, 미관상 보기 안 좋아서 그렇게 안 했나 보다.

물론 일부러 구분해 놓은 걸 당장 쓰기 편하다는 이유로 몽땅 개방해서 내 명칭과 뒤섞어 버리는 건 전역 변수, friend, public의 남발만큼이나 경계해야 할 일이다. 하지만 적절하게 활용하는 건 auto를 쓰는 것만큼이나 코드를 짧고 간결하게 만드는 약이 될 수도 있다.

C++ 표준 라이브러리의 경우 namespace가 도입되기 전 코드와의 호환을 지키기 위해 <iostream.h>는 std로 감싸져 있지 않고, <iostream>은 감싸져 있는 것으로 잘 알려져 있다. 물론 .h 버전은 앞으로 사용을 권하지 않는 deprecated로 철저히 봉인됐고 말이다.

요 두 가지가 using의 전통적인 기능이었다.
그런데 C++11 이후에는 using이 typedef의 기존 기능까지 흡수하여 본격적인 타입 alias 전담 키워드로 등극하기 시작했다. 바로, 등호를 이용해서

using P_INT = int*;
using PF_INT = int (*)();

위와 같이 써 주면 아래의 typedef와 완전히 동치가 된다.

typedef int* P_INT;
typedef int (*P_INT)();

굉장히 참신하다. 새 명칭과 치환 대상 타입이 =를 경계로 딱 분리되어 있다 보니 재래식 typedef보다 깔끔하고 알아보기도 더 쉽다.
using이라는 단어는 파스칼의 use 키워드와 비슷한 느낌이며, using A=B는 파스칼의 type A=B와 뭔가 닮은 것 같다. 또한 이 문법은 namespace에 대한 alias를 만드는 namespace A = B::C 같은 문법과도 일관성이 있다.

Visual C++에서는 한 2013쯤부터 지원되기 시작했다. 2010은 지원 안 하고, 2012는 인텔리센스 컴파일러는 지원하지만 본 컴파일러는 지원하지 않더라.
이름 없는 namespace를 선언해서 C의 static 전역 변수/함수를 표현하듯이, C++의 키워드를 이용해서 기존 C의 기능을 대체하는 예가 하나 더 생겼다. 최신 컴파일러에서는 using을 볼 일이 더 많아지겠다.

Posted by 사무엘

2018/12/15 08:32 2018/12/15 08:32
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1565

우리는 객체지향 프로그래밍 언어를 공부하면서 클래스 멤버들의 공개 등급이라는 개념을 접한다. 까놓고 말해 public, protected, private은 C++, C#, Java에 모두 공통으로 거의 동일한 용도로 쓰이는 키워드이다.

C++은 이런 공개 등급을 마치 case나 default처럼 뒤에다 콜론을 붙여 일종의 label 형태로 지정하지만, Java/C#은 멤버 함수 및 변수의 선언에 공개 등급이 같이 붙는다. 이 세 등급의 차이는 아래 표와 같다.

출처 \ 공개 등급 public protected private
외부 O X X
파생 클래스 내부 O O X
자기 클래스 내부 O O O

public이야 멤버의 접근에 아무 제약이 없는 등급이지만 pr*로 시작하는 나머지 두 등급은 그렇지 않다. 단지, protected는 파생 클래스의 내부에서 자기에게 접근을 허용하는 반면, private은 이마저도 허용하지 않는다. 상속 관계에서부터 둘의 차이가 발생하는 것이다. private은 사람으로 치면 자식에게도 물려주거나 공유하지 않는 개인 칫솔, 속옷, 복용하는 약 같은 급의 지극히 '사쩍'인 물건에다 비유할 수 있겠다.

물론 그 어떤 공개 등급이라도 자기가 선언해 놓고 자기 클래스의 멤버 함수에서도 사용하지 못하는 등급은 없다. 심지어 자기 자신 this뿐만 아니라 자기 클래스에 속하는 아무 객체라도 말이다.
즉, 아래의 코드에서 bar(함수)와 priv_member(변수)가 똑같이 Foo의 멤버라면, bar는 o라는 다른 인스턴스의 priv_member에도 저렇게 마음대로 접근할 수 있다.

void Foo::bar(Foo& o)
{
    priv_member += o.priv_member;
}

this 포인터가 아예 없는 static 멤버 함수도 있다는 점을 생각한다면 이는 당연한 귀결이라 하겠다. 선언은 자기가 했지만, 접근과 사용은 내가 곧장 못 하고 파생 클래스에서만 가능하다거나 하는 기괴한 개념은 없다.

오히려 반대로 부모 클래스에서는 공개였는데 파생 클래스에서는 부모의 멤버를 감추고, 외부에서는 오로지 파생 클래스가 새로 제공하는 public 멤버만 사용 가능하도록 클래스를 더 폐쇄적인 형태로 바꾸는 건 가능하다.

C++에서는 클래스를 상속할 때 별 생각 없이 파생 클래스의 이름 뒤에다 콜론을 찍고 public Base1, public Base2 이런 식으로 public을 붙이곤 한다. 이때 써 주는 공개 등급은.. 부모 클래스 멤버들의 공개 등급이 파생 클래스에서는 어떻게 되는지를 결정한다. 그 방식은 한편으로는 직관적이어 보이면서도 한편으로는 헷갈리고 어렵다.

상속 방식 \ 기존 공개 등급 public protected private
public public protected private
protected protected protected private
private private private private

public 상속은 부모 클래스 멤버들의 공개 등급을 파생 클래스에다가도 원래 지정되었던 형태 그대로 유지시킨다. 부모 때 public이었던 놈은 파생에서도 public, protected는 protected.. 그런 식이다.

그 반면, protected나 private 상속으로 가면 일단 부모 멤버들은 몽땅 private, 또는 잘해야 protected로 등급이 바뀐다. public 속성이 없어지기 때문에 외부에서 파생 클래스 객체를 대상으로 부모 클래스의 멤버에 접근은 할 수 없어진다. public, protected, private이라는 공개 등급을 각각 3, 2, 1이라는 수라고 생각한다면, 클래스를 상속하는 방식 N은 부모 멤버들의 공개 등급을 N보다 크지 않은 등급으로 재설정하는 셈이다.

다른 예로, 부모 클래스에서 protected였던 멤버가 있는데 자식이 부모를 private로 상속했다고 치자. 그러면 그 멤버는 부모에서의 공개 등급은 protected였기 때문에 자식 클래스의 내부에서 마음대로 접근이 가능하다. (참고로 public 멤버는 부모에서 public이었다 하더라도 non-public 상속을 거치면 파생 클래스에서의 외부 접근이 곧장 차단된다. 내부 접근과 외부 접근의 차단 시기가 서로 차이가 있다.)

하지만 private 상속된 protected 멤버는 파생 클래스에서의 등급이 private로 바뀌었다. 그렇기 때문에 얘로부터 상속받은 손자 클래스에서는 이 멤버에 더 접근할 수 없게 된다.
그리고 한번 private/protected 상속으로 인해 작아져 버린 공개 등급은 후속 파생 클래스가 다시 public으로 상속한다고 해서 다시 커지지 않는다. 상속 과정에서 기존 공개 등급을 동일하게 유지하거나 더 낮출 수는 있어도 도로 높일 수는 없다는 뜻이다.

부모 클래스에서 private 상태였던 멤버들은(처음부터 그리 됐든, 상속 방식 때문에 그리 됐든..) public 등 그 어떤 방식으로 상속을 받더라도 파생 클래스에서는 결코 접근할 수 없다. 위의 표에서 그냥 평범하게 private라고 명시된 놈은 현재 private이기 때문에 다음 파생 클래스에서는 감춰진다는 뜻이며, 취소선이 그어져 있는 private은 이미 접근 불가이고 파생 클래스의 입장에서는 그냥 없는 멤버가 됐음을 의미한다.

C++은 언어 차원에서 POD(단순 데이터 더미)와 객체(생성자 소멸자 가상 함수 등..)의 구분이 모호하다 보니, struct와 class의 언어적 구분도 없다시피한 것으로 잘 알려져 있다. 그냥 디폴트로 지정돼 있는 멤버의 공개 등급이 전자는 public이고 후자는 private이라는 차이만이 있을 뿐이다.

그것처럼, 클래스를 상속할 때 공개 등급을 안 쓰고 그냥 class Derived: Base {} 라고만 쓰면 Base는 private 방식으로 상속된다. C++의 세계에서는 디폴트 공개 등급이 어디서든 private인 셈이다.

class 대신 아예 struct Base { private: int a; } 이런 식으로 클래스를 선언해도 된다. 미관상 보기 좋지 않으니까 안 할 뿐이지.
얘는 클래스 선언 문맥에서는 struct라는 대체제가 있고, 템플릿 인자 문맥에서는 typename라는 대체제가 있으니 위상이 뭔가 애매해 보인다. 전자는 C 시절부터 있었던 키워드요, 후자는 C++98에서 추가된 키워드이다.

코딩을 하다 보면 범용적인 부모 클래스의 포인터로부터 자식 클래스로 static_cast 형변환을 하는 경우가 많다. 파생 클래스가 부모보다 멤버가 더 많고 할 수 있는 일도 더 많기 때문이다. 그런데 protected/private 상속을 한 파생 클래스는 자기만의 새로운 멤버/메소드가 있는 한편으로 부모에게 가능한 조작이 금지되어 버린다.

일반적으로 부모와 자식 클래스 관계는 is-a 관계라고 일컬어지고, 자식 포인터에서 부모 포인터로 형변환은 "당연히" 가능한 것으로 여겨지는데.. 그 당연한 건 public 상속일 때만으로 한정이다. 비공개 상속일 때는 정보 은닉을 제대로 보장하기 위해 자식에서 부모로 가는 게 허용되지 않으며, 심지어 static_cast로도 안 된다! Visual C++ 기준 C2243이라는 고유한 에러까지 난다.

기술적으로는, 객체 내부의 ABI 차원에서는 아무 위험할 것이 없음에도 불구하고 전적으로 객체지향 이념에 위배된다는 이유만으로 자식에서 부모로 못 간다. 무리해서 강제로 부모인 것처럼 취급하려면 reinterpret_cast라는 무리수를 동원해야 한다.

게다가 C++은 다중 상속(=가상 상속) 때문에 일이 더 크고 복잡해진다.

class A { public: int pub_mem; };

class B: virtual protected A {};

class C: virtual public A {};

class D: public B, private C {};

D o; o.pub_mem = 100;

위의 코드에서 저 멤버에다가 100을 대입하는 것은 가능할까?
이걸 판단하기 위해서는 컴파일러는 클래스 D의 가능한 상속 계통을 모두 순회하면서 최대 공개 등급(?)이 public이 되는지 따져 봐야 한다.
(참고로, 둘을 virtual로 상속하지 않았다면, 저 pub_mem이 B에 딸린 놈인지 C에 딸린 놈인지 알 수 없어서 모호하다고 어차피 컴파일 에러가 남..)

B는 A를 protected 상속했기 때문에 여기서 pub_mem이 protected가 되어 버려서 나가리. C는 A를 public으로 상속했지만, 최종 단계인 D에서 C를 private 상속해 버렸기 때문에 private가 된다.
요컨대 A에서 D까지 가는 동안 public이 계속 public으로 유지되는 상속 계통이 존재하지 않으며, 최대 공개 등급은 B 계열인 protected로 귀착된다. 그렇기 때문에 위의 구문은 컴파일 에러가 나게 되며, pub_mem은 D의 멤버 함수 내부에서나 건드릴 수 있다.

Visual C++의 경우, 가상 상속이 아닌 일반적인 상속 공개 등급 위반이라면 C2247 Not accessible because .. uses ... to inherit from 이라는 좀 단정적인 문구의 에러가 뜬다.
그러나 가상 상속 체계에서는 "접근 경로가 없다"라는 표현이 들어간 C2249 No accessible path to ... member declared in virtual base ... 에러가 난다. 공개 등급 체크를 위해서 더 복잡한 계산을 한 뒤에 판정된 에러이기 때문에 그렇다. 매우 흥미로운 차이점이다.

아무튼.. 참 복잡하기 그지없다.
그래서 C++ 이후의 언어들은 상속은 그냥 부모 멤버들의 공개 등급을 그대로 유지하는 public 상속만 생각하는 편이다. 다중 상속을 봉인해 버렸다는 건 더 말하면 입만 아플 것이고. C++이 객체지향 언어로서 여러 실험과 시행착오를 많이 했고 거기서 너무 무리수로 여겨지는 개념들이 후대의 언어에서는 짤렸다고 생각하면 되겠다.

Posted by 사무엘

2018/10/31 08:36 2018/10/31 08:36
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1549

1. rc 파일의 유니코드화

Visual C++ 2008까지만 해도 안 그랬던 것 같은데.. 2010쯤부터는 새로 만드는 프로젝트들의 리소스 스크립트(*.rc) 파일의 기본 인코딩이 유니코드(UTF-16LE)로 바뀌었다는 걸 본인은 최근에야 알아차렸다. 어쩐지 구버전에서는 파일을 열지를 못하더라.
그러니 이런 rc 파일의 내부에는 #pragma code_page(949) 같은 구차한 지시문도 없다.

리소스는 Windows의 실행 파일 포맷 차원에서 유니코드인데, 그걸 생성하는 스크립트 파일은 왜 유니코드가 아닌지 본인은 오랫동안 의아하게 생각해 왔다. 물론, 다국어 리소스는 언어별로 다 따로 만들지, 한 리소스 내부에 갖가지 외국어가 섞여 들어갈 일은 거의 없기 때문에 이런 방식이 크게 문제 되지 않았을 뿐이다.

리소스 파일 관련 속성을 보면.. MFC 모드로 동작할지 말지를 지정하는 옵션이 있다. 이건 rc 파일 내부에 저장되는 추가적인 옵션/플래그 같은 건 아니고, 그냥 Visual C++ IDE의 동작 방식을 결정하는 것이다. 프로젝트 내부의 설정으로 저장되는 것 같다.

이 옵션의 지정 여부에 따라 대표적으로 달라지는 것은 초기에 콤보박스 내부에다 집어넣을 데이터 목록을 지정하는 기능이다. 이것은 Windows API가 자동으로 해 주는 게 아니라, MFC가 추가적으로 구현해 놓은 기능이다. 그렇기 때문에 리소스 파일이 MFC mode로 지정돼 있지 않으면 해당 기능을 사용할 수 없다.

리소스 파일을 들여다 본 분은 아시겠지만 이 초기화 데이터는 Dialog 리소스 템플릿 안에 내장돼 있는 게 아니라, 240 (RC_DLGINIT)이라는 custom 리소스 타입에 따로 들어있다.
할 거면 리스트박스에다가도 같은 기능을 넣어 줄 것이지 왜 하필 콤보박스에다가만 넣었는지는 잘 모르겠다.

굳이 MFC를 사용하는 프로젝트가 아니더라도, Visual C++ 리소스 에디터가 저장해 놓은 대로 콤보박스를 초기화하는 기능을 내 프로그램에다가 넣고 싶으면 MFC의 소스 코드를 참고해서 직접 구현하면 된다.

그런데 리소스 스크립트 전체의 포맷은 유니코드로 바뀌었음에도 불구하고, 이 초기화 데이터는 기존 코드/프로그램과의 호환성 문제 때문에 여전히 CP_ACP이니 참 애석하다.
MFC 소스를 보면 문자열을 CB_ADDSTRING 메시지로 등록하는 부분에서 의도적으로 SendDlgItemMessageA라고 A 버전을 호출한 것을 볼 수 있다.

Windows는 여러 모로 UTF-8과는 친화적이지 않은 게 느껴진다. "UTF-8 + 32비트 wchar_t"를 전혀 찾아볼 수 없는 환경이다.

2. 소스 코드의 유니코드화, UTF-8 지원

앞서 언급한 바와 같이, Windows는 유니코드 계열이건 그렇지 않은 계열이건 2바이트(...) 단위의 문자 인코딩을 굉장히 좋아해서 전통적으로 UTF-8에 친화적이지 않았다. 친화도는 "UTF-16 > BOM 있는 UTF-8 > BOM 없는 UTF-8"의 순이다.

물론 Visual Studio의 경우, 먼 옛날의 200x대부터 소스 코드를 UTF-8 방식으로 불러들이고 저장하고, 파일 형식을 자동 감지하는 것 자체는 잘 지원한다. 하지만 한글 같은 게 전혀 없고 BOM도 없어서 일반 ANSI 인코딩과 아무 차이가 없는 파일의 경우 기본적으로 UTF-8이 아니라 ANSI 인코딩으로 간주하며, 디폴트 인코딩 자체를 UTF-8로 맞추는 기능은 기본적으로 제공되는 않는다는 점이 아쉽다.

다시 말해 새로 만드는 소스 코드라든가, 처음엔 한글이 없었다가 나중에 한글· 한자가 추가된 파일의 경우 실수로 여전히 cp949 같은 재래식 인코딩으로 파일이 저장될 여지가 있다는 것이다. 일일이 저장 옵션을 바꿔 줘야 된다.

Windows 환경에서 UTF-8 인코딩의 C++ 소스 코드는 (1) 주석을 다국어로 작성해서 온전히 보존 가능하고, (2) 동일 파일을 xcode 같은 타 OS에서도 깨지는 문자 없이 공유 가능하다는 것 정도에나 의미를 둬야 할 것이다.
L"" 문자열이 아니라 printf나 WM_SETTEXTA 같은 곳에 쓰이는 "" 문자열은 소스 코드의 인코딩이 무엇이냐에 따라 값 자체가 달라지기 때문이다.

Windows가 진정한 UTF-8 친화적인 환경이 되려면 시스템 코드 페이지 자체를 65001 UTF-8로 지정할 수 있고 명령 프롬프트에서도 그게 지원돼야 할 것이다. 하지만 UTF-8은 (1) 특정 로케일이나 언어에 속해 있지 않다는 점, 그리고 (2) 기존 multibyte 인코딩들과는 달리 한 글자가 3바이트 이상의 길이를 가질 수 있다는 점으로 인해 Windows는 이를 지원하지 않고 있었다. 그래도 요즘 마소가 워낙 파격적으로 변화하고 있고 Windows 10로 하루가 다르게 달라지고 있으니 이런 금기가 앞으로 깨지지 말라는 법도 없을 것 같다.

3. 디버그 로그의 유니코드화

Windows가 10이 나온 이래로 많이 바뀌긴 했다. 완전히 새로운 기능들만 추가되는 게 아니라, 이미 만들어졌고 앞으로 영원히 바뀌지 않을 것처럼 여겨지던 기능까지도 말이다.

가령, OutputDebugString 함수는 통상적인 다른 API 함수들과는 반대로, W가 내부적으로 A 버전을 호출하고 유니코드를 수십 년째 전혀 지원하지 않고 있었다. 이 때문에 굉장히 불편했는데.. 언제부턴가 Visual C++의 디버그 로그 출력창에 surrogate(확장 평면)까지 포함해 유니코드 문자열이 안 깨지고 온전히 찍혀 나오는 걸 보고 개인적으로 굉장히 놀랐다. 나중에 개선된 거라고 한다.

그리고 Windows의 에디트 컨트롤은 개행 문자를 오로지 \r\n밖에 지원하지 않기 때문에 메모장에서 유닉스(\n) 방식의 파일을 열면 텍스트가 개행 없이 한 줄에 몽땅 몰아서 출력되는 문제가 있었다.
그런데 이것도 Windows 10의 최신 업데이트에서는 개선되어서 \n도 제대로 표시 가능하게 되었다.
수백 KB~수 MB 이상 큰 파일을 여는 게 너무 오래 걸리던 고질적인 문제가 개선된 데 이어, 또 장족의 발전이 이뤄졌다.

Windows가 제공하는 유니코드 관련 API 중에는 주어진 텍스트가 유니코드 인코딩처럼 보이는지 판별하는 IsTextUnicode도 있고, 한자 간체-번체를 전환하는 LCMapString 같은 함수도 있다.
IsTextUnicode의 경우, 1바이트 아스키 알파벳 2개로만 이뤄진 아주 짧은 텍스트를 UTF-16 한자 하나로 오진(?)하는 문제가 있어서 내 기억이 맞다면 한 2000년대 Windows XP 시절에 버그 패치가 행해지기도 했다. 사실, 이런 휴리스틱은 정답이 딱 떨어지는 문제가 아니기도 하다.

저런 식으로 알고리즘이 일부 개정되는 경우가 있긴 했지만, Windows에서 데이터 기반으로 동작하는 유니코드 API들은 대개가 한 1990년대 말, 겨우 Windows NT4와 유니코드 2.0 정도나 있던 시절 이후로 그 데이터와 알고리즘이 업데이트 된 내역이 없다.

그래서 간체/번체를 변환하는 테이블에 등재된 한자는 내가 세어 본 기억에 맞다면 2300개 남짓밖에 되지 않으며, IsTextUnicode도 21세기 이후에 유니코드에 새로 추가된 수많은 글자들까지 고려하지는 않고 동작한다.
이 와중에 그래도 Windows 10에 와서 OutputDebugStringW가 제 구실을 하기 시작하고 메모장의 동작이 바뀌기도 한 것이 놀랍게 느껴진다.

한편, UTF-8은 그래도 첫 바이트로 등장할 만한 글자와 그 이후 바이트로 등장할 만한 글자가 형태적으로 무조건 정해져 있다. 그래서 데이터니 통계니 휴리스틱 없이도 자기가 UTF-8이라는 게 딱 티가 나며, UTF-8을 타 인코딩으로 오인한다거나 타 인코딩을 UTF-8로 오인할 가능성이 거의 없는 것이 매우 큰 장점이다.

4. 문자형의 부호 문제

컴퓨터에서 문자열의 각 문자를 구성하는 단위 타입으로는 전통적으로 char가 쓰여 왔다. 그러다가 유니코드가 등장하면서 이보다 공간이 더 커진 wchar_t가 도입되었으며, 언어 표준까지 채택됐다. 값을 다룰 때는 같은 크기의 정수와 다를 게 없지만, 포인터로는 서로 곧장 호환되지 않게 type-safety도 강화되었다.

그런데, 처음에 1바이트짜리 문자열의 기본 타입을 왜 괜히 부호 있는 정수형인 char로 잡았을까 하는 게 아쉬움으로 남는다. 물론 매번 unsigned를 붙이거나 typedef를 하는 건 귀찮은 일이며, 영미권에서는 문자 집합 크기가 7비트만으로도 충분했다는 그 상황은 이해한다. 하지만 문자 코드를 저장할 때는 애초에 부호 따위는 전혀 필요하지 않다. char보다 더 큰 wchar_t도 결코 부호 있는 정수형과 대응하지 않는다.

크기가 겨우 8비트밖에 안 되는 '바이트'는 양수 음수를 따지기에는 너무 작은 타입이기도 하다. 파일이나 메모리 데이터를 바이트 단위로 읽으면서 2의 보수 기반의 부호를 따질 일이 과연 있던가..?

이런 구조로 인해.. UTF-8이건 -16이건 -32이건 모두 대응 가능한 문자열 템플릿을 만들 때, char형에 대해서만 코드값 범위 검사를 할 때 예외를 둬야 하는 불편한 상황도 생긴다. 템플릿 인자로 주어진 어떤 타입에 대해서, 크기는 동일하면서 부호만 없는 타입을 자동으로 되돌리는 방법이 C++ 언어에는 존재하지 않기 때문이다.

그러니 다른 타입에서는 다 간단하게 >= 0x80을 검사하면 되는데, char만 <0을 봐야 한다. 이런 거 로직이 꼬이면 모든 타입에서 0xF0이 저장되어야 하는데 딴 타입에서는 0xFFF0이 저장되는 식의 문제도 생길 수 있다. 그렇다고 임의로 제일 큰 부호 없는 정수형으로 typecast를 하는 건 무식한 짓이다.

회사에서 일을 하다가 하루는 이게 너무 짜증 나서 std::basic_string<unsigned char>로부터 상속받은 클래스를 새로 만들어 버렸다. 베이스 클래스의 명칭이 딱 한 토큰 한 단어가 아니라 저렇게 템플릿 인자가 덕지덕지 붙은 형태인 게 특이했다만.. 생성자 함수에서 기반 클래스를 호출할 때는 __super를 쓰지도 못하더라.

내부적으로는 모든 처리를 unsigned char를 기준으로 하는데, 생성자와 덧셈 연산, 형변환 연산에서만 부호 있는 const char*를 추가로 지원하는 놈을 구현하는 게 목적이었다. 이런 생각을 나만 한 건 절대 아닐 텐데..
개인적으로 + 연산자를 만드는 부분에서 좀 헤맸었다. 얘는 +=와 달리 완전한 내 객체를 새로 만들어서 되돌리는 것이기 때문에 컴파일러 에러를 피해서 제대로 구현하는 게 생각보다 nasty했다. 그렇다고 도저히 못 할 정도는 아니었고.. 뭐 그랬다.

그러고 보니 Java는 기본적으로 부호 있는 정수형만 제공하지만, char만은 문자 저장용으로 부호 없는 16비트 정수를 쓰는 걸로 본인은 알고 있다.
그런데 얘도 그 크기로는 BMP 영역 밖은 표현할 수 없다. Java 언어가 처음으로 설계되고 만들어지던 때는 1990년대 중반으로, 아직 유니코드 2.0과 확장 평면 같은 개념이 도입되기 전이었다.
결국 범용적인 글자 하나를 나타내려면 부호 있는 정수인 int를 써야 한다. 상황이 좀 복잡하다..;;

5. Windows 문자열 변환 함수의 함정

Windows API 중에서 WideCharToMultiByte와 MultiByteToWideChar는 운영체제가 내부적으로 사용하는 2바이트 단위 UTF-16 방식의 문자열과 타 인코딩 문자열(UTF-8, CP949 등..)을 서로 변환하는 고전적인 함수이다.

이 두 함수는 크게 두 가지 모드로 동작한다. (1) 사용자가 넘겨준 문자열 버퍼 포인터에다가 변환을 수행하거나.. (2) 아니면 그렇게 write 동작을 하지는 않고, 이 원본 문자열을 몽땅 변환하는 데 필요한 버퍼의 크기만을 되돌린다.
일단 (1)처럼 동작하기 시작했는데 사용자가 넘겨준 버퍼 크기가 원본 문자열을 모두 변환해 넣기에 충분하지 못하다면 함수의 실행은 실패하고 0이 돌아온다.

이때도 기존 버퍼의 크기만치 변환을 하다가 만 결과는 확인할 수 있다. 하지만 원본 문자열의 어느 지점까지 변환하다가 끊겼는지를 이 함수가 알려 주지는 않는다. 그렇기 때문에 그 정보를 유의미하게 활용하기 어려우며, 이는 개인적으로 아쉽게 생각하는 점이다.

그러니 버퍼가 얼마나 필요한지 알 수 없는 일반적인 경우라면, WideCharToMultiByte를 기준으로 함수를 사용하는 방식은 이런 형태가 된다. 함수를 두 번 호출하게 된다.

const wchar *pSrcBuf = L"....";
int len = WideCharToMultiByte(CP_***, pSrcBuf, -1, NULL, 0, ...); //(2) 크기 측정
char *pTgtBuf = new char[len];
WideCharToMultiByte(CP_***, pSrcBuf, -1, pTgtBuf, len, ...); //(1) 실제로 변환
...
delete []pTgtBuf;

그런데, 이들 함수가 (1)과 (2) 중 어느 모드로 동작할지 결정하는 기준은 버퍼 포인터(pTgtBuf)가 아니라, 버퍼의 크기(len)이다.
보통은 크기를 측정할 때 포인터도 NULL로 주고 크기도 0으로 주니, 함수가 내부적으로 둘 중에 뭘 기준으로 동작하든 크게 문제될 건 없다.

하지만 한 버퍼에다가 여러 문자열을 변환한 결과를 취합한다거나 해서 포인터는 NULL이 아닌데 남은 크기가 우연히도 딱 0이 될 수 있는 상황이라면 주의해야 한다. 포인터와 버퍼 크기가 pTgtBuf + pos, ARRAYSIZE(pTgtBuf) - pos 이런 식으로 정해진다거나 할 때 말이다.

저 식에서 pos가 우연히도 배열의 끝에 도달했다면, 남은 크기가 0이니까 프로그래머가 의도하는 건 이 함수의 실행이 무조건 실패하고 0이 돌아오는 것이다. 그럼 프로그램은 버퍼 공간이 부족해졌다는 걸 인지하여 지금까지 쌓인 버퍼 내용을 딴 데로 flush한 뒤, 변환을 재시도하면 된다.

하지만 이 함수는 프로그래머가 의도한 것처럼 동작하지 않는다. 문자열 변환을 하지 않지만, 마치 실행에 성공한 것처럼 변환에 필요한 버퍼 크기를 되돌린다. 쉽게 말해 "(1)에 대한 실패"가 아니라 "(2)에 대한 성공"으로 처리된다는 것이다.

이 문제를 피하려면, 버퍼를 관리하는 프로그램은 WideChar...함수가 실패했을 때뿐만 아니라 포인터가 버퍼의 끝에 도달했는지의 여부도 따로 체크해야 하며, 그 경우 버퍼를 flush해 줘야 한다. 변환 함수가 후자까지 같이 체크해 주지 않기 때문이다.
날개셋 편집기가 9.5의 이전 버전에, 바로 이것 때문에 대용량 파일을 저장할 때 낮은 확률로 데이터를 날려먹는 버그가 있었다.

Windows API가 입력값이 0일 때에 대해 일관된 유도리가 없어서 불편한 예가 GDI 함수에도 있다.
주어진 문자열의 픽셀 단위 길이와 높이를 구하는 GetTextExtentPoint32의 경우, 문자열 길이에다 0을 주면 가로는 0이고 세로 크기만 좀 구해 줬으면 좋겠는데.. 그러질 않고 그냥 실행이 실패해 버린다.
높이만 구하고 싶으면, 공백 하나라도 dummy로 전해 준 뒤 리턴값의 cx 부분은 무시하고 cy를 사용해야 한다.

Posted by 사무엘

2018/09/29 08:35 2018/09/29 08:35
, ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1537

1. R-value 임시 객체를 일반 참조자 형태로 함수 인자로 전달하기

C/C++ 프로그래밍 요소 중에는 잘 알다시피 & 연산자를 이용해서 주소를 추출할 수 있으며 값 대입이 가능한 L-value라는 게 있고, 그렇지 않고 값 자체만을 나타내는 R-value라는 게 있다.
C언어 시절에는 R-value라는 게 함수의 리턴값이 아니면 프로그램 소스 코드 차원에서 리터럴 형태로 하드코딩되는 숫자· 문자열밖에 없었다. 하지만 C++로 와서는 생성자와 소멸자가 호출되는 클래스에 대한 임시 인스턴스 개체도 그런 범주에 속할 수 있게 되었다.

다른 변수에 딱히 대입되지 않은 함수의 리턴값 내지, 변수로 선언되지 않고 함수의 인자에다가 곧장 Class_name(constructor_arg) 이런 형태로 명시해 준 객체 선언은 모두 R-value이다.

R-value를 그 타입에 대한 포인터형으로 함수 인자로 전달하는 것이야 가능하지 않다. 주소를 얻을 수 없으니 말이다. C/C++에 &100 이런 문법 같은 건 존재하지 않는다.
하지만 참조자는 외형상 값으로 전달하는 것과 동일하기 때문에 저런 제약이 없다. 그런데 참조자가 내부적으로 하는 일은 포인터와 완전히 동일하다. 그럼 뭔가 모순/딜레마가 발생하지 않을까?

이런 오류를 막기 위해, R-value를 일반 참조자형으로 전달하는 것은 원래 금지되어 있다. 참조자 내지 포인터는 자신이 가리키는 대상이 당연히 대입 가능한 L-value라는 것을 전제로 깔기 때문이다.
임시 개체를 함수 인자로 전하려면..

  • 그냥 값으로 전달해야 한다. 이 방법은 객체의 크기가 크거나 복사 생성자에서 하는 일이 많다면, 성능 오버헤드가 우려된다.
  • 아니면 const 참조자형으로 전달해야 한다. R-value는 대입이고 변경이고 불가능한 놈이니 const 제약을 줘서 취급하는 것이 이치에 맞다.
  • 아니면 얘는 임시 R-value이지만 값이 보존되지 않아도 아무 상관 없다는 표식이 붙은, C++11의 R-value 참조자 &&를 써서 전달하면 된다.

사실, 정수 같은 아주 작고 간단한 타입이라면 모를까, 커다란 객체는 임시 객체라 해도 어차피 자신만의 주소를 갖고 있는 것이나 다름없다.
그래서 그런지 Visual C++은 200x 언제부턴가 R-value를 통째로 일반 참조자로 전달하는 것을 허용하기 시작했다. xcode에서는 에러가 나지만 Visual C++은 컴파일 된다. 이렇게 해 주는 게 특히 템플릿을 많이 쓸 때 더 편하긴 하다. VC++도 내 기억으로 6.0 시절에는 안 이랬다.

사실, 이걸 허용하나 안 하나.. &로 전달하나 &&로 전달하나 컴파일러 입장에서는 크게 달라지는 게 없다. 템플릿 인자로 들어간 타입이 객체가 아니라 정수라면 좀 문제가 되겠지만 어차피 C++은 서로 다른 템플릿 인자에 대해서 같은 템플릿을 매번 새로 컴파일 하면서 코드 생성과 최적화를 매번 새로 하는 불편한(?) 언어이다. 그러니 각 상황별로 따로 처리해 주면 된다.
물론 R-value 참조자가 C++에 좀 일찍 도입됐다면 Visual C++이 저런 편법을 구현하지 않아도 됐을 것 같아 보인다.

2. C++에서 함수 선언에다 리턴 타입 생략하기

엄청 옛날 유물 얘기이긴 하지만.. Visual C++이 2003 버전까지는 아래 코드가 컴파일이 됐었다는 걸 우연한 계기로 뒤늦게 알게 됐다. 바로 함수를 선언· 정의할 때 리턴 타입을 생략하는 것 말이다.

class foo {
public:
    bar(int x); //생성자나 소멸자가 아닌데 클래스 멤버 함수의 리턴 타입을 생략!! 여기서는 경고는 뜸
};

foo::bar(int x) //여기서도 생략했지만 그래도 int로 자동 간주됨
{
    return x*x;
}

main() { return 0; }

C++은 본격적인 클래스 다루는 거 말고 일상적인 코딩 분야에서 C와 달라지는 차이점이 몇 가지 있다. 그 차이점은 대부분 C보다 type-safety가 더 강화되고 엄격해진다는 것이다.

  • 임의의 type의 포인터에다가 void*를 대입하려면 형변환 연산자 필수. (경고이던 것이 에러로)
  • 함수도 prototype을 반드시 미리 선언해 놓고 사용해야 함. (경고이던 것이 에러로)
  • 그리고 함수의 선언이나 정의에서 리턴 타입을 생략할 수 없음. 한편, 인자 목록에서 ()은 그냥 임의의 함수가 아니라 인자가 아무것도 없는 함수, 즉 void 단독과 동치로 딱 정립됨.
  • 그 대신 C++은 지역 변수(+객체)를 굳이 {} 블록의 앞부분이 아니라 실행문 뒤에 아무 데서나 선언해도 된다.

이 개념이 어릴 적부터 머리에 완전히 박혀 있었는데, VC6도 아니고 2003의 컴파일러에는 C의 잔재가 아직 저렇게 남아 있었구나. 몰랐다.
cpp 소스에다가도 int main()대신 main()이라고 함수를 만들어도 되고, 심지어 클래스의 멤버 함수에다가도 리턴 타입을 생략할 수 있었다니... 완전 적응 안 된다.

물론 익명 함수(일명 람다)를 선언할 때는 꼭 리턴값 타입을 안 써 줘도 된다. void나 int 같은 간단한 것은 함수 내부의 return문을 통해서 컴파일러가 그럭저럭 유추해 주기 때문이다.
함수형이라는 완전히 다르고 새로운 패러다임이 C++에 한참 뒤에 추가되다 보니 일관성이 깨졌다면 깨진 듯이 보인다.

3. C/C++ 컴파일러 및 언어 문법 자체의 변화

내 경험상, 지난 2000년대에는 Visual C++ 컴파일러의 버전이 올라가면서 명칭의 scope 인식이 좀 더 유연해지곤 했다.
가령, 클래스 A의 내부에 선언된 구조체 B를 인자로 받는 멤버 함수 C의 경우, C의 몸체를 외부에다 정의할 때 프로토타입 부분에서 B를 꼭 A::B라고 써 줘야 됐지만, VC6 이후 버전부터는 그냥 B라고만 써도 되게 됐다.

람다가 최초로 지원되기 시작한 미래의 VC++ 2010에도 비슷한 한계가 있었다.
클래스 멤버 함수 내부에서 선언된 람다 안에서는 그 클래스가 자체적으로 정의해 놓은 타입이나 enum값에 곧장 접근이 안 됐다. A::value 이런 식으로 써 줘야 했는데.. 2012와 그 후대 버전부터는 곧바로 value라고만 써도 되게 바뀌었다. 2012부터 람다가 함수 포인터로 cast도 가능해졌고 말이다.

내 기억이 맞다면 템플릿 인자가 공급된 템플릿 함수가 함수 포인터로 곧장 연결되는 게 VC++ 2003쯤부터 가능해졌다. 상식적으로 당연히 가능해야 할 것 같지만 VC6 시절에는 가능하지 않았었다.
2000년대가 generic이라면 2010년대는 functional 프로그래밍이 도입된 셈이다.

아.. 또 무슨 얘기를 더 할 수 있을까?
C는 옛날에, 원래 처음에 1980년대까지는 K&R 문법인지 뭔지 해서 함수의 인자들의 타입을 다음과 같이 지정할 수도 있었다고 한다.

int foo(a, b) int a; float b; { return 0; }

같은 명칭을 이중으로 명시하고 체크하느라 괜히 분량 길어지고 파싱이 힘들어지고..
무슨 Ada나 Objective C처럼 함수를 호출할 때 foo(b=20, a=1)처럼 인자들 자체의 명칭을 지정하는 것도 아닌데..
저 문법이 도대체 무슨 의미가 있고 왜 저런 게 존재했는지 나로서는 좀 이해가 안 된다. C는 파이썬 같은 dynamic 타입 언어도 전혀 아닌데 말이다.

C 말고 C++도 1980년대까지는 문법이나 라이브러리가 제대로 표준화되지도 않았었고, 지금으로서는 상상하기 어려운 관행이 많았다고 한다. 유명한 예로는 소멸자가 존재하는 클래스 객체들의 배열을 delete 연산자로 제거할 때는 원소 개수를 수동으로 공급해 줘야 했다거나, static 멤버를 선언한 뒤에 굳이 몸체를 또 정의할 필요가 없었다거나 하는 것 말이다.

사실, 후자의 경우 또 정의할 필요가 없는 게 더 직관적이고 프로그래머의 입장에서 편하긴 하지만.. 컴파일러와 링커의 입장에서는 생성자 함수를 호출하는 실행문이 추가되는 부분이 따로 들어가는 게 직관적이니 불가피하게 생긴 변화이긴 하다.
이런 저런 변화가 많은데 C++은 표준화 이전의 격변의 초창기 시절에 대한 자료를 구하기가 어려워 보인다.

객체를 생성하는데 메모리 주소는 정해져 있고 거기에다 생성자 함수만 호출해 주고 싶을 때..
지금이야 placement new라는 연산자가 라이브러리의 일부 겸 사실상 언어의 일부 요소로 정착해서 new(ptr) C라고 쓰면 되지만, 옛날에는 ptr->C::C() 이런 표기가 유행이었다. . ->를 이용해서 생성자와 소멸자 함수를 직접 호출하는 건 지금도 금지되어 있지는 않지만.. 사용이 권장되는 형태는 아닌 듯하다.

4. macOS와 Windows의 관점 차이

macOS의 GUI API(Cocoa)와 Windows의 GUI API는 뭐 뿌리나 설계 철학에서 같은 구석을 찾을 수 없을 정도로 완전히 다르다.
좌표를 지정하는데 화면이 수학 좌표계처럼 y축이 값이 커질수록 위로 올라가며, NSRect는 Windows의 RECT와 달리 한쪽이 절대좌표가 아니라 상대좌표이다. 즉, 두 개의 POINT로 구성된 게 아니라 POINT와 SIZE로 구성된 셈이다.

또한 Windows의 사고방식으로는 도저히 상상할 수 없는 float 부동소수점을 남발하며, 처음부터 픽셀이라는 개념은 잊고 추상적인 좌표계를 쓴다. 얘들은 이 정도로 장치· 해상도 독립적으로 시스템을 설계했으니 high DPI 지원도 Windows보다 더 유연하게 할 수 있었겠다는 생각이 들었다.

그리고 대화상자나 메뉴 같은 리소스를 관리하는 방식도 둘은 서로 다르다.
Windows는 철저하게 volatile하다. 이런 것은 생성되는 시점에서 매번 리소스로부터 처음부터 load와 copy, 초기화 작업이 반복되며, 사용자가 해당 창을 닫은 순간 메모리에서 완전히 사라진다.

그 반면, 맥은 그런 것들이 사용자가 닫은 뒤에도 이전 상태가 계속 남아 있다.
내가 뭔가 설정을 잘못 건드렸는지는 모르겠지만, Windows로 치면 [X]에 해당하는 닫기 버튼을 눌러서 대화상자를 닫았는데도 호락호락 창이 사라지지 않고 DestroyWindow보다는 ShowWindow(SW_HIDE)가 된 듯한 느낌? 대화상자의 이전 상태가 계속 살아 있는 것 같다.

특히 메뉴의 경우 Windows는 내부 상태가 완전히 일회용이다. 메뉴가 화면에 짠 표시될 때가 되면(우클릭, Alt+단축키 등) 매번 리소스로부터 데이터가 로딩된 뒤, 체크 또는 흐리게 같은 다이나믹한 속성은 그때 그때 새로 부여된다.
그 반면 mac에서는 메뉴가 화면에 표시되지 않을 때에도 내부 상태가 쭉 관리되고 있는 게 무척 신기했다.

그러니 개발자는 시간과 여유만 된다면 프로그래밍 언어와 환경을 많이 알면 사고의 범위가 넓어질 수 있고 각각의 환경을 설계한 사람의 관점과 심정을 이해할 수도 있다.
하지만 뒤집어 말하면 프로그래머는 은퇴하는 마지막 순간까지도 공부하고 뒤따라가야 할 게 너무 많다.. -_-;; 이거 하나 적응했다 싶으면 그새 또 다른 새로운 게 튀어나와서 그거 스펙을 또 공부해야 된다.

Posted by 사무엘

2018/09/08 08:37 2018/09/08 08:37
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1530

코딩을 하다 보면 한 자료형(타입)에 속하는 값 내지 개체를 다른 타입으로 변환해야 할 때가 있다. 아주 직관적이거나(C에서 정수와 enum), 작은 타입에서 큰 타입으로 가기 때문에 정보 손실 염려가 없는 상황에 대해서는 해당 언어의 문법 차원에서 대입이나 함수 인자 전달이 곧장 허용되곤 한다. 바이트 수가 대등하더라도 signed보다는 unsigned가 더 큰 타입이고, 정수보다 실수가 더 큰 타입으로 여겨진다.

그렇지 않고 정보 소실의 여지가 있거나 서로 호환되지 않는 타입에다 값을 집어넣는 건 컴파일러의 경고나 에러를 유발한다. 이 상황에 대비하여 프로그래밍 언어들은 여러 형변환 함수들을 제공하는데, 씨크하게 괄호 안에다가 타입 이름만 달랑 쓰면 형변환 연산자로 인식되는 C/C++이 여기서도 참 유별난 면모를 보이는 것 같다.

형변환이란 건 값의 초기 타입과 목적 타입이 무엇이냐에 따라 내부에서 벌어지는 일이 매우 다양한 편이다.

(a) 없음: LPARAM에서 void*, void*에서 char* 같은 무식한 형변환은 소스 코드상의 의미만 매우 과격하게 바뀔 뿐, 내부적으로 행해지는 일은 전무하다! (클래스 상속 관계를 신경쓸 필요 없는 간단한 것 한정으로)

(b) 그냥 뒷부분 짜르거나 늘리기: int와 char 사이의 변환

(c) 정수와 실수 사이를 변환: 내부적으로 일어나는 일이 분명 간단하지는 않지만, 요즘은 이런 건 CPU 명령 한 줄이면 바로 끝난다. x86 기준으로 cvtsi2sd이나 cvttsd2si 같은 인스트럭션이 있다.

(d) 고정된 오프셋 보정: 단순한 형태의 다중 상속에서 제n의 부모 클래스 포인터를 얻으려면 이런 보정이 필요하다.

(e) 함수 호출: 해당 클래스에다 사용자가 구현해 놓은 operator 함수가 호출된다. 사실, 100과 "100"처럼 숫자와 문자열 사이의 변환도 컴퓨터의 관점에서 보면 이 정도의 cost가 필요한 작업이다.

(f) 상속 계층 관계 그래프 순회: 이건 객체지향 이념 때문에 형변환 연산이 언어 차원에서 가장 복잡해지는 상황이다. 위의 1~5와는 근본적으로 차원이 다르다. 가상 상속 체계에서 부모 클래스를 찾아가거나 dynamic_cast 형변환을 하려면 자기의 타입 정보 metadata를 토대로 주변 클래스 계층 그래프를 O(n) 시간 동안 순회해야 한다(n은 상속 단계).
사용자의 코드가 아닌 컴파일러의 코드만 실행됨에도 불구하고 런타임 가변적인 반복이 발생할 수 있으며, 객체와 메모리 상태가 어떤지에 따라서 형변환 결과가 dynamic하게 달라질 수 있다!

내부적으로 벌어지는 일은 대략 저렇게 분류 가능하고, 겉으로 소스 코드의 의미 차원에서도 형변환의 성격을 몇 가지로 분류할 수 있다.
처음에 C++에는 그냥 C-style cast밖에 존재하지 않았다. 그런데 그랬더니 형변환 연산이 발생하는 부분만 검색으로 뽑아내는 게 어려웠고, 또 단순한 형변환과 좀 위험한 형변환 같은 걸 따져 보기도 어려웠다. 표현 형태가 괄호와 타입 이름이 전부이니까..

그래서 1996~97년경, C++98의 발표를 앞두고 C++에는 길고 굉장히 기괴해 보이지만 용도별로 세분화된 형변환 연산자가 4종류나 추가되었다. namespace, bool, explicit, mutable 이런 키워드들과 같은 타이밍에 도입되었다. C++이 숫자는 몽땅 machine-word int로 어영부영 때우려던 C스러운 사고방식을 탈피하고, 예전에 비해 나름 type-safety를 따지기 시작한 그 타이밍이다. (예: C와 C++에서 sizeof('a')의 값의 차이는?)

새 연산자들은 모두 *_cast로 끝난다. 옛날의 재래식 형변환은 (NEWTYPE)value라고 썼고 C++ 문법으로는 NEWTYPE(value)도 허용되는 형태였다(NEWTYPE이 딱 한 단어 토큰으로 떨어지는 경우에 한해서).
그에 비해 새 연산자들은 *_cast<NEWTYPE>(value)라고 쓰면 된다. < > 안에다가 타입 이름을 쓰는 것은 템플릿 인자 문법에서 유래되었는데 나름 직관적이고 적절한 활용 같다.

1. static_cast

얘는 일상적으로 가볍고 큰 무리 없이 일어나는 일반적인 형변환을 거의 다 커버한다. (1) 큰 타입에서 작은 타입으로(실수에서 정수, UINT에서 int, long long에서 int 등..), 그리고 (2) 범용적인 타입의 포인터에서 더 구체적인 타입의 포인터로(void*에서 타 포인터, 기반 클래스*에서 파생 클래스 포인터) 말이다. 이게 대부분이다.

그리고 형변환 operator 호출이라든가, 다중· 가상 상속으로 인한 포인터 보정도 언어에서 보장돼 있는 메커니즘이므로 알아서 처리해 준다. 정말 대부분의 상황에서 앞서 나열했던 (a)에서 (f)까지, C-style cast를 대체할 수 있는 무난한 연산자이다. 단, f에서 typeid와 RTTI까지 동원되는 제일 비싸고 난해한 기능은 없으며, 이건 나중에 설명할 dynamic_cast가 전담하는 영역이다.

2. const_cast

얘는 값이 아니라 포인터/참조자형에서 C/C++ 특유의 한정자(qualifier) 속성만을 제거해서 더 범용적인 포인터로 만들어 준다. 그러므로 용도가 아주 제한적인 형변환 연산자이다.
C++에서 공식적으로 제공되는 qualifer는 const와 volatile이 있다. 이런 한정자는 가리키는 대상 타입과는 아무 상관 없고, 포인터를 이용해 그 메모리를 접근하는 방식 차원에서 제약을 부여할 뿐이다. 전자는 읽기 전용 속성이고, 후자는 멀티스레드에 의해 값이 언제든 바뀔 수 있음을 대비하라는 최적화 힌트이다.

Visual C++에는 __unaligned라는 확장 키워드도 저것들과 동급인 한정자이다. 이 포인터는 machine word 단위의 align이 맞춰지지 않은 주소가 들어올 수도 있으니 그렇더라도 뻗지 말고 보정하라는 뜻이다(성능 오버헤드 감수하고라도). align 보정을 알아서 너무 잘 해 주고 있는 x86 계열은 전혀 해당사항이 없고, 과거에 IA64를 지원하던 시절에 필요했던 키워드이다. 이것도 포인터 한정자 속성으로서는 굉장히 적절한 예이며, 이런 속성들을 const_cast로 제거할 수 있다.

3. reinterpret_cast

이건 의미론적으로는 제일 무식하고 생뚱맞고 위험하지만 내부 처리는 제일 할 것 없는 형변환 전문이다. (1) 정수와 포인터 사이를 전환하는 것, 그리고 (2) 서로 관련이 없는 타입을 가리키는 포인터끼리 전환하는 것.. 어디 범용적인 함수나 메시지로부터 아주 polymorphic한 데이터를 전달받아서 처리할 때에나 불가피하게 쓰일 법하다.

void*를 char*로 바꾸는 건 static_*으로도 되고 reinterpret_*으로도 된다. 하지만 const char*를 char*로 바꾸는 것은 static_*나 심지어 reinterpret_*로도 안 되고 반드시 const_*로만 해야 한다.
그런데 그래 봤자 reinterpret_*과 const_*는 어떤 경우에도 실질적인 내부 처리는 (a)뿐인(= 없음).. 참 허무한 연산자이다. 실질적인 처리가 없지만 이 숫자값을 해석하는 방식을 변경하는 이유는 분야별로 여럿 존재할 수 있다는 뜻이다.

재래식 C-style cast는 따지고 보면 1~3을 그냥 싸잡아서 구분 없이 수행해 준다. 그런데 가끔 드물게 다중· 가상 상속 관계의 타입 포인터끼리 형변환을 할 때 정석대로 보정 연산을 거친 포인터를 원하는지(static_*), 아니면 이것도 아무 보정 없이 동일한 메모리 주소에서 타입만 바꿔서 해석하고 싶은지(reinterpret_*) 모호해질 때가 있다.

이런 문제도 있고, 또 C++에다가 좀 제대로 된 객체지향 언어의 기능을 뒤늦게 갖추려다 보니 새로운 형변환 메커니즘이 필요해졌다. 이쯤 되니까 형변환 연산자도 별도의 예약어로 도입해서 구분하지 않고서는 도저히 버틸 수 없는 지경이 됐다. 그럼 다음으로 제일 괴물인 형변환 연산자에 대해서 살펴보도록 하자.

4. dynamic_cast

가상 함수를 쓰면 기반 클래스의 포인터를 주더라도 자신이 실제로 속한 파생 클래스에 해당하는 멤버 함수가 알아서 호출된다.
그리고 다중 상속 때 가상 상속을 쓰면, 여러 부모 클래스들이 동일한 조부모 클래스로부터 상속받았을 때 공통 조부모가 한 번만 상속되는 마술(?)이 일어난다. 물론 객체지향 언어에서 유연한 코드 재사용성을 보장하는 모든 마술에는 그에 상응하는 성능 오버헤드가 대가로 따른다는 점은 감안할 필요가 있다.

그런데 과거의 C++은 상속과 함수 호출에서 이렇게 언어 차원의 동적 바인딩이 지원되는 것과 대조적으로, 형변환에는 "동적 바인딩 + 무결성"을 보장하는 메커니즘이 딱히 없었다. 이놈이 A의 파생 클래스이긴 하지만 더 구체적으로 A의 자식들 중에 B가 아닌 C의 파생 클래스가 진짜로 맞는지, 이 멤버에 접근하고 이 함수를 호출해도 안전하겠는지 말이다.

C++은 void*가 있을지언정, 언어 차원에서 모든 클래스들의 공통 클래스(Java의 Object 같은)라는 개념이 없다. 그리고 클래스 내부의 vbtl에 직접 접근한다거나, 가상 함수의 포인터 값을 보고 클래스 종류를 판별할 수 있을 정도로 C++이 ABI가 몽땅 왕창 노출돼 있느냐 하면 그렇지도 않다(겉에는 공통의 썽킹 함수의 주소만 노출돼 있기 때문). 뭔가 어정쩡하다.

그러니 MFC 같은 옛날 라이브러리들은 자체적으로 CRuntimeClass 같은 타입 메타정보를 구비하고, 이놈이 CObject의 파생이긴 하지만 특정 클래스의 파생형이 정말 맞는지 런타임 때 확인하는 함수를 자체적으로 구현해야 했다.
C++이 아무리 C의 저수준 고성능 제어 이념을 계승했다 해도 명색이 객체지향 언어인데 그런 기능조차 없는 건 좀 아니라 여겨졌는지, 훗날 언어 차원에서 타입 식별 정보와 전용 형변환 연산자가 도입됐다. 그 결과물이 바로 dynamic_cast이다.

함수도 virtual, 상속도 virtual인 걸 감안하면 얘의 이름은 기술적으로 virtual_cast라 해도 과언이 아닐 듯하다. 하지만 static_* 이라는 단어가 이미 있으니 그것보다 더 값비싼 형변환이라는 의미로 dynamic_*이라는 이름이 최종적으로 붙었다. static_*은 이놈이 진짜 조상 관계가 맞는지 확인하지 않고 그냥 O(1) 복잡도짜리 기계적인 오프셋 보정만 해서(필요한 경우) 파생 클래스로 형변환해 주는 반면, dynamic_*은 타입 식별자를 직접 확인까지 한다는 것이다.

가상 함수의 구현을 위해서는 함수 포인터 테이블과 테이블의 포인터(멤버)가 필요하고, 가상 상속의 구현을 위해서는 기반 클래스의 포인터(멤버)가 필요하다. 그것처럼 동적 바인딩 형변환을 구현하려면 클래스 이름과 계층 관계를 기술하는 메타데이터와 함께 그놈의 포인터(멤버)가 필요하다.

가상 함수와 가상 상속 지원을 위한 데이터는 비공개로 꽁꽁 감춰져 있는 반면, 동적 바인딩 형변환을 위한 타입 식별자 데이터는 공식적으로 스펙이 공개돼 있고 일반 프로그래머들이 언어 요소를 통해 접근할 수 있다. 일명 RTTI (run-time type info)이다.
#include <typeinfo>를 한 뒤 typeid() 연산자로 const type_info&라는 구조체, 아니 클래스를 들여다보면 된다. typeid는...

  • sizeof와 마찬가지로 오버로딩 할 수 없다.
  • sizeof와 마찬가지로 타입 이름과 일반적인 값을 모두 받을 수 있다. 단, sizeof는 값이 올 때는 괄호를 생략할 수 있는 반면, typeid는 그렇지 않아서 언제나 뒤의 피연산자를 괄호로 싸야 한다.
  • sizeof는 결과값이 무조건 정적 바인딩으로 구해지는 반면, typeid는 바인딩이 정적과 동적 사이에서 어정쩡하다. 피연산자가 타입 이름이거나, 값이더라도 int 같은 primitive type 내지 상속이고 가상 함수고 아무것도 없는 구조체라면.. sizeof와 마찬가지로 수식을 실제로 evaluate하지 않는다. 그러나 뭔가 상속 관계 규명이 필요하다 싶은 개체라면 런타임 계산이 행해진다.

쉽게 말해 typeid는 MFC로 치면 obj->GetRuntimeClass()와 RUNTIME_CLASS(classnam)의 역할을 혼자 모두 수행한다는 뜻이다.
그럼 관련 타입들에 대해 DECLARE_DYNAMIC 내지 IMPLEMENT_DYNAMIC도 어딘가에 행해져야 할 텐데, 그건 C++ 컴파일러가 typeid 연산자가 쓰인 곳을 총체적으로 따져서 알아서 처리해 준다.

이런 RTTI 기능은 대다수의 C++ 컴파일러에서 사용 여부를 옵션으로 지정할 수 있게 돼 있다.
RTTI를 사용한 상태에서 dynamic_cast를 사용하면 실제 타입이 그게 아닌데 그 파생 타입으로 형변환을 시도하는 경우.. 피연산자가 포인터였다면 NULL이 날아오고, null이 가능하지 않은 참조자를 줬다면 예외(exception)를 날리게 된다.
이것도 다중 상속까지 생각한다면 상속 관계 그래프를 타고 오프셋을 보정하는 알고리즘이 가히 판타지가 될 것 같다.

이상.
객체지향 언어라는 게 그냥 구조체에다가 this가 자동으로 전달되는 함수가 같이 딸려 있고, 상속에 다형성 정도 지원되는 게 전부라고 생각하는 게 얼마나 순진한 생각인지 알 것 같다.
PC 환경에서 C를 초월하여 C++이 보급된 게 1990년대 초쯤인데, 이 무렵에 템플릿과 다중 상속도 도입됐다. 처음부터 있었던 게 아니다. 그리고 그때부터 C++은 뭐랄까, 괴물 같은 복잡도를 자랑하는 치떨리는 언어로 변모한 것 같다.

구리고 지저분한 면모가 많지만 그래도 그 정도 객체지향 이념에다가 고성능 저수준 제어까지 이만치 잡은 건 얘가 C++이 가히 독보적인 것 같다.
그러니 형변환 연산자도 언어를 따라 이렇게 복잡해진 것이다. 일례로, Java는 final이 있을지언정 포인터도 없고 const니 volatile 같은 건 신경 쓸 필요도 없는데 뭐 저런 구분이 필요하겠는가? 그러니 지금도 여전히 C-style cast만으로도 충분한 것이다.

Posted by 사무엘

2018/03/25 08:30 2018/03/25 08:30
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1471

« Previous : 1 : 2 : 3 : 4 : 5 : ... 7 : Next »

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2019/10   »
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

Site Stats

Total hits:
1267008
Today:
141
Yesterday:
552