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

1. 함수 명칭만으로 오버로딩 분간하기

C++에는 그 이름도 유명한 함수 오버로딩이라는 게 존재하기 때문에 어떤 함수를 이름만으로 유일하게 식별할 수 없다. 링크를 위한 심벌을 생성할 때는 자신이 받아들이는 인자들의 개수와 타입도 이름에다가 일일이 곁들여 줘야 동명이인(?) 함수들을 구분할 수 있다. 이 절차를 decoration이라고 한다.

그런데 바이너리 차원에서 함수 이름에 대한 구체적인 decoration 방식은 표준으로 정해진 것이 없어서 컴파일러마다 완전히 제각각이다. 이 때문에 동일한 타겟에다 동일한 포맷의 obj/lib(기껏해야 OMF 아니면 COFF..)라도 C++ 클래스 라이브러리는 컴파일러를 넘나드는 이식성이 크게 떨어진다.

C 단독이 거의 쓰이지 않는 오늘날까지도 유명 라이브러리들이 C언어 형태의 단순한 인터페이스를 고집하는 이유 중의 하나가 바로 이것이다. 아니면 그런 C 함수를 아주 얇게 감싸는(생성자, 소멸자, 오버로딩..) C++ wrapper 클래스를 만들더라도 하는 일이 정말 C 함수 호출밖에 없고, C++ 멤버 함수는 몽땅 인라이닝이 되게 만든다. 인라이닝이 됐다면 decoration이고 뭐고 걱정할 필요가 전혀 없어지기 때문이다.

그런데.. C++에서 함수를 (1) 실제로 호출하지 않고, (2) 저렇게 decoration 정보가 있는 link time도 아니면서 소스 코드 차원에서(= compile time) 오버로딩 동명이인 함수를 구분할 수는 없을까?

엥? (1)도 (2)도 아닌 애매한 상황은 C++에서 한동안 고려할 필요가 없었다. 그러나 2010년대부터 modern C++이 등장하고, 명칭만으로 type을 유추할 수 있는 auto와 decltype 키워드가 도입되면서 발생할 수 있게 됐다.

void foo() {}

라는 함수를 정의해 놓았다면

auto ptr = &foo;
decltype(&foo) ptr = ...;

이런 식으로 foo를 얼마든지 써먹을 수 있다. auto와 decltype이 자동으로 void (*)()이라는 타입을 유추해 내기 때문이다. 그런데 문제는..

void foo(int) {}

같은 overload를 더 만들었을 때이다.
그러면 이때부터 auto와 decltype에다가 foo를 언급할 수 없게 된다. 이 이름이 가리키는 함수의 prototype이 하나로 딱 떨어지지 않기 때문이다.

이에 대해 C++ 표준 스펙은 오버로딩된 함수 이름을 저기에다 집어넣는 것은 ill-formed라고만 지적하고 넘어간다. (☞ 링크)
이건 컴파일된 obj가 아니라 소스 코드 레벨이기 때문에 decorate된 저수준 명칭을 사용할 수도 없다. 어느 오버로드인지를 지목하는 문법은 딱히 마련하지 않고 넘어간 듯하다.

글쎄, 생각 같아서는 foo as_in () 내지 foo as_in (int) 같은 오버로딩 식별을 위한 토큰이 필요해 보인다.
파이썬이라면 모를까 C++에서 겨우 이런 용도를 위해 영단어 예약어를 도입하는 건 보기 좋지 않다. 그냥 foo 다음에 -> : []처럼.. 데이터 포인터가 아닌 함수 포인터라면 쓰일 일이 없는 기존 연산자 토큰을 늘어놓아서 이 함수의 인자들의 타입을 기술해 주면 될 것이다.

참고로, 함수의 포인터를 얻는 상황에서는 static_cast가 아주 유용하게 쓰인다.
void *p = static_cast<int (*)(int,int)>( func_ptr );

이렇게 해 주면 이 형변환은 func_ptr이 int 2개를 받고 int를 리턴하는 놈이 실제로 선언이나 정의돼 있을 때에만 성공한다. 그런 게 없으면 에러.. 그러니 안전하다. 흥미롭지 않은가? 형변환 연산자가 함수의 동명 오버로드를 분간할 때도 쓰인다니 말이다.
C-style cast나 reinterpret_cast는 그런 면모가 없고 무조건 될 것이다.

2. 복합 포인터 간의 더 세밀한 형변환 연산자

C/C++에서 void*라는 포인터 타입은 잘 알다시피 다른 아무 자료형을 가리키는 포인터를 받아서 대입될 수 있다. 공집합은 다른 모든 집합들의 부분집합이며, 1은 다른 모든 자연수의 약수인 것과 같은 이치이다.
malloc을 비롯해 메모리를 할당하는 함수들은 특정 자료형에 구애받지 않는 void*를 되돌린다. 그런데 이 포인터값을 함수의 리턴값이 아니라 함수 인자로 전달된 포인터가 가리키는 주소에다 받게 하려면 어떡해야 할까?

그럴 때는 별 수 없이 이중 포인터가 쓰이게 된다. 자주 보는 물건은 아니지만 Windows에서 COM 객체를 다루다 보면 QueryInterface 메소드, CoCreateInstance 함수 때문에 접하게 된다. COM에서는 함수 리턴값은 에러코드(정수값)를 되돌리고, 포인터는 인자로 전달된 주소를 통해 받기 때문이다.

여기서 우리는 문법 차원에서 약간의 어색함을 경험하게 된다.
void*는 int*, char* 등 다른 포인터 타입과 호환되지만 이중 포인터끼리는 그렇지 않다. 가령, void**와 int**, char** 따위는 호환되지 않는다.
상속 관계도 마찬가지이다. IUnknown**에다가 IUnknown의 파생 클래스의 포인터의 주소를 바로 넘겨줄 수는 없다.

단순 포인터는 한쪽은 호환되고, 역변환은 static_cast만 해 주면 된다. 그러나 이중 이상의 포인터는 가리키는 타입도 타입 그 자체가 아니라 그 타입의 포인터이다. 그렇다 보니 타입간의 아무런 계층 관계가 인정되지 않는다. 어느 방향으로든 얄짤없이 무식하게 reinterpret_cast만 써야 한다.

글쎄, 이런 일이 자주 발생하고 구분해 줄 필요가 꼭 있다면 pointer_cast 내지 reference_cast라고 해서.. 다중 포인터라도 참조 깊이가 동일하고 최종적으로 도달하는 타입이 서로 static_cast급으로 호환된다면 변환을 허용하는 형변환 연산자를 둘 법도 해 보인다. 저건 굳이 reinterpret_cast까지 사용해야 할 정도로 과격하고 위험해 보이지는 않기 때문이다.

하지만 저 상황만을 위해서 별도의 키워드까지 추가하는 건 좀 overkill 낭비로 보이니 그렇게 되지 않은 것 같다. 배열이야 필요에 따라 3차원 이상의 다차원 배열이 쓰일 수 있지만, 포인터는 본인도 20여 년에 달하는 프로그래밍 인생 이래로 3중 이상 깊이의 포인터를 사용할 일은 전혀 없었다. 즉, void ***p라든가, 이중 포인터에 대한 주소값 같은 것 말이다.

포인터라는 게 크게.. (1) 타 자료형에 대한 포인터, (2) 함수에 대한 포인터, (3) 구조체 및 클래스의 멤버에 대한 포인터라는 세 갈래로 나뉘는 것 같다. 물론, (1)~(3) 종류 불문하고 포인터를 가리키는 포인터는 자동으로 (1)에 속하게 된다. (2)와 (3)은 void*로 싸잡아 일컫는 것이 권장되지 않거나 원천적으로 가능하지 않다.

멤버 포인터의 포인터 내지 배열 같은 것은.. 잠깐 테스트를 해 보니 그래도 문법적인 한계나 typedef 땜빵 없이 이렇게 바로 선언해서 쓸 수 있긴 하다. 물론 멤버 포인터 자체도  쓰일 일이 극도로 드문데 하물며 그걸 또 가리키는 포인터는.. 삼중 이상의 포인터만큼이나 정말 레어템이다. 아래처럼 말이다.

class A {
public:
    void func(int x);
};

void (A::*pfn)(int) = &A::func;
void (A::**ppfn)(int) = &pfn;
void (A::*apfn[1])(int) = { &A::func };

A obj;
(obj.*pfn)(1);
(obj.**ppfn)(2);
(obj.*apfn[0])(3);

복잡한 포인터에서 세부 속성 간의 형변환은 비단 다중 포인터에만 존재하는 게 아니다. 함수 포인터에다가 인자의 개수와 calling convention 같은 건 완전히 일치하고, 일부 인자나 리턴값만이 void*와 char*처럼 미묘하게 다른 함수를 집어넣는 상황을 생각해 보자. 일반 함수뿐만 아니라 C++ 멤버 함수의 포인터도 해당된다.

이때도 지금 문법에서는 닥치고 C-style 또는 reinterpret_cast를 쓰는 수밖에 없다. 하지만 static_cast와 reinter_*의 중간 완충 역할을 해서 저럴 때만 유도리를 허용하는 연산자가 있다면 문법 차원에서 실수가 더 줄어들 수 있고 더 깔끔한 코드를 작성할 수 있다. 프로그래밍 언어에서 type theory의 심오함이 문득 느껴진다.

3. 복수 인터페이스의 구현체에서 IUnknown 베이스 얻기

C++로 COM 인터페이스를 지원하는 클래스를 구현하다 보면.. 다중 상속 기능을 이용하여 한 클래스에다가 2개 이상의 인터페이스를 한꺼번에 집어넣는 경우가 있다.
예를 들어 한 윈도우가 drag & drop을 양방향으로 지원해서 데이터를 밖으로 날릴 수도 있고 받을 수도 있다면, 그 윈도우를 나타내는 클래스(가령, CMyWnd)에다가 IDataObject, IDropSource와 IDropTarget를 몽땅 때려박는 게 편하다.

이렇게 하고 나면, 그 CMyWnd를 상대로 인터페이스들의 베이스인 IUnknown의 QueryInterface, AddRef, Release 메소드를 호출하는 것이야 아무 문제 없이 된다.
다중 상속의 특성상, CMyWnd를 IDataObject, IDropSource, IDropTarget 등으로 캐스트한 포인터 값은 제각각 달라질 수 있다. 왜냐하면 멤버 변수가 없는 인터페이스이더라도 상속을 하나 할 때마다 vtable 포인터의 크기 하나씩은 클래스에다가 차지하게 되기 때문이다.

하지만 이들의 vtable에서 IUnknown 파트는 모두 공통으로 CMyWnd가 구현한 동일한 QueryInterface, AddRef, Release 함수를 가리키게 된다. 이게 바로 마법의 비결이다.
단, 둘째, 셋째, n째 인터페이스들은 this 포인터 값을 살짝 보정한 뒤에 원래 함수를 호출하는 thunk가 추가된다. 마법이 공짜는 아닌 셈이다. 그래서 다중 상속에서는 내가 함수를 호출한 객체의 주소와, 해당 멤버 함수가 받은 this 포인터의 값이 일치하지 않을 수 있다.

그렇게 다중 상속에서 함수 호출과 this 보정 문제가 해결되었는데.. 정작 CMyWnd 오브젝트의 포인터를 IUnknown* 자체로 cast 하는 것은..??? 뜻밖에도 되지 않고 컴파일 에러가 난다. 암시적 자동 형변환은 물론이고, static_cast와 C-style cast도 통하지 않는다.
왜냐하면 얘는 2개 이상 여러 인터페이스를 구현했는데 어느 놈을 기준으로 삼아서 IUnknown으로 cast 해야 할지 알 수 없기 때문이다. 모호성이 존재한다는 것이다. 뜨악~

현실에서 어지간해서는 이런 일을 겪을 일이 거의 없다. 그냥 파생 클래스 구현체가 베이스 인터페이스의 완벽한 상위 호환이니, 어지간한 상황에서는 그냥 그 클래스를 쓰면 되지 굳이 베이스로 형변환을 할 일 자체가 없기 때문이다.

하지만 아무 인터페이스 오브젝트나 받아들여서 레퍼런스 카운트 관리만 한답시고 IUnknown을 인자로 받는 함수가 드물게 있을 수 있다. 그 함수에다가 이런 오브젝트를 덥석 넘겨주면 어느 베이스의 IUnknown을 골라야 할지 모르겠다는 태클에 걸린다. 저 인터페이스들이 IUnknown을 가상(virtual) 상속을 한 게 아니기 때문에 이 문제를 피해 갈 수 없다. 어차피 인터페이스에는 데이터 멤버도 없으니 아무거나 골라도 됨에도 불구하고 말이다.

그 클래스가 상속한 베이스들 중 가상 함수가 존재하는 제일 첫 놈이 IUnknown 기반의 인터페이스라면.. 그 클래스의 인스턴스의 포인터는 그대로 직통으로 IUnknown으로 형변환해도 된다. 하지만 이건 이게 C++의 문법 차원에서 안전이 보장될 수 없는 동작이기 때문에 컴파일 에러가 발생하는 것이다.

C-style cast는 static_*과 reinterpret_*의 중간 정도 위상을 차지하는 물건이며, 포인터 간의 형변환에서는 오히려 후자에 더 가까운 위치에 있다. 하지만 다중 상속에 대해서는 의외로 선 넘지 않는 안전 장치가 걸려 있는가 보다.
저 때 자기 자신을 베이스인 IUnknown으로 강제로 둔갑시키는 수단은 reinterpret_cast밖에 없다.
아니면!! 자신을 void*로 먼저 전환한 뒤에 그걸 IUnknown으로.. static_cast를 두 번 적용하면 된다. 물론 이것들은 다 at your own risk를 감수하고 해야 한다.

이 문제를 해결한답시고 CMyWnd에 대해서 무식하게 QueryInteface(IID_IUnknown, &obj)를 하는 건 너무 오버 같다.
뭐, 어느 베이스를 선택할지 static_cast<IDataObject*>(&obj) 이렇게 명시적으로 지정을 해 주면 모호성이 해소되어 C++ 차원에서 IUnknown으로 cast도 가능해진다.
하지만 이것도 언어 차원에서 더 깔끔하게 해결할 방법이 없는지, const 객체뿐만 아니라 베이스 인터페이스에 대해서도 select_any 같은 속성을 지정해 줄 수는 없을지 궁금하다.

참고로 이런 형변환이 일어나는 곳은 해당 객체 자체가 아니라 십중팔구 그 객체의 포인터들이다. 그러니 그 클래스에서 operator IUnknown*() { return static_cast<****>(this); } 이렇게 전용 형변환 연산자를 구비하는 것은.. 성능 오버헤드는 없지만 언어 문법 차원에서의 아주 깔끔한 해결책으로 보기는 어려워 보인다.;;;

Posted by 사무엘

1. 파이썬

요즘 프로그래밍 언어는 네이티브 코드+수동 메모리 관리(= 가상 머신이나 GC가 없는) 분야에서야 C++이 무섭게 발전하면서 약진하는 중이다. D나 Rust나 델파이 같은 나머지 네이티브 코드 언어 진영은 요즘 어찌 지내나 모르겠다.

거기서 양상이 살짝 바뀌어서 VM 기반의 언어로는 Java와 C#이 대표적이다. C#은 매우 뛰어난 언어이고 기반이 탄탄한 건 사실이지만 PC와 Windows의 밖에서는 과연 쓸 일이 얼마나 있나 모르겠다. 안드로이드와 iOS 모두 앱 개발용으로 권장하는 주력 언어가 코틀린, Swift 등 생소한 것으로 바뀌었는데, 지난 수 년 동안 기존 언어(Java, Objective C)의 점유율은 어찌 바뀌었는지 역시 궁금하다.

이보다 표현이 더 자유로운 동적 타입 언어 세계에서는 닥치고 JavaScript 아니면 파이썬이 지존 압권 깡패로 등극했다. 펄, 루비, 루아.. 등등 필요 없고 이걸로 다 물갈이돼 버렸다. 특히 파이썬은 교육용과 실무용이라는 두 영역에서 완벽하게 주류로 자리잡았다는 것이 대단하고 신기하다.

대학교들 CS101 프로그래밍 기초 코스에서 가르치는 언어도 C, Java를 거쳐 지금은 몽땅 파이썬이다. 교육용이 아니면 일부 특수한 분야 한정의 마이너 언어에 그쳤던 과거의 베이식이나 파스칼과는 매우 대조적인 점이다. 한편, JavaScript는 웹의 세계 공용어라는 독보적인 지위를 획득했고 말이다.

네이티브 코드인 C++, 가상 머신 기반인 Java, 동적 타입인 파이썬.. 이렇게 등급과 종류를 불문하고 언어들에 한때는 객체지향 패러다임이 들어가는 게 유행이었는데, 21세기에 들어서는 함수형 패러다임도 필수가 돼서 익명 함수(람다) 정도는 지원해 줘야 아쉽지 않은 지경이 돼 있다.

C/C++, Java 같은 언어에만 파묻혀 살다가 컴파일 에러와 런타임 에러의 구분이 없는 언어..
catch되지 않은 예외 같은 에러를 잡고 나니 다음으로 소스 코드의 스펠링 에러를 접할 수 있는 언어를 쓰는 느낌은 참 묘하다.
그래도 컴파일 없이 바로 실행한다는 게 심리적으로 참 부담없고 가벼운 느낌을 준다. 먼 옛날에 Basic 쓰던 시절 이래로 얼마 만에 다시 경험하는 느낌인지?

• 나눗셈은 정수/정수라도 언제나 실수가 되는구나. 이건 C/C++ 계열이 아니라 베이식/파스칼에 더 가까운 이념이다. 그래도 '같지 않음'이 <>가 아니라 !=인 것은 C/C++ 영향이다.
  
• 비트 연산자는 & |로 두고, 논리 연산자를 and or이라는 단어로 분리한 것은 나름 양 계열의 특성을 골고루 적절하게 수용한 디자인인 것 같다.
• 삼항 연산자 A ? B:C를 B if A else C로 표현한 것은.. 우와;;;;
• 함수에 인자를 전달할 때 값만 그냥 전하기도 하고 경우에 따라서 config=100 이렇게도 주는 건.. C/C+++ 스타일과 objective C 스타일을 모두 접하는 것 같다.
• 문자열이나 리스트 같은 복합 자료형에다가 상수배 곱셈 연산을 해서 복제 뻥튀기를 시키는 것도 상당히 유용하다. 단, 이 경우 내부에 있는 복합 자료형들은 shallow copy만 된다. 제대로 deep copy를 하려면 list comprehension 같은 다른 기법으로 원소들을 하나하나 새로 생성해야 한다.
• 여러 변수에다 한꺼번에 대입하기, 그리고 리스트 원소들을 연달아 함수 인자로 풀어넣기...;;;
• 코딩을 하다 보면 특정 자료구조 내부의 원소들을 range-based for 문으로 순회함과 동시에, 각 원소별로 1씩 증가하는 인덱스 번호도 같이 돌리고 싶은 때가 많다. 이럴 때 파이썬은 for i, elem in enumerator(set)라고.. enumerator를 사용하면 저 기능을 곧장 구현할 수 있다.. 오, 이거 사이다 같은데?
• []는 배열, {}는 dictionary. 의도한 건지는 모르겠지만 JSON 자료구조와 딱 정확하게 대응한다.
• 문자열에 "" ''을 모두 사용 가능한 건 SQL 같다. 다만, 문자로 표현된 숫자 리터럴과의 구분이 없다 보니, 'a'와 97을 상호 변환하는 건 베이식이나 파스칼처럼 별도의 함수를 써야 한다.

2. 각 프로그래밍 언어별로 없어서 처음에 좀 놀랐던 것들

• JSON: JavaScript라는 프로그래밍 언어의 문법을 채용했다면서 정작 자신은 코멘트를 넣는 부분이 없고 정수 리터럴에 16진수 표기용 접두사가 없다. 얘는 오로지 machine-generation만 생각했는가 보다.
  
• Java: int 같은 primitive type을 함수에다 reference로 전달해서 swap 같은 걸 시킬 수 없다. 그리고 가상 머신 환경에서 큰 의미가 없긴 하지만 sizeof 연산자도 없다.
  
• 파이썬 1: goto가 없는 건 Java도 마찬가지이지만.. switch-case도 없다. 파이썬은 들여쓰기 구문이 콜론으로 끝나는 언어인데, 정작 C/C++계열에서 라벨과 콜론을 사용하는 문법이 저 동네에서 존재하지 않는 셈이다. 넣어 달라는 제안이 과거에 있긴 했지만 문법적으로 난감해서 봉인됐다고 한다. 뭐, 그 대신 얘는 elif가 있다.
• 파이썬 2: 그리고 파이썬은 명시적인 const 속성도 없는 것 같다. 튜플이 값의 불변을 보장하는 자료형이기 때문에 const 테이블 역할을 같이 담당한다.
  
• 파스칼: 오리지널 문법에서는 임의의 크기의 동적 배열을 만들 수 없다. 참고로 베이식은 배열의 크기 조절은 자유이지만 포인터가 아예 존재하지 않다 보니 리스트 같은 재귀 구조의 복잡한 자료구조를 구현하는 것 자체가 원천 불가능이다.
  
• 익명 함수: C++의 람다만 그런 건지는 모르겠지만, 자기 자신을 간단히 가리키는 키워드가 없고 재귀호출을 구현할 수 없다. 그나마 구현했다는 것들은 다 주변의 다른 functor 등 갖가지 편법을 동원해서 매우 힘들게 억지로 구현한 것들이다.

사실, C/C++의 for문은 while문과 거의 동치일 정도로 조건 검사 지향적이고 range-based for는 21세기가 돼서야 도입됐다. 그러나 파이썬의 for문은 훨씬 더 range 내지 iterator 지향적이다.

그리고 베이식 같은 언어는 switch/case가 거의 if문의 연장선일 정도로 범위 지정도 되고 쓰임이 유연하지만.. C/C++의 switch/case는 그보다 제약이 심하다. 그 대신 그 제약을 이용해서 컴파일러가 최적화를 할 여지가 더 있다. (가령, 조건 검사 대신 테이블 오프셋 참조로..)

3. 언어 문법 차원에서의 지원

20여 년 전 먼 옛날에 스타크래프트 경기 중계방송이란 게 처음으로 행해지던 극초창기엔 경기 운영 노하우가 부족해서 이런 일이 있었다고 한다.
경기를 하는 선수 말고 화면 중계를 위한 옵저버도 게임에 join을 해야 하는데, 자기 기지는 없이 남들 시야 눈팅만 하는 상태로 참여하는 방법을 몰랐던 것이다.

그러니 그때 옵저버는 테란을 골라서 들어갔다. 자기 커맨드센터는 띄워서 맵 구석 모서리에 안 보이게 처박아 놓고, SCV 4기는 서로 공격시켜서 없앴다. 이런 궁색한 삽질을 해서 자기 존재를 최대한 없애 버린 뒤 선수들의 화면을 중계했던 것이다.

물론, 옵저버의 이런 자폭 플레이는 경기 시작 직후, 카메라가 잠시 각 선수들의 개인 화면을 비추고 있는 동안 최대한 잽싸게 행해졌다. 한편으로 선수들 역시 옵저버에게 자기 시야를 공개하는 설정을 매번 수동으로 해 줘야 했다.
선수가 옵저버의 커맨드센터를 고의나 실수로 부숴서 옵저버를 엘리시켜 버리는 건.. 그건 경기 진행 방해이며 규정상 거의 반칙 몰수패 사유가 됐을 것이다.;;

그러다가 잘 알다시피 경기용 맵은 특수하게 트리거를 조작해서 옵저버를 위한 전용 자리가 있는 "유즈맵, 커스텀 맵" 형태로 만들어지고 쓰이게 되었다. 이제 옵저버의 일꾼을 제거하고 커맨드센터를 치우는 삽질을 할 필요가 없어진 것이다.
하지만 경기 자체는 다른 특이 사항이 전혀 없고 건물 짓고 유닛 뽑아서 적 진영을 부수는 것밖에 없는데 매번 유즈맵을 쓰는 건 번거로웠다. 스타 프로그램 차원에서 일반 맵에다가 옵저버 참관 기능을 지원하는 게 제일 이상적이고 바람직했다.

결국 옵저버 참관 기능은 먼 훗날 스타의 1.18 패치에서 정식으로 도입됐다. 지난 1.08 패치에서 리플레이 기능이 추가된 것만큼이나 참신한 기능이다.
특히 이 참관 기능은 각 선수들의 개인 화면과 동급으로 진영별 자원 수, 생산· 연구 건물들의 내부 진행 상태까지 모두 볼 수 있어서 매우 편리하다. 과거의 유즈맵 옵저버로는 그런 게 가능하지 않았기 때문에 선수 개인 화면의 모습을 직접 봐야 했다.

이렇게 과거에 꼼수로 구현하던 기능들이 훗날 정식으로 가능해진 것의 예로는 C++ 프로그래밍이 떠오른다.
일례로, 복사나 대입이 가능하지 않은 클래스를 만들기 위해서 복사 생성자나 대입 연산자를 private에다가 미구현 상태로 박아 넣는 꼼수가 동원됐지만.. C++14부터는 = delete라는 더 완전하고 깔끔한 문법이 언어 차원에서 추가됐다.

Posted by 사무엘

1. 가상 함수 테이블을 강제로 없애기

C++에서는 가상 함수가 하나 이상 존재하는 클래스는 그렇지 않은 클래스와 좀 다른 취급을 받게 된다. 자기가 새로 선언한 것뿐만 아니라 기반 클래스로부터 상속받은 가상 함수까지 포함해서 말이다.
가상 함수가 존재하는 모든 클래스들은 각각 가상 함수 포인터 테이블(v-table)이라는 일종의 global 배열을 할당받으며, 이를 가리키는 포인터를 멤버로 갖게 되고 생성자에서 그 포인터의 값이 초기화된다.

클래스에 온갖 파생 클래스와 가상 함수들이 추가되고 상속 단계가 복잡해질수록, 이 테이블들의 개수와 크기도 무시 못 할 비중을 차지하게 된다.
A라는 클래스에 가상 함수가 5개 있으면 A의 v-table은 크기가 5이다. 그런데 A로부터 상속받은 클래스 B가 또 가상 함수를 3개 추가한다면 B의 v-table의 크기는 5+3 = 8이 된다. 그런 식이다. 다중· 가상 상속 같은 것까지 자연스럽게 지원하려면 B의 v-table에도 A의 것이 고스란히 몽땅 중복 등재돼 있어야 한다.

그런데 문제는 순수 가상 함수가 들어가 있어서 단독으로 인스턴스가 생성될 일이 전혀 없는 클래스에 대해서도 일단은 동작의 일관성을 보장하기 위해 v-table이 잉여스럽게 따로 생성된다는 것이다.
왜냐하면 B라는 클래스의 생성자는 그 정의상 기반 클래스 A의 생성자를 반드시 호출하게 돼 있고, A의 생성자가 하는 일 중 하나는 A에 대한 고유한 v-table을 참조하는 것이기 때문이다.

어차피 값이 거의 전부 다 NULL이고 실제로 쓰일 일도 없는 v-table이 쓸데없이 생성되는 일을 막기 위해, Visual C++에는 __declspec(novtable)이라는 비표준 확장 속성이 도입되었다. 특히 COM이라는 규격을 C++ 언어와 바이너리 차원에서 연계하려다 보니 이 기능이 없어서는 도저히 안 되는 지경이 되었다.

굳이 순수 가상 함수가 없더라도, 어쨌든 반드시 파생 클래스 형태로만 쓰이지 그 자체가 인스턴스 형태로 선언될 일이 없는 클래스라면 __declspec(novtable)를 지정해 주는 게 메모리 절약 측면에서 좋다. 날개셋 한글 입력기의 경우 이걸 적용해 주니 ngs3.dll의 크기가 수 KB 남짓 줄어드는 효과가 있었다.

특히 데이터 멤버 없고 순수 가상 함수밖에 없는 인터페이스라면 이거 지정이 무조건 필수이다. 이래서 후대의 객체지향 언어들은 구조체(생성자 소멸자 가상 함수 없는 POD) vs 클래스뿐만 아니라, 일반 클래스 vs interface(추상 클래스)도 언어 차원에서 구분한다는 게 느껴졌다. 이게 단순히 외형이나 기분상의 구분만을 의미하지 않는다.

파생 클래스 쪽의 초기화가 덜 된 오브젝트에 대해서 순수 가상 함수를 호출해 버리면 보통은 pure virtual function call이라는 C++ 예외가 발생한다. 그런데 __declspec(novtable)가 지정된 오브젝트에 대해서 가상 함수를 호출해 버리면 저런 high-level 예외가 아니라 그냥 NULL 포인터 접근에 준하는 평범한 access violation 에러가 나면서 프로그램이 죽게 된다.

2. 가상 함수 테이블의 메모리 오버헤드

가상 함수 테이블 얘기를 계속하겠다.
B가 가상 함수가 100개 있는 A라는 클래스를 상속받아서 자신만의 가상 함수를 새로 만드는 것 없이, A의 함수 중 딱 한두 개만 override를 했더라도.. 컴파일러는 내용이 한두 개밖에 차이가 나지 않고 거의 동일한 원소 100개짜리 함수 포인터 배열을 또 하나 만들게 된다. B의 모든 인스턴스들이 한데 공유하는 가상 함수 포인터 테이블 말이다. 일종의 copy-on-modify와 비슷한 메커니즘이다.

그렇게 해야만 A건 B건 오브젝트 종류를 불문하고 가상 함수의 주소를 배열 오프셋만으로 O(1) 시간 만에 곧장 얻어 와서 호출을 할 수 있기 때문이다.
가상 함수 호출은 그렇잖아도 오버헤드가 일반 함수 호출보다 훨씬 더 큰데, 메모리를 아낀답시고 주소를 얻는 것조차 클래스 계층이나 함수 테이블을 뒤지는 방식이어서는 곤란하다.

하지만 이런 내부 디테일과 오버헤드를 생각하면 클래스를 아무 부담 없이 막 상속받기가 좀 부담스러워진다. 뭐, 요즘처럼 컴퓨터에 메모리가 풍족한 시대에 무슨 198, 90년대 같은 메모리 구두쇠 쫌생이처럼 코딩을 할 필요는 없지만, 그래도 같은 값이면 컴퓨터의 자원을 아껴 쓰는 게 프로그래머의 미덕 아니겠는가?

그렇다고 언어의 스펙을 바꿔 버릴 수는 없으니, Windows용 C++ 라이브러리인 MFC는 저런 가상 함수 테이블 오버헤드를 줄이기 위해, CWnd 클래스의 Windows 메시지 handler 함수는 가상 함수 대신 pointer-to-member 기반의 message map으로 구현한 것으로 잘 알려져 있다.

얘는 사용자가 실제로 overriding을 한 함수의 개수만큼만 테이블의 크기가 커지니 공간 사용은 효율적이다. 그러나 메시지에 대응하는 함수를 찾는 일은 매번 테이블을 선형 검색을 해야 하기 때문에 시간 복잡도가 O(n)으로 커진다.
이 부분은 정말 밥 먹듯이 자주 호출되는 부분이고 목숨 걸고 성능을 최적화해야 하는지라, MFC 소스에서도 극히 이례적으로 인라인 어셈블리가 사용되어 있다~! (wincore.cpp의 AfxFindMessageEntry 함수)

객체지향을 구현하기 위해서 이런 시간-공간 tradeoff를 따져 봐야 하니, C++보다 더 유연한 디자인을 추구한 Objective C 같은 언어는 메시지를 아예 문자열로 식별하게 했다(selector). 이름으로부터 실제 주소 매핑은 물론 hash 기반이고..

C++은 배열 오프셋 기반이어서 당장 성능 자체는 제일 좋으나, 클래스에서 뭐가 바뀌었다 싶으면 몽땅 재컴파일 해야 한다. 그리고 그런 경직된 체계에서 다중/가상 상속과 멤버 함수 포인터까지 구현하려다 보니 디자인에 무리수가 많이 들어갔고, 그 뒷감당은 결국 컴파일러 제조사들이 비표준 확장을 도입해서 땜빵하는 촌극이 벌어졌다.

그에 비해 Objective C는 신호등 교차로 대신 회전 교차로, 수동 변속기 대신 아예 자동 변속기 같은 접근을 한 셈인데.. C++ 같은 C의 이념 적당히 절충이 아니라 객체지향 언어라는 이론만 생각해 보면 저런 접근 방식도 충분히 가능은 하겠다는 생각이 든다.

3. 캐사기 auto

람다 함수가 최초로 도입된 C++0x 시절에 곧장 가능했던 것 같지는 않다만..
요즘 람다는 인자와 리턴값의 타입으로 auto를 지정할 수 있다.. >_<
auto에서 또 auto가 가능하다니? 그것도 C++ 같은 언어에서.. 이건 좀 꽤 사악한 기능인 것 같다.

auto Func = [](auto x) -> auto { return x * 2; };
printf("%f\n", Func(1.4));
printf("%d\n", Func(25));

람다가 일반 C++ 함수 같은 오버로딩이나 템플릿을 지원하지는 않으나, 저기서는 auto가 템플릿 인자 역할을 하는 거나 마찬가지이다.
생긴 건 함수와 비슷하지만 캡처가 지원되고 호출 규약 제약 없고 저런 것까지 가능하니.. 기존의 함수와는 형태가 얼마나 다른지 알 수 있다.

그나저나 람다 함수는 함수 자기 자신을 지칭해서 재귀 호출을 하는 방법은 여전히 없는지? this처럼 자기 함수 자신을 가리키는 예약어가 필요하지 않을까 싶다. __self??
그리고 사실은 C++도 기반 클래스를 지칭하는 __super 같은 키워드도 있어야 할 듯하다.

4. export의 재탄생

C++에서 완전 존재감 없는 잉여로 전락했던 auto가 10여 년 전 2010년대부터는 잘 알다시피 언어의 패러다임의 변화를 주도하는 거물로 환골탈태했다.
그것처럼.. 지난 2000년대에 비현실적인 흑역사 키워드로 전락하고 봉인됐던 키워드 export가.. 2020년대부터는 모듈 선언이라는 완전히 다른 용도로 다시 쓰이게 될 것으로 보인다. 하긴 import, export는 그 대상이 무엇이 됐건 프로그래밍에서는 굉장히 즐겨 쓰일 만한 의미의 동사이긴 하다.

지난 수십 년을 C처럼 원시적인 텍스트 include와 라이브러리 링킹에 의존했던 C++에 파스칼이나 D처럼 신속하게 빌드 가능한 모듈, 유닛이 도입되려는가 궁금하다.
그럼 이제 C/C++에서 제일 존재감 없는 잉여 키워드로는 signed만 남는 건지?

C++이 이 정도까지 변하고 있는데 #pragma once는 좀 언어 차원에서 정식으로 표준으로 수용할 생각이 없는지 궁금하다.
이제 플랫폼을 불문하고 지원하지 않는 컴파일러가 거의 없는 사실상의 표준이며, 실용적으로도 꼭 필요한 기능인데 말이다.

5. 템플릿의 prtial specialization

C++ 템플릿에는 template<typename X> class A처럼 말 그대로 템플릿을 선언하는 게 있는가 하면, template<> class A<XXX> 처럼 특정 타입에 대해 specialization을 하는 문법이 있다. 둘의 형태를 주목하기 바란다.
그런데 C++03즈음에서는 partial specialization이라고 해서 단일 타입이 아니라 일정 조건을 만족하는 템플릿 인자에 대해서는 몽땅 이 specialization을 사용하도록 하는 기능이 추가되었다. 가령 X가 포인터 타입이라든가, 템플릿 인자 A,B를 받는데 B가 A 내부의 pointer-to-member 타입이라거나 할 때 말이다.

이런 specialization에서는 template<typename X> class A<X*> 내지 A<X, X::*> 같은 식으로 template과 A에 템플릿 인자가 모두 들어온다.
개인적으로 이런 기능을 사용해 본 적은 없다. 특정 상황에서 편리한 기능이 될 수는 있겠지만.. 컴파일러를 만드는 건 더욱 어려워질 것 같다..;; 저 시절에 이런 기능과 함께 export까지 제안됐었다니 참 가관이다.

6. C++ 코딩 중에 주의해야 할 점

예전 글에서 언급했던 것들이지만 다시 한데 정리해 보았다.
참고로, 클래스의 상속 관계에서 부모/자식(parent/child), 기반/파생(base/derived)은 서로 기능적으로 아무 차이 없이 기분 따라 섞여서 쓰인다.
인자와 매개변수도(argument/parameter) 그냥 섞여 쓰이는 것 같다.

(1) C++에서는 오버로딩과 오버라이딩이 동시에 같이 자동 지원되지는 않는다.
가령, 한 클래스에서 foo라는 같은 이름으로 void foo()와 void foo(int x)를 모두 정의하는 건 당연히 가능하다(오버로딩).
하지만 둘 중 하나를(가령, 후자) 가상 함수로 지정해서 파생 클래스에서 그놈을 오버라이딩 했다면.. 파생 클래스에서는 오버라이딩 되지 않은 다른 '오버로드' 버전은 자동 지정이 되지 않는다. 이건 혼동을 피하기 위해 C++ 언어의 스펙 차원에서 일부러 그렇게 설계된 것이다.

파생 클래스에서 전자를 사용하려면 기반 클래스의 이름을 거명해서 기반::foo() 이런 식으로 언급하거나..
아니면 파생 클래스의 선언부에서 using 기반::foo; 라고 명시적으로 선언을 해 주면 된다. 그러면 foo만으로 기반 클래스의 두 함수를 곧장 접근할 수 있게 된다. using에 이런 활용 가능성도 있었다니~!

(2) 클래스 객체의 생성 단계에서 멤버들이 초기화되는 순서는 헤더에서 선언된 순서이지, 생성자 함수의 이니셜라이저 목록에 등장하는 순서가 아니다. 그렇기 때문에..

class Bar {
    int x,y;
public:
    Bar(int n): y(n), x(y+1) {}
};

위의 코드에서 x는 제대로 초기화되지 않는다. x(y+1)이 y(n)보다 먼저 실행되기 때문이다.
이건 방대하고 복잡한 클래스를 구현할 때 정말 쉽게 간과하고 실수할 수 있는 특성인데 컴파일러가 경고라도 해 줘야 되지 않나 싶다. 함수 안의 지역변수에서 "초기화되지 않은 변수 거시기를 사용했습니다" 경고를 띄우는 것과 비슷한 로직으로 별로 어렵지 않게 구현할 수 있을 텐데..??

(3) 생성자와 소멸자 함수에서는 자기 객체에 대한 가상 함수를 호출하지 말아야 한다. 비록 기반 클래스의 생성자 및 소멸자가 파생 클래스의 생성자 및 소멸자의 실행 과정에서 같이 호출되겠지만.. 기반 클래스는 자기 객체가 진짜로 기반인지 아니면 상속된 파생 클래스로부터 호출된 것인지를 전혀 알 수 없으며, 알려고 하지도 말아야 한다. 그냥 기반 클래스 자신의 일만 하면 된다.

이는 프로그래머에게 불편을 끼치는 규제가 아니라 언어의 컨셉이 그러하기 때문이다. 생성자와 소멸자는 Windows 메시지로 치면 그냥 WM_CREATE/DESTROY가 아니라 NC 버전이다. (WM_NCDESTROY는 자식 창들이 몽땅 다 사라지고 없는 상태에서 호출) 그리고 복잡한 처리를 절대로 해서는 안 되는 DllMain 함수와도 같다.

기반 생성자는 이 객체가 파생 클래스로서의 초기화가 되기 전에 먼저 호출되고, 기반 소멸자는 파생 클래스 부분이 소멸된 뒤에 맨 나중에 호출된다. 그러니 파생 클래스가 어떠한지를 따지는 것은 전혀 무의미한 것이다.
이건 위의 2번과 마찬가지로 초기화의 순서와 관련해서 저지르기 쉬운 실수이다. 2번은 멤버들의 초기화 순서이고(수평??) 3번은 상속 계층에서의 초기화 순서이다(수직??).

소멸자 자체는 반드시 가상 함수 형태로 선언해야 하지만 소멸자 내부에서 또 다형성을 기대하지는 말아야 한다는 것이 아이러니이다.

(4) 멤버 함수 포인터로 가상 함수의 오버라이딩을 제어할 수는 없다.
한 함수 포인터로 기반 클래스의 함수 내지 파생 클래스의 오버라이딩 함수 중 원하는 것의 주소를 저장하고, ptr의 값(정확히는 ptr이 가리키는 vtbl의 값)과 무관하게 ptr에 대해 원하는 함수를 강제 호출하는 것은 가능하지 않다.

그런 시도를 했을 때 함수 포인터에 저장되는 것은, 그저 ptr->vtbl에 매핑된 버전의 함수를 따로 호출하는 역할을 수행하는 thunk뿐이다.
그러니 멤버 함수 포인터를 동원한다 하더라도 vtbl을 거친 가상 함수 본연의 동작을 변형할 수는 없다.

Posted by 사무엘

1. 호출과 사용

Windows API 중에는 IsBadWritePtr이라고 해서 주어진 포인터가 가리키는 메모리가 올바른지를 되돌리는 함수가 있다. 하지만 이 함수는 모든 경우를 맞게 판단하지 않을 뿐만 아니라 다른 코드에서 처리해야 하는 exception을 가로채서 다른 곳에서 문제를 일으킬 가능성을 높인다.

그리고 올바르지 않은 포인터가 발생했을 정도라면 이런 부류의 함수를 갖고 성공 여부를 어설프게 간보는 게 애초에 별 의미도 없다. 그 즉시 깔끔하게 뻗고 프로그램을 종료시키는 게 차라리 더 안전하며, 문제의 원인을 탐색하는 데도 더 도움이 된다.

이런 이유로 인해 과거에 the old new thing 블로그에서는 IsBadWritePtr should be called XXXX..라는 제목의 글이 올라왔는데, 본인은 제목의 진짜 의미를 파악하지 못해서 한동안 멈칫했다. 함수 이름 다음에 be called가 나오니 이 함수의 호출과 실행, 다시 말해 프로그래머가 이 함수를 사용하는 방법과 관련이 있는 제목인 줄 알았기 때문이다.

하지만 제목의 실제 의미는 그게 아니다. "IsBadWritePtr은 실제로는 XXX라는 이름으로 명명되었어야 한다. 하는 일이 '요게 잘못된 포인터인지 판단'이 아니라 그냥 '프로그램을 랜덤하게 뻗게 하라'이기 때문이다." 요게 제목의 의도이다.
하긴, Windows API 중에는 이름이 좀 므흣하게 지어진 게 내 기억으로 몇 가지 있다. 가령, IsDialogMessage는 동사가 Is가 아니라 Translate가 되는 게 훨씬 더 적절하다는 식으로 말이다.

call이 '명칭 부여'라는 뜻도 있고 '실행, 사용'이라는 뜻도 있다. 옛날에 GWBASIC의 Illegal function call이라는 에러 메시지가 한국어로는 "기능호출 사용이 잘못되었읍니다"라고 호출과 사용을 모두 넣어서 번역됐던 게 떠오른다.

2. 목적어가 자체 포함된 타동사

정확한 출처와 문맥은 기억이 안 난다만.. 본인은 어느 프로그래밍 라이브러리 문서에서 "The XXXX function does not return." 형태의 문장을 본 적이 있다. 언뜻 보기에는 이 함수가 실행이 끝나지 않고 무한루프에 빠진다는 말 같지만, 거기서의 의미는 그렇지 않았다. 저 함수는 그냥 리턴 타입이 void, 즉 리턴값이 없다는 뜻이었다.
이건 영어에서 마치 이런 식의 의미 차이를 보는 것 같다.

• I can't read. 난 문맹이다. (시력이나 조명에 문제가 있어서 못 읽는 게 아니라)
• XXXX is a word. 스크래블 게임 같은 데서, XXXX는 아무 글자 나열이 아니라 스펠링이 맞는 정식 단어이다.

read가 단독으로 '글을' 읽는다라는 뉘앙스를 포함하고 있고, word라고만 해도 자동으로 '올바른' 단어라는 뜻이 포함돼 있다.
사실, 이건 생소한 개념이 아니다. dream, design, sleep 같은 다른 동사도 마찬가지이며 얘들은 아예 명사도 된다. 심지어 dream a dream, design a design, sleep a sound sleep 같은 말도 의도적으로 쓰인다.

옛날 영어에서는 심지어 kill/slay, send 같은 타동사도 목적어를 생략한 채로 쓰였다는 것을 예전 글에서 언급한 바 있다. 그러니 굳이 murder이라고 안 쓰고 thou shalt not kill이라고만 해도 "살인하지 말지니라"가 된다.
return도 그런 식의 유도리 용례가 있는 것으로 보인다.

3. 한국어와 영어의 재귀 구조

한국어는 주어, 보어, 목적어, 부사어 등의 격이 체언 뒤에 달라붙는 온갖 조사들에 의해 구분된다. 어순에 의존하지 않고 격조사가 따로 존재하기 때문에 어순의 도치가 '비교적' 자유로운 편이다.
하지만 종결어미가 들어있는 서술어는 예외이다. 절대적으로 무조건 마지막에 와야 한다. 그리고 그 어떤 문장도 종결어미가 등장해서 말을 완전히 끝맺기 전에는 끝난 게 아니다.

이런 특성으로 인해 한국어를 외국어로서 공부하는 사람들 사이에서 한국어는 끝까지 들어 보지 않으면 뭔 말인지 도무지 종잡을 수 없는 스펙터클한 반전 언어라는 평이 지배적이다.
"내가 무릎을 꿇은 건 추진력을 얻기 위함이었다...는 소식이 나돈다..고 하지만 그건 사실이 아니다" ... 앞서 언급되었던 내용들이 막판에서 순식간에 전면 부정되거나 매트릭스 안에 들어가 버리기 때문이다. 이런 막장 어순을 영어로 실시간 동시 통역해야 한다면 통역자의 멘탈에 얼마 못 가 과부하가 걸릴 것이다.

이런 한국어와 달리, 영어는 SVO형 언어답게 보어건 목적어건 객체를 문장의 뒤에다 꽝 찍은 뒤, 그 객체를 수식하는 문구들이 관계대명사와 함께 꼬리에 꼬리를 물고 끝없이 이어질 수 있다. 즉, 뒤에 이어지는 말들은 앞의 문맥을 더 구체화하는 역할을 한다.
성경으로 치면 롬 8:1처럼 말이다. 그들은 정죄가 없는데 그들이란 바로 그리스도 예수 안에서 걷는 자들이고, 그런 자들은 육체가 아니라 성령을 따라 걷는다.. them, who가 말을 쭉쭉 이어 준다.

한국어는 저런 영어의 특기를 그대로 따라하기가 난감하다. 관형어가 체언의 뒤가 아니라 앞에 등장하며, 길이가 한없이 길어지기 어렵기 때문이다. 말을 저렇게 만들면 십중팔구 번역투가 돼 버리니.. 문장을 둘로 나누거나 어순을 재배치한다든가 해야 한다. 한국어에 가주어 it 같은 개념이 있지도 않으니 말이다.

한국어는 인용문 안에 또 인용이 등장하는 식으로 문장을 n중으로 안았다면 안은 문장을 끝내는 종결어미도 n중으로 역순으로 스택 pop 하듯이 나와 줘야 한다. 그래서 성경에도 “... 있나이다, 하라, 하고” (창 32:18) 같은 문장이 종종 등장한다.

영어는 그런 제약이 없다. 지금 문장이 몇 중으로 깊게 인용돼 있건, 끝나는 건 인용이 없을 때와 아무런 차이가 없다. 이는
if() for() for() while() ...; 과
if() { for() { for() { while() { ... } ... } ... } ... }
의 차이와도 비슷해 보인다.
혹은, 전자는 굳이 스택을 사용하지 않는 선형적인 최적화가 가능한 tail recursion 구조인 반면, 후자는 그렇지 않은 느낌?

지금까지 별 잡생각이 다 튀어나왔는데, 정리하고 결론을 내리자면 이렇다. 한국어와 영어는 말을 길게 이어 나갈 때 화자의 관점 내지 사고 전개 방식이 서로 근본적으로 다르다는 것이다.
어느 것이 구조적으로 더 나은지 굳이 우열을 따질 필요는 없을 것이다. 비트 배열 순서(엔디언)나 함수 인자 전달 방식에 절대적인 우열이 존재하지는 않을 테니 말이다.

단지, 언어간에 이런 차이점이 존재한다는 것을 염두에 둔다면 외국어 학습이나 자연스러운 번역에도 도움이 될 것이다. 그리고 차이점들을 프로그래밍 언어의 특성과 연계해서도 생각해 볼 수 있다는 게 이 글의 요지이다.

Posted by 사무엘

1. 코드의 입체적 배치

C/C++에는 여느 프로그래밍 언어들과 마찬가지로 if else 조건문이란 게 있고 이게 여러 단계로 중첩될 수 있다. 단계가 깊어질수록 코드에서 들여쓰는 왼쪽 여백이 증가한다.

그런데 C/C++에는 전처리기 지시라는 것도 있어서 컴파일되는 실제 코드와는 완전히 별개의 다른 문맥과 차원에서 해석된다. 희곡에서 다른 코드들이 연극 대사라면 전처리기 지시는 괄호 안의 상황 설명지시와 비슷한 존재 같다. 결정적으로는 전처리기에도 조건부 컴파일을 지시하는 #if #else #endif 같은 물건이 있다.

전처리기의 #if도 여러 단계로 중첩되면 알아보기가 상당히 힘들어진다.
그러니 문득 드는 생각은.. 소스 코드의 들여쓰기도 3차원 입체로 표현 가능하면 어떨까 싶다. 통상적인 if else 등의 들여쓰기는 지금처럼 왼쪽 여백으로 표현하고, #if의 단계가 증가하면 그 부분의 코드가 몽땅 X, Y가 아닌 Z축으로.. 전방으로 한 단계 돌출되는 것이다. 해당 부분이 끝나면 다시 쑥 들어가고..
그러고 보니 전처리기 중에는 #if 말고도 #pragma pack처럼 스택 기반으로 설정을 저장하는 것들이 더 있기도 하다.

컴퓨터야 1차원적인 메모리 셀에서 코드와 데이터를 죽어라고 읽고 쓰고 계산하는 기계이겠지만, 그걸 기술하는 프로그램 코드라는 건 색깔(syntax coloring)과 XYZ 축 공간을 모두 이용해서 인간이 최대한 알아보기 편하게 시각화를 할 수 있다. 하지만 이런 수단을 몽땅 동원해도 남이 만든 코드는 선뜻 읽기가 어렵다.;;.

2. 컴파일러의 경고

C/C++ 코딩을 하다 보면 컴파일러가 뱉어 주는 경고 메시지의 도움을 종종 받곤 한다.
제일 자주 보는 건 아무래도 선언만 해 놓고 사용되지 않은 변수, 초기화하지 않고 사용한 변수, void형 함수가 아닌데 return으로 실행이 종료되는 구간 따위이다. 이런 건 에러로 치면 단순 스펠링 오타나 {}() 호응 미스, type mismatch만큼이나 흔하다. 아 하긴 type mismatch는 가벼운 건 warning 형태도 있긴 하다.

경고의 민감도를 상향 조정하면 if문에서 괄호 없이 대입(=) 연산자가 쓰인 것(혹시 비교 연산 ==이랑 헷갈린 거 아니냐?), 우선순위가 아리까리 한 << 나 & 같은 연산자가 괄호 없이 마구 섞여 쓰인 것, 심지어 for이나 if문이 뒷부분 없이 그냥 세미콜론으로 종결된 것까지도 실수가 아닌지 의심스럽다고 일단 지적해 주기도 한다.
글쎄, 컴파일러가 그 정도로 민감하다면.. 본인이 예전에도 언급한 적이 있지만 a=a++이나 a>>-2처럼 이식성이 없는(즉, 컴파일러마다 결과가 다를 수 있는 undefined behavior) 수식이야말로 안 쓰는 게 좋다고 경고를 띄워 줘야 하지 않나 싶다.

요즘 컴파일러는 printf/scanf에서 %문자와 실제 인지의 대응이 맞는지까지도 체크한다. printf 출력일 때는 float건 double이건 %f만 써도 충분하지만(float도 어차피 double로 값이 promote되므로), scanf 입력일 때는 둘은 %f와 %lf로 정확하게 구분돼야 한다.
가변 인자는 그야말로 type-safety의 완벽한 사각지대인데 이런 실수를 컴파일러가 잡아 준다면 프로그래머에게 굉장히 도움이 된다. 원래 전문적인 '정적 분석'용으로 쓰이는 함수의 인자별 annotation 정보까지 컴파일러가 활용하는 것 같다.

그런데 내가 지금까지 본 컴파일러 경고들 중 제일 계륵 같은 건 코드를 32비트에서 64비트로 포팅 하면서 생겨난 수많은.. type mismatch이지 싶다. 이제 int의 크기와 포인터의 크기가 일치하지 않게 되고, 덕분에 int와 INT_PTR의 구분이 생겼기 때문이다.
일단, 이 경고는 레거시 코드에서 발생하는 양이 어마어마하게 많은 편이다. 그리고 (1) 치명적인 것하고 (2) 그다지 치명적이지 않은 것이라는 분명한 구분이 존재한다.

int에다가 포인터를 곧장 대입하는 부분은 전자에 속한다. 이건 번거롭더라도 int를 당연히 INT_PTR로 바꿔 줘야 한다.
그러나 두 포인터의 차이를 대입하는 부분은 상대적으로 덜 치명적인 부분에 속한다. 왜냐 하면 64비트 환경이라 해도 작정하고 프로 연구자가 컴퓨터를 굴리는 게 아닌 한, 단순 end-user급에서 대놓고 2GB, 4GB를 넘는 데이터를 취급할 일은 거의 없다시피하기 때문이다.

특히 문자열의 길이를 구하는 strlen, wcslen 같은 함수 말이다. 리턴 타입이 size_t이지만.. 난 경고를 없애기 위해 그냥 대놓고 #define _strlen32(x) static_cast<int>(strlen(x)) 이런 것도 만들어서 썼다.
주변의 int 변수를 몽땅 확장하기에는 내 함수의 인자와 리턴값, 구조체 멤버 등 영향 받는 게 너무 많고 귀찮고, 그 반면 세상에 문자열 길이가 4GB를 넘어갈 일은 없기 때문이다.

대부분의 경우 무시해도 상관은 없지만 그래도 경고가 뜨는 게 마음에 걸리고, 그렇다고 기계적이고 무의미한 typecast 땜빵을 하고 싶지도 않으니.. 이건 64비트 컴퓨팅이 선사한 계륵 같은 경험이었다.

3. #include 절대경로 표시

요즘 개발툴 IDE, 에디터들은 코드에서 각종 명칭을 마우스로 가리키기만 하면 그게 선언된 곳이 어딘지를 친절하게 알려 준다. #define 매크로도 다 파악해서 이게 전개된 결과가 무엇인지도 툴팁 형태로 표시해 준다.
이와 관련해서 개인적으로는.. #include 다음에 이어지는 토큰을 마우스로 가리키고 있으면 얘가 무슨 파일을 가리키는지도 절대경로를 알려 주는 기능이 있으면 좋겠다. 이 파일을 여는 기능은 Visual Studio건 xcode건 이미 다 제공되고 있으니, 그렇게 알아낸 파일명을 가만히 표시만 해 주면 된다.

C/C++의 include 경로 찾기 규칙은 꽤나 복잡한 구석이 있기 때문이다. #define이 정의돼 있는 줄 모르고 삽질하는 것처럼, 예상하지 않은 다른 디렉터리에 있는 동명의 파일이 잘못 인클루드 되어 착오가 발생할 가능성이 있다.
이는 마치 경로를 생략하고 파일명만 달랑 입력했을 때 실행 파일 디렉터리를 탐색하는 순서라든가 LoadLibrary 함수가 DLL의 경로를 탐색하는 순서와도 비슷한 면모이다.

#include로 지정하는 경로는 C/C++ 문법의 지배를 받는 문자열 리터럴이 아니다. ""로 둘러싸기 때문에 문자열 리터럴처럼 보이지만 <>로 둘러싸는 것도 가능하고.. 여기서는 역슬래시 탈출문자가 적용되지 않기 때문에 디렉터리 구분자를 지정할 때 \를 번거롭게 두 번 쓸 필요도 없다. 애초에 #include는 컴파일러가 전혀 아닌 전처리기의 영역이니 당연한 소리인데.. 가끔은 당연한 사실이 당연하게 와 닿지가 않는다.

그런데 #include 경로명에다가 매크로 상수를 지정할 수는 있다. 내가 지금까지 이런 기괴한 용례를 본 건 지금까지 FreeType 라이브러리의 소스가 유일하다. IDE가 이런 것까지 다~~ 파악해서 실제로 인클루드 되는 헤더 파일을 사용자에게 알려준다면 코드를 분석하는 데 큰 도움이 될 것이다.

4. 리터럴 형태의 표현

프로그래밍 언어가 표현력이 좋으려면, 함수 코드든지 재귀성을 지난 복잡한 데이터든지(리스트, 배열 테이블 등) 불문하고 하나의 리터럴 내지 값(value)로 취급 가능하며, 굳이 이름을 붙여서 변수로 할당하지 않아도 함수 인자나 리턴값으로 자유자재로 주고 받고 대입 가능해야 한다.
쉽게 말해 함수 포인터가 들어갈 곳에 이렇게 함수 몸체가 곧장 들어갈 수 있어야 하며..

qsort(pData, nElem, nSize, [](const void *a, const void *b) { return 어쩌구저쩌구 } );

데이터가 들어갈 곳에도 이렇게 배열을 즉석에서 지정할 수 있어야 한다는 얘기이다.

memcpy(prime_tbl, {2,3,5,7, 11}, sizeof(int)*5);

하지만 C/C++은 이런 쪽의 유연한 표현력이 매우 취약했다.
함수 쪽은 machine word 하나에 딱 대응하는 것 이상의 context를 담은 추상적인 포인터를 지원하지 않는 관계로 클로저나 함수 안의 함수 따위를 지원하지 않는다.

그리고 언어 차원에서 복합 자료형을 built-in type으로 직접 지원하는 게 없다. 전부 프로그래머나 라이브러리의 구현에 의존하지..
그렇기 때문에 복잡한 데이터 리터럴은 변수를 초기화하는 이니셜라이저 형태로나 아주 제한적으로 표현 가능하며 이마저도 구조체· 배열의 초기화만으로 한정이다. 리터럴 형태 표현 가능한 배열 비스무리한 건 읽기 전용 null-terminated 문자열이 고작이다.

함수를 리터럴 형태로 표현하는 건 C++에 람다와 함수형 패러다임이 도입되면서 상황이 많이 나아졌다.
그 뒤 복합 자료형을 리터럴 형태로 표현하는 것도 C++1x 이후로 하루가 다르게 새로운 문법이 도입되면서 바뀌고 있긴 하다.

이름을 일일이 붙이지 않고 아무 테이블 및 계층 자료구조, 그리고 함수를 마음대로 선언해서 함수의 인자나 리턴값으로 주고받을 수 있는 것은..
마치 메신저나 이메일로 스크린샷 그림을 주고받을 때 매번 그림을 파일로 저장하고 그 파일을 선택하는 게 아니라 간단히 print screen + 클립보드 붙여넣기만으로 그림 첨부가 되는 것과 비슷하다. 의식의 흐름을 매우 편리하고 직관적으로 코딩으로 표현 가능하게 해 준다.

디자인 근본적인 차이로 인해 C++이 무슨 파이썬 수준의 유연함을 갖는 건 무리이겠지만 저 정도만으로도 엄청난 변화이며 한편으로 컴파일러를 구현하기에는 굉장히 난감할 것이다. 저수준 성능과 고수준 추상화 범용성이라는 두 모순되는 토끼를 몽땅 잡아야 하기 때문이다. 특히 그런 문법이 템플릿 내지 캐사기 auto와 결합하면.. 복잡도가 끔찍할 수준일 것 같다.

5. 기타

(1) 변수나 함수를 선언할 때는 type을 지정하면서 각종 modifier나 storage class를 같이 써 주게 된다. 거기에 들어가는 단어 중에는 static과 const, 그리고 int와 __declspec(..)처럼 대충 순서가 바뀌어도 되는 것이 있다.
그런데 long unsigned a도 된다는 것은 지난 20여 년 동안 본인이 한 번도 시도해 본 적이 없었다. 영어 어순 직관과 어울리지 않으니까.. 하긴, 2[a]도 되는 언어에서 저 정도쯤이야 이상할 게 없다.

(2) void main(void) {}은 컴파일은 되지만 void가 뭔가 권장되지 않고 바람직하지 않은 형태로 쓰이는 전형적인 예시라 하겠다. main 함수의 프로토타입도 그렇고, 또 함수에 인자가 없음을 나타낼 때는 C/C++ 가리지 않고 ()만 써도 충분하기 때문이다.

(3) 잘 실감이 나지 않겠지만 요즘은 C와 C++은 서로 따로 제 갈 길 가고 있다. 특히 C99와 C++1x부터 말이다. 그렇기 때문에 세월이 흐를수록 C 코드를 C++ 컴파일러에서 곧바로 돌리기는 어려워질 것이다.

보통은 C가 C++에 있던 // 주석, inline 키워드, C++ 라이브러리에 있는 몇몇 기능들을 자기 스타일로 도입하는 형태였지만 최신 C에서 C++과 무관하게 독자적으로 도입한 기능 중 하나는 restrict 키워드이다. 얘가 가리키는 메모리 주소는 딴 데서 건드리지 않으니 마음 놓고 최적화해도 된다는 일종의 힌트이다. volatile과는 반대 의미인 듯하다.

컴파일러에 따라서는 C++에서도 얘를 __restrict 이런 형태의 비표준 확장으로 도입한 경우가 있다. 하지만 Visual C++은 내가 알기로는 그리하지 않은 것 같다. 마소 컴파일러는 C 단독은 거의 없는 자식 취급하고 C99 지원도 안 하고 있으니 말이다.

(4) 방대한 C/C++ 코드에 정적 분석을 돌려 보면, 아무 type-safety 단서 없이 무데뽀로 아무 메모리에다 임의의 바이트만치 쓰기를 허용하는 memset, memcpy 계열의 함수에 실수와 버그가 들어간 경우가 생각보다 굉장히 많다고 한다.
배열 크기만큼 써야 하는데 포인터 크기(4/8바이트!)만치만 기록해 버리는 건 약과다. 둘째 인자와 셋째 인자의 순서가 바뀌어서 0을 기록하는 게 아니라 0바이트만치만 기록한다거나..;;

sizeof(A)*b라고 써야 할 것을 실수로 sizeof(A*b)라고 써 버려서 역시 4/8바이트 고정과 같은 효과가 나기도 한다. 전체 바이트 수를 써야 하는 곳과 배열의 원소 수만 써야 하는 곳을 헷갈리는 것도 미터나 피트 같은 단위를 헷갈려서 착오를 일으킨 것과 비슷하다.
문제는 저런 건 잘못 써도 언어 문법상으로는 아무 잘못이 없고 철저하게 합법이라는 것이다. 컴파일러가 잡아 주지 못하니 더 고차원적으로 문맥을 읽는 정적 분석에 의존해야 한다.

Posted by 사무엘

본인은 최근에 직장일 때문에 이메일을 자동으로 생성해서 보내는 프로그램이란 걸 난생 처음으로 작성해 봤다. 소켓 API만 써서 말이다.
서식이고 첨부고 몽땅 다 생략한 최소한의 형태만 생각한다면, 이메일을 보내는 것 자체는 내 예상보다 굉장히 간편하게 쉽게 자동화할 수 있는 일이라는 걸 알 수 있었다. SMTP 서버 명령어 몇 개만 스펙대로 주고 받으면 된다.

발신자는 말할 것도 없고 수신자조차도 실제로 수신하는 대상과 화면에 표시되는 수신자가 서로 다르게 얼마든지 조작 가능하다. 스팸 메일을 대량으로 살포하는 건 일도 아니겠다는 걸 이제야 느꼈다. 이런 문제도 있고, 또 이메일 내용을 다른 해커가 가로챌 수도 있으니 이 바닥에도 온갖 복잡한 인증과 암호화 계층이 나중에 도입된 거지 싶다.

이메일과 관련하여 서버에다 요청을 보낼 때는 줄 바꿈 문자가 \n이 아니라 반드시 \r\n을 써야 한다는 게 인상적이었다. 이건 어째 유닉스가 아닌 DOS/Windows 진영의 관행과 일치한다. 그리고 메일 본문의 끝을 의미하는 게 도스의 copy con이 사용하는 Ctrl+Z 같은 제어 문자가 아니라 그냥 "빈 줄+마침표+빈 줄"이다.

또 주목할 만한 것은 DATA(본문)에 들어가는 발신 날짜였다. 난 메일을 보내면 발신 시각 정도는 메일 서버가 자기 시각을 기준으로 당연히 자동으로 넣어 줄 거라고 생각했다. 사람이 이메일을 보낼 때 발신 시각을 일일이 써 넣지 않듯이 말이다.
하지만 내부적으로는 그렇지 않았다. 보내는 쪽에서 알려 줘야 하며, 허위로 조작된 임의의 날짜· 시각을 보내는 것도 얼마든지 가능하다.

그리고 여기에 써 주는 날짜· 시각은 "Tue, 18 Nov 2014 13:57:11 +0000" 같은 형태로, 날짜와 시각, time zone을 모두 포함하고 있다. 심지어 요일이라는 일종의 잉여 정보도 있다.
이 형식은 RFC 2822에 표준 규격으로 정해졌는데, 보다시피 사람이 읽기 편하라고 만들어졌지 컴퓨터의 입장에서 간편하게 읽고 쓸 수 있는 형식은 아니다. 컴퓨터의 관점에서는 그냥 1970년 1월 1일 이래로 경과한 초수, 일명 Unix epoch 숫자 하나가 훨씬 편할 텐데 말이다. time zone도 무시하고 UTC만 통용시키고 말이다.

실제로 이 날짜· 시각 문자열은 그 형태 그대로 쓰이지 않는다. 어차피 이메일 클라이언트가 파싱을 해서 내부적으로 Unix epoch 같은 단순한 형태로 바꿔야 한다. 그래야 당장 메일들을 오래된 것-새것 같은 순서대로 정렬해서 목록을 뽑을 수 있을 테니 말이다. 또한 그걸 출력할 때는 "2014년 11월 18일 오후 10시 57분 11초"처럼 사용자의 언어· 로케일과 설정대로 형태가 또 바뀌게 된다.

그러니 사람보다는 기계가 더 활용하는 날짜 시각 문자열 포맷이 왜 저렇게 복잡한 형태로 정해진 건지 의문이 들지 않을 수 없다. 읽고 쓰기 위해서 달 이름과 요일 이름 테이블까지 참조해야 하고 말이다. 글쎄, SMTP 명령어를 사람이 직접 입력해서 이메일을 보내던 엄청난 옛날에 사람이 읽고 쓰기 편하라고 저런 형태가 정해진 건지는 모르겠다.

Windows API의 GetDateFormat/GetTimeFormat 내지 C 언어의 asctime/ctime 함수 어느 것도 이메일의 날짜· 시각 포맷과 완전히 일치하는 문자열을 되돌리지는 않는다. 특히 C 함수의 경우,

Tue Nov 18 13:57:11 2014

로, 년월일 시분초 요일까지 정보가 동일하고 맨 처음에 요일이 나오는 것까지도 일치하지만.. 이메일 포맷과는 일치하지 않는다. C 함수도 나열 순서와 글자수가 언제나 동일하고 불변인 것이 보장돼 있기 때문에 저걸 변경할 수는 없다. 저 결과값을 그대로 쓸 수도 없으니 답답하기 그지없다.

참고로 일반인이 저런 날짜· 시각 format 함수를 작성한다면 그냥 단순무식하게 sprintf "%02d %s" 같은 방식으로 코딩을 하겠지만, 프로그래밍 언어 라이브러리에서는 그런 짓은 하지 않고 성능을 최대한 중요시하여 각 항목들을 써 넣는 것을 한땀 한땀 직접 구현한다. 해당 라이브러리의 소스를 보면 이를 확인할 수 있다.

Windows API에는 SYSTEMTIME이라는 구조체가 있고, C에는 tm이라는 구조체가 있어서 날짜와 시각을 담는 역할을 한다. 그런데 tm이라니.. 구조체 이름을 무슨 변수 이름처럼 참 이례적으로 짧고 성의없게 지은 것 같다. -_-
C 시절에는 앞에 struct라는 표식을 반드시 덧붙이기라도 해야 했지만 C++은 그런 것도 없으니 더욱 난감하다. C++의 등장까지 염두에 뒀다면 이름을 절대로 저렇게 지을 수 없었을 것이다.

또한 tm 구조체의 멤버들 중 월(tm_mon)은 1이 아니라 0부터 시작한다는 것, 그리고 연도(tm_year)는 실제 연도에서 1900을 뺀 값을 되돌린다는 것도 직관적이지 못해서 번거롭다. 즉, 2019년 7월은 각각 119, 6이라고 기재된다는 것이다. 그에 반해 Windows의 SYSTEMTIME은 그렇지 않으며 wYear과 wMonth에 실제값이 그대로 들어가 있다.

월이 0부터 시작하는 건 쟤네들 문화권에서는 어차피 월을 숫자가 아닌 이름으로 취급하기 때문에 배열 참조의 편의를 위해서 그렇게 했을 것이다. 그런데 연도는.. 무슨 공간을 아끼려고 굳이 1900을 뺐는지 모르겠다. 16비트 int 기준으로 서기 32767년만 해도 정말 까마득하게 먼 미래인걸 말이다.

아 하긴, 20세기 중후반엔 연도의 마지막 두 자리(10과 1)만 써도 70이니 90이니 하면서 월과 일의 숫자 범위보다 월등히 컸기 때문에 변별력이 있었다. 연도도 두 자리만 쓰는 게 관행이었기 때문에 1900을 빼는 것은 그런 관행을 반영한 조치였을 것이다. Office 97은 있어도 Office 07은 없고 2007이니까 말이다.

엑셀 같은 스프레트시트들도 날짜 겸 시각을 저장하는 자료형의 하한이 1900년 1월 1일로 잡혀 있다. 그래서 한국 최초의 철도가 개통한 1899년 9월 18일 같은 날짜는 아슬아슬하게 날짜형으로 저장하지 못하며, 일반 문자열로만 취급된다. =_=;;

이렇게 인간 가독형 날짜· 시각 말고 기계 가독형으로 직렬화된 날짜· 시각을 저장하는 정수 자료형으로 Windows에는 FILETIME이 있고, C에는 time_t가 있다. FILETIME은 Windows NT 시절부터 64비트로 시작했지만 후자는 2000년대 이후에 와서야 2038년 버그를 미연에 방지하기 위해 각 플랫폼별로 64비트로 확장됐다. 사실, 이때부터 PC도 64비트로 바뀌어서 플랫폼에 따라서는 long 같은 자료형도 64비트로 바뀌기도 했다..

그리고 요일이야.. 두 구조체 모두 일요일이 0이고 토요일이 6이다.
요일도 이름이 아닌 숫자로만 취급하는 언어는 내가 알기로 중국어밖에 없는데 혹시 더 있는지 궁금하다. 물론 인간의 언어에는 설마 0요일이 있을 리는 없고 1부터 시작할 텐데.. 중국어의 경우 일요일은 日이어서 이게 0 역할을 하고, 월요일부터 토요일까지가 1요일~6요일에 대응한다.

이상이다. 이메일 얘기로 시작해서 날짜 시각 얘기로 소재가 바뀌었는데..
이메일(POP3/SMTP)을 비롯해 HTTP, FTP 같은 표준 인터넷 프로토콜들을 클라이언트와 서버를 모두 소켓 API만으로 직접 구현해 보는 건 코딩 실력의 향상에 도움이 될 것 같다. 일상생활에서야 이미 만들어져 있는 솔루션만 사용하면 되니까 실용적인 의미는 별로 없겠지만, 학교에서 학술..도 아니고 그냥 교육적인 의미는 충분히 있을 테니 말이다. 내부 구조를 직접 살펴보면, 이런 프로토콜의 secure 버전이 왜 따로 만들어져야 했는지 이유도 알게 될 것이다.

더구나 이를 응용해서 특정 메일에 대해 자동 회신을 보내는 프로그램, 한 FTP 서버의 파일을 다른 FTP 서버로 올리는 프로그램까지 만드는 건 시험이나 과제 용도로도 괜찮아 보인다. 요즘은 FTP 같은 거 명령어로 이용할 줄 아는 사람이 얼마나 될까? 당장 본인도 모른다. ㅎㅎ

이메일을 쓰지 않는다는 도널드 커누쓰 할배가 문득 생각난다. 이분이야 뭐 1970년대, 컴퓨터 네트워크라는 건 그냥 기업· 연구소, 정부 기관만의 전유물로 여겨졌고 이메일이란 게 처음으로 발명됐던 시절에 그걸 다뤄 왔던 분이다. 그러다가 현역 은퇴 후에 때려치우고 온라인 공간의 속세와 단절한 셈이다. 이젠 뭐가 아쉬워서 누구에게 이메일로 연락을 하거나 연락을 기다려야 할 처지도 전혀 아니고.. 그냥 아날로그 종이 편지를 취급하는 것만으로 충분하시댄다.

Posted by 사무엘

C/C++은 어떤 명칭에 대해 선언과 정의의 구분이 명확한 축에 드는 언어이다. 정의는 선언도 같이 포함하지만 그 역은 성립하지 않는다. 전자는 심판의 선고이고, 후자는 집행이라고 봐도 되겠다.

(1) 함수: 실행되는 코드를 담고 있기 때문에 {}에 둘러싸여 정의된 몸체의 존재감이 압도적인 물건이다. 또한 함수의 선언부는 자신의 프로토타입(인자의 개수와 타입, 리턴값의 타입)을 나타내기도 한다. 그렇기 때문에 얘는 소형 인라인 형태가 아닌 이상, 선언과 정의의 구분이 가장 명확하다.

(2) 자료형: 구조체나 클래스는 함수보다야 선언 따로 정의 따로일 일이 훨씬 드물다. 하지만 헤더에서는 포인터 형태만 사용하는데 쓸데없는 #include 의존성을 또 만들지 않기 위해 class Foo; 같은 불완전한 타입을 선언만 하는 게 가능은 하다. 마치 함수 선언처럼 말이다.
선언만 존재하는 불완전한 타입은 sizeof 연산자를 적용할 수 없으며, 포인터형의 경우 *나 ->로 역참조해서 사용할 수도 없다.

(3) static 멤버/전역 변수: 변수는 선언하는 것 자체 말고 딱히 {}로 둘러싸인 세부 정의가 존재하지 않는다. 생성자 인자라든가 초기화 값(initializer)이 쓰이긴 하지만 그건 definition, body와는 성격이 완전히 다른 정보이니 말이다.

다만, 지역 변수 말고 클래스의 static 멤버에 대해서는 static int bar와 int Foo::bar 같은 선언/정의 구분이 존재한다. 그리고 전역 변수도 extern이라고 선언된 놈은 정의가 아닌 선언 껍데기일 뿐이다. (실제 definition은 다른 translation unit에 존재한다는..)
사실, global scope에서 함수의 선언도 앞에 extern이 생략된 것이나 마찬가지이다. 지역 변수의 선언들이 모두 구 용법의 auto가 생략된 형태인 것처럼 말이다.

함수건 변수건 선언은 여러 군데에서 반복해서 할 수 있지만 몸체 정의는 딱 한 군데에만 존재한다. 이는 마치 분향소와 빈소의 관계와도 비슷해 보인다.
이런 선언부에서는 배열의 경우 그 구체적인 크기를 생략할 수 있다. * 대신 []을 써서 얘는 정확한 크기는 모르지만 어쨌든 포인터가 아닌 배열이라고 막연하게 선언할 수 있다는 것이다. 그리고 const 변수는 초기화 값이 선택이 아니라 필수인데, 이 역시 선언 단계에서 생략될 수 있다.

1. 함수와 구조체: 상호 참조를 위한 불완전한 전방 선언

(1) 함수나 (2) 구조체/클래스는 상호 참조를 할 수 있다. A라는 함수에서 B를 호출하고, B도 A를 호출할 수 있다. 또한, X라는 구조체에서 Y라는 구조체의 포인터를 멤버로 갖는데, Y도 내부적으로 X의 포인터를 갖고 있을 수 있다.

요즘 프로그래밍 언어들은 구조적으로 같은 소스 코드를 두 번 읽어서 파싱하게 돼 있기 때문에 한 함수에서 나중에 등장하는 다른 함수를 아무 제약 없이 참조할 수 있다. C++도 그런 요소가 있기 때문에 한 클래스의 인라인 멤버 함수에서 클래스 몸체의 뒷부분에 선언된 명칭에 곧장 접근할 수 있다. 즉, 다음과 같은 코드는 컴파일 된다.

class Foo {
public:
    void func1() {
        func2();
    }
    void func2() {
        func1();
    }
};

하지만 global scope에서 이런 코드는 적어도 C++ 문법에서는 허용되지 않는다.

void Global_Func1() {
    Global_Func2();
}
void Global_Func2() {
    Global_Func1();
}

맨 앞줄에 void Global_Func2(); 이라고 Global_Func2라는 명칭이 껍데기만이라도 forward(전방) 선언돼 있어야 한다. 파스칼 언어에는 이런 용도로 아예 forward라는 지정자 키워드가 있기도 하다.
매우 흥미로운 것은..

struct DATA1 {
    DATA2* ptr;
};
struct DATA2 {
    DATA1* ptr;
};

이렇게 구조체끼리 상호 참조를 하기 위해서는..
심지어 클래스 안의 구조체라 하더라도 앞에 struct DATA2는 반드시 미리 전방 선언이 돼 있어야 한다는 것이다. 클래스 안에 선언된 멤버 함수와는 취급이 다르다. 왜 그런 걸까? 멤버 함수의 몸체는 클래스 밖에 완전히 따로 정의될 수도 있지만 구조체의 몸체는 그럴 수 없다는 차이 때문인 듯하다.

원래 파스칼과 C는 옛날에 컴파일러의 구현 난이도와 동작 요구 사양을 낮추기 위해, 소스 코드를 한 번만 읽으면서 곧장 parsing이 가능하게 설계되기도 했다. 모든 명칭들은 사용되기 "전에" 정의까지는 아니어도 적어도 선언은 미리 돼 있어야 컴파일 가능하다. 아무 데서나 '정의'만 한번 해 놓으면 아무 데서나 그 명칭을 사용할 수 있는 그런 자유로운 언어가 아니라는 것이다.

함수와 전역 변수의 경우, 그 다음으로 몸체 정의를 찾아서 실제로 '연결'하는 건 잘 알다시피 링커가 할 일이다. 단지, 구조체/클래스는 몸체가 당장 컴파일 과정에서 그때 그때 쓰이기 때문에(멤버의 타입과 오프셋...) 링크가 아닌 컴파일 단계에서 실제 몸체를 알아야 한다는 차이가 있다.

불완전한 타입에 대해서 거기에 소속된 구조체/클래스를 불완전한 형태로 또 중첩 선언하는 것은 가능하지 않다.

class A;
class A::B;

A의 몸체를 모르는 상태에서 연쇄적으로 B를 저렇게 또 선언할 수는 없다는 것이다. 그걸 허용하는 건 C++을 동적 타입 언어급으로 만드는 너무 사악한(?) 짓이 될 것 같다. 특히 이미 자유도가 너무 높은 템플릿을 구현하는 것까지 생각했을 때 말이다.
실체가 없는 저런 자료형의 포인터를 무리하게 만들 바에야 아예 void* 포인터를 그때 그때 캐스팅해서 쓰고 말겠다. 아니면, 저런 식으로 다단계 scope 구분만 하는 게 목적이라면 클래스 대신 namespace라는 훌륭한 대체제가 있다.

2. 구조체: 전방 선언과 다중 상속 사이의 난감함

이렇게 몸체를 모르는 클래스를 불완전 전방 선언만 해서 쓰는 것은 일면 편리하지만.. C++이 제공하는 다른 기능 내지 이념과 충돌해서 난감한 상황을 만들 때도 있다.
즉, class X와 class Y라고 이름밖에 모르던 시절에는 X와 Y는 서로 완전히 남남이며, 포인터 형변환도 오프셋 보정 없이 단순무식한 C-style로만 하면 된다.

그런데 알고 보니 X와 Y가 다중 상속으로 얽힌 사이라면.. 몸체를 모르던 시절과 알고 난 뒤의 컴파일러의 코드 생성 방식이 서로 달라질 수밖에 없다. 특히 X 내지 Y의 멤버 함수를 가리키는 pointer-to-member 타입의 크기와 구현 방식도 달라지게 된다. X가 전방 선언만 돼서 아무런 단서가 없을 때가 제일 복잡하고 까다롭다.

Visual C++의 경우, 얘가 전방 선언만 됐지만 다중/가상 상속 같은 것 안 쓰는 제일 단순한 형태이기 때문에 pointer-to-member도 제일 단순한 형태로만 구현해도 된다고 단서를 제공하는 비표준 확장 키워드를 자체적으로 제공할 정도이다. 그만큼 C++의 스펙은 복잡 난해하고 패러다임이 서로 충돌하는 면모도 존재한다.

이렇듯, 명칭의 선언과 정의라는 간단한 개념을 고찰함으로써, C/C++ 이후의 언어들은 선배 언어의 복잡 난해함을 어떻게든 감추고 사용자와 컴파일러 개발자의 입장에서 다루기 편한 언어를 만들려고 어떤 개량을 했는지를 알 수 있다. 당장 Java만 해도 헤더/소스 구분 없이 한 클래스에서 각종 함수나 명칭을 수정하면 번거로운 재컴파일 없이도 그걸 다른 소스 코드에서 곧장 사용 가능하니 얼마나 편리한가 말이다.

3. 함수: extern "C"

앞서 살펴본 바와 같이 extern은 static library 형태이든 DLL/so 방식이든 무엇이건, 외부로 노출되는 전역 함수 및 변수 명칭을 선언하는 키워드이다. 그런데 기왕 대외 선언을 하는 김에 노출을 하는 방식도 옵션을 줘서 같이 지정할 수 있다.
모르는 사람에게는 굉장히 기괴해 보이는 문법인 extern "C"가 바로 그것이다. 이건 함수 명칭을 C++ 스타일로 decorate를 할지, 아니면 예전의 C 시절처럼 원래 이름을 변조 없이 그대로 선언할지를 지정한다.

C++에서 변조니 decorate니 해서 굳이 언어의 ABI 차원에서 호환을 깨뜨려야 하는 이유는.. C++에는 C와 달리 함수 인자를 기반으로 오버로딩이 존재하기 때문이다. 그러니 argument의 개수와 타입들에 대한 정보가 이름에 첨가돼야만 이 함수를 그 이름으로 유일하게 식별할 수 있다.

뭐, static 함수는 대외 노출이 아니니 한 번역 단위 안에서 함수 이름이야 어떻게 붙이건 전혀 상관없으며.. C++ 클래스 멤버 함수는 애초에 C언어에서 접근 불가능한 물건이이고 무조건 C++ 방식으로 decoration을 해야 한다. 그러니 extern "C" 옵션이 필요한 곳은 C와 C++이 모두 접근 가능한 일반 전역 함수 정도로 한정된다.

"C" 말고 쓸 수 있는 문자열 리터럴은 "C++".. 요 둘뿐이다. 그리고 "C++"은 디폴트 옵션이므로 signed만큼이나 잉여이고, 오늘날까지도 사실상 "C"만 쓰인다.
만들고 있는 라이브러리가 자기 제품 내부에서밖에 안 쓰이거나, 어차피 소스째로 통째로 배포되는 오픈소스여서 특정 컴파일러의 ABI에 종속되어도 아무 상관 없다면.. 함수를 C++ 형태로, 아니 C++ 클래스 라이브러리 형태로 선뜻 만들 수 있을 것이다.

그게 아니라면 외부 노출 함수 이름은 어느 언어에서나 쉽게 import 가능한 extern "C" 형태로 만드는 게 일반적이다. extern "C" 다음에는 이 구간에서 선언되는 명칭들을 모두 C 방식으로 노출하라고 중괄호 {}까지 줄 수 있으니 생소함과 기괴함이 더해진다.

이건 컴파일러의 구문 분석 방식을 변경하는 옵션이 아니다. {} 안의 코드는 C 문법으로만 해석하라는 말이 절대 아니다. extern "C" 방식으로 선언된 함수의 안에서도 템플릿, 지역 클래스 등 C++ 문법은 얼마든지 사용할 수 있고 타 C++ 객체를 참조할 수 있다. 단지 이 함수는 동일 명칭의 여러 오버로딩 버전을 만들어서 대외적으로 제공할 수 없을 뿐이다.

또한, 컴파일러의 최적화나 코드 생성 방식에 영향을 주지도 않는다. stdcall, pascal, cdecl 같은 calling convention이야 인자를 스택에다 올리는 순서 내지 스택 주소 복귀를 하는 주체(caller or callee)를 지정하는 것이니까 코드 생성 방식에 영향을 준다. 언어 문법 차원에서의 프로토타입이 동일하더라도 calling convention이 다른 함수끼리는 포인터가 서로 호환되지 않는다.
그에 반해 extern "C" 지정이 잘못되면 obj와 lib 사이에 공급된 명칭과 요청한 명칭이 일치하지 않아서 끽해야 링크 에러가 날 뿐이다. 개념이 이렇게 정리된다.

Posted by 사무엘

1. 문법 함정

C/C++에서 연산자로 쓰이는 토큰(문자)들 중에는 문맥에 따라서 의미가 중복될 수 있는 것이 있다.
예를 들어 * () [] 같은 토큰은 값을 계산하는 수식에서 쓰일 때와, 변수를 선언할 때 의미가 서로 다르다. 한쪽에서는 인근의 변수가 배열· 포인터· 함수 타입임을 나타내지만, 다른 쪽에서는 실제로 배열 첨자나 포인터를 역참조하고 함수를 호출하는 역할을 한다.

심지어 =조차도 int a=5; 와 그냥 a=5; 에서 =는 문법적인 의미가 서로 동일하지 않다. 똑같이 =를 썼더라도 중괄호를 동원하여 배열이나 구조체를 초기화하는 것은 일반 수식에서는 가능하지 않기 때문이다.

이런 것 말고도 콤마(,)의 경우.. 함수 인자 구분자와 쓰임이 완벽하게 겹친다. 그렇기 때문에 함수 인자에서 콤마 연산자를 쓰려면 수식을 괄호로 싸야 한다.

그리고 <>로 둘러싸인 템플릿 인자에서 부등호 내지 비트 이동 연산자를 쓸 때도 상황이 좀 난감해진다. 템플릿 인자에 typename만 올 때는 <>가 모호성을 전혀 일으키지 않지만, 문제는 템플릿 인자로 정수도 들어올 수 있다는 것이다. 그리고 값이 컴파일 타임 때 결정만 될 수 있다면 정수값을 만들어 내는 각종 연산자들도 당연히 쓰일 수 있다.

template class Foo<size_t N> { .... };

Foo<(a>b ? 5:3)> bar1;
Foo<(MAX>>3)> bar2;

그러니 위와 같은 상황에서는 수식 전체를 괄호로 싸야만 한다. 괄호가 단순히 같은 수식 안에서 연산 우선순위를 조절할 때만 쓰이는 게 아니라는 점이 흥미롭다. 수식 영역과 함수 및 템플릿 인자 영역을 구분할 때도 쓰인다.

std::vector<std::list<int>> vl;

요렇게 중첩되었던 템플릿 인자들이 한꺼번에 종결될 때 > 사이를 강제로 띄우지 않아도 되게 컴파일러의 동작 방식 지침이 달라진 때가 내 기억이 맞다면 C++03과 C++11사이였지 싶은데.. 정확하게는 모르겠다.

그 밖에 2[a]가 가능하다는 C/C++의 변태적인 특성상, 람다와 관련해서 또 변태 같은 중의성을 만들 수 있지는 않으려나 궁금한데, 너무 머리가 아파서 더 생각해 보지는 않으련다.
요즘 C++은 auto라든가 using, delete를 보면 =를 사용하는 새로운 문법이 여럿 생긴 것 같다.

2. 비표준이지만 표준처럼 쓰이는 함수

C언어 라이브러리에 있는 모든 함수들이 100% 표준이고 어느 플랫폼에서나 동일하게 사용 가능한 게 아니다.
본인은 평소에 Visual C++만 쓸 때는 이런 걸 전혀 의식하지 않고 지냈는데.. strlwr과 심지어 내 기억이 맞다면 strdup도 macOS에서는 지원되지 않는 걸 최근에 확인하고는 놀랐었다.
물론 저런 함수들이야 하는 일이 워낙 간단하니 3분 만에 직접 짤 수도 있다. 하지만 핵심은 저건 universal한 표준이 아니라는 것이다.

Visual C++도 세월이 흐를수록 '표준 준수'를 강조하는 쪽으로 라이브러리의 디자인이 바뀌다 보니, 관례적으로 제공되긴 했지만 엄밀히 말해 표준이 아닌 함수들에 대해서는 앞에 밑줄을 붙여서 구분하는 추세이다.
하긴 그러고 보니, Visual C++을 업그레이드 한 뒤에 기존 코드가 컴파일되지 않아서 수정하던 내역 중에도 멀쩡한 함수 앞에다가 _를 붙이는 게 많았다. 일례로, 이분 검색 함수는 bsearch가 당당히 표준으로 등재돼 있지만, 그에 상응하는 선형 검색 함수는 표준이 아니어서 그런지 _lfind이다.

3. 스택 메모리의 임의 할당

그러고 보니 비표준 함수 중에는.. malloc의 변종으로서 가변 길이(= 크기가 런타임 때 정해지는) 메모리를 heap이 아닌 무려 현재의 스택 메모리에서 얻어 오는 alloca이던가 malloca인가 하는 물건도 있었다. 옛날 16비트 Turbo C에만 있는 줄 알았는데 현재의 Visual C++에서도 지원은 하는가 보다. 물론 앞에 밑줄은 붙여서 말이다.

얘는 C에서 문법적으로 가능하지 않은 동적 배열을 heap이 아닌 스택 메모리에 구현해 준다. 메모리 할당 속도가 heap을 다루는 것보다 훨씬 더 빠르며, 함수 실행이나 scope이 끝날 때 해제도 자동으로 되어 memory leak 걱정을 할 필요 없으니 편리하다. 지금 실행 중인 함수의 stack frame을 조작하는 물건이니, 겉으로는 함수 호출 같지만 실제로는 컴파일러 인트린식 형태로 구현되지 싶다.

이렇게 생각하면 얘는 장점이 많아 보이지만.. 일단 할당 장소가 장소인 관계로 (1) 수 MB 이상급의 대용량 메모리를 할당할 수 없으며, (2) 할당 방식의 특성상 heap 메모리처럼 할당과 해제를 무순으로 임의로 자유자재로 할 수 없다. (3) C++ 언어의 보조를 받는 게 없기 때문에 해제와 C++ 객체 소멸을 한데 연계할 수도 없다.

이런 한계로 인해 스택에서의 동적 메모리 할당은 생각만치 그렇게 유용하지 않다. 본인도 지난 20여 년 동안 C/C++ 프로그래밍을 하면서 이걸 사용해 본 적이 전혀에 가깝게 없었다.
저 함수가 괜히 비표준이 아닌 셈이다. 마치 정수 기반 고정소수점과 비슷한 위상의 이단아인 것 같다. 다만, 그럼에도 불구하고 본인은 이런 상황은 어떨까 하는 생각을 해 보았다.

생성자에서 문자열을 인자로 받아들여 적절한 처리를 하는 기반 클래스가 있다.
이걸 상속받아 파생 클래스가 만들어졌는데, 얘는 자주 쓰이는 문자열 패턴을 손쉽게 생성하기 위해 여러 개의 문자열이나 숫자를 숫자를 인자로 받으며, 이로부터 단일 문자열을 생성하여 기반 클래스의 생성자에다가 전달한다. 즉, 이런 꼴이다.

Derived::Derived(string arg1, string arg2, int num):
 Base( prepareArgument(arg1, arg2, num) ) {}

예시를 보이기 위해 편의상 string이라는 자료형을 썼지만, 실제로 저기서 쓰이는 것은 const char * 같은 문자열 포인터이다.
즉, 나는 Derived의 생성자에서 char buf[128] 같은 스택 기반 지역변수 배열을 선언한 뒤, 거기에다 arg1, arg2, num의 정보를 담고 있는 문자열을 담고 그걸 Base의 생성자에다가 전달하고 싶으나.. 문법 구조상 그건 가능하지 않다. 기반 클래스는 파생 클래스의 생성자가 실행되기 전에 초기화가 완료돼야 하기 때문이다. 그러니 파생 클래스의 생성자 함수에서 확보해 놓은 스택 변수의 공간을 받을 방법도 존재하지 않는다.

이럴 때 prepareArgument(_alloca(len), arg1, arg2, num) 이런 식으로 static한 보조 함수를 만들면 굳이 힙 메모리 할당과 생성자· 소멸자가 뒤따르는 범용 string을 쓸 필요 없이 스택에다가 문자열을 담을 공간을 임시로 확보하여 소기의 목적을 달성할 수 있을 것으로 보인다.

4. 쓰레기값

'초기화되지 않은 변수, 쓰레기값'이라는 건 내가 아는 프로그래밍 언어들 중에는 C/C++에만 존재하는 개념이다. 물론 컴퓨터라는 기계에 본질적으로 존재하니까 C/C++에도 존재하는 것이지만 말이다.
이것 때문에 야기되는 버그의 황당함과 막장스러움은 뭐, 이루 말로 형용할 수 없다. 같은 소스 코드가 release 빌드와 debug 빌드의 실행 결과가 달라지는 건 애교 수준이다. 프로그램이 미묘하게 삑사리가 나고 있어서 몇 시간을 끙끙대며 디버깅을 했는데 원인이 고작 이것 때문인 일이 비일비재하다.

개인적으로는 부모 클래스의 멤버가 초기화되지 않았는데 그걸 자식 클래스에서도 초기화하지 않은 것, 처음에는 0 초기화가 보장되는 static 영역에 있던 오브젝트를 별 생각 없이 스택/힙으로 옮긴 것, 심지어 한 멤버를 초기화할 때 아직 초기화되지 않은 다른 멤버를 참조해서 망한 것이 기억에 남아 있다.

간단한 int 지역변수가 초기화되지 않은 건 컴파일러 차원에서 잡아 주지만 위와 같은 사항들, 복잡한 구조체의 멤버가 일부 초기화되지 않는 것, 스택이 아닌 힙에서 할당하는 동적 메모리가 돌아가는 사정은 컴파일러도 일일이 다 챙겨 주지 못하기 때문에 더 복잡한 정적 분석의 영역으로 가야 한다.

그런데 개인적으로 의문이 드는 건 초기화되지 않은 쓰레기값이란 건 어느 정도로 무질서하냐는 것이다. 무슨 수학적으로 균일한 난수 수준일 리는 없을 것이다.
그 쓰레기들의 값에 영향을 주는 것은 정확하게 무엇일까? (스택이냐 힙이냐에 따라 다르게 생각해야 할 듯) 컴파일 시점에서 결정되어서 한번 빌드된 프로그램은 동일한 동작 조건에서는 불변인 걸까? 혹은 운영체제에 따라 달라질 수 있을까?

마치 중간값 피벗 기반의 퀵 정렬이 최고 시간 복잡도가 나오게 공격하는 방법을 연구하는 것처럼 저것도 뭔가 컴퓨터공학적인 고찰이 필요한 의문인 것 같다.

5. 메모리 주소의 align 문제

"어..? 구조체의 크기가 왜 각 구조체 멤버들의 크기의 합보다 더 크지? 컴파일러의 버그인가?"
본인이 이렇게 크게 놀랐던 게 벌써 20여 년 전, 고딩 시절에 도스용 DJGPP를 갖고 놀던 때였다.
그때는 지금 같은 구글 검색도 없고 네이버 지식인도 없고.. 이런 시시콜콜한 이슈를 다루는 C언어 서적도 없었으니, 궁금하면 물어 볼 만한 곳이 PC 통신 프로그래밍 관련 동호회 게시판밖에 없었다.

메모리 취급에 매우 관대한 x86 물에서만 놀던 사람이라면 word align이라는 개념이 더욱 생소할 수밖에 없다. 더구나 그 경계에 맞지 않은 단위로 메모리 접근을 시도할 경우, CPU가 귀찮아서 예외까지 날린다면??
본인은 포팅이라는 걸 할 때 word align을 조심해야 한다는 것을 머리로는 들어서 알았지만 그 문제를 회사에서야 실제로 겪었다.

이제 네이티브 코드는 반드시 ARM64 기반으로 빌드해야 하니 해당 부분을 64비트로 다시 빌드했다. 그런데 동일한 엔진을 얹은 안드로이드 앱이 어떤 기기에서는 잘 돌아갔는데 다른 기기에서는 뻗었다.
죽은 지점이 어딘지는 stack dump를 통해 알아낼 수 있었지만 거기는 null pointer, buffer overflow 등 그 어떤 통상적인 메모리 문제가 발생할 여지도 없는 곳이었다.

알고 보니 거기는 파일 형태로 기록하는 조밀한 버퍼에다 wcsncpy( reinterpret_cast<wchar_t*>(buf+1), str, len) 이런 짓을 하고 있었으며, 타겟 포인터가 한눈에 보기에도 wchar_t의 크기 대비 word align이 되어 있지 않았다(buf 는 char* ㄲㄲㄲ).
그래서 wcsncpy를 memcpy로 교체함으로써 문제를 해결할 수 있었다. wchar_t는 long과 더불어 포팅을 어렵게 하는 주범이며, reinterpret_cast는 align과 관련된 잠재적 위험성을 발견하는 용도로도 쓰일 수 있다는 점을 알게 됐다.

복잡한 포인터 메모리 조작 코드에서 잠재적인 align 문제를 잡아내는 건 사람의 디버깅만으로는 한계가 있을 텐데, 정적 분석으로 가능한지 궁금하다. 그리고 반대로 레거시 코드를 돌리기 위해 컴파일러가 성능이 떨어지는 걸 감수하고라도 최소한 뻗지는 않게 align 보정 코드를 집어넣어 주는 옵션도 있을 텐데 그것도 궁금해진다.

6. 32비트 단위 문자열

C/C++에서 wchar_t 크기의 파편화로 인해 야기된 혼란과 원성이 워낙 장난이 아니었기 때문에 C++11에서는 아예 크기를 직접 명시하고 고정시킨 char16_t와 char32_t라는 자료형이 built-in으로 추가되었다. int는 32비트 시대에 크기가 변했고 long은 64비트 시대에 플랫폼별로 삐걱거리기 시작했다면, wchar_t는 유니코드와 함께 새로 등장하면서 저 지경이 된 셈이다.

개인적으로 인상적인 것은 char32_t는 U""라고 문자열 리터럴을 나타내는 접두사까지 언어 차원에서 새로 등장했다는 점이다. 드디어 확장 평면 문자도 취급하기 더 수월해지겠다.
그런데 그러면 Visual C++이라면 ""는 1바이트, L""는 2바이트, U""는 4바이트라고 자연스럽게 연결되는데, 처음부터 wchar_t가 4바이트였던 맥에서는 L과 U가 모두 4바이트이다. char16_t에 대응하는 2바이트 문자열은 리터럴로 표현하는 방법이 없나 궁금하다. 오히려 Objective C에서 사용하는 NSString의 @""가 2바이트 문자열 리터럴이다.

char32_t가 언어 차원에서 이렇게 지원되기 시작했는데 str*, wcs*처럼 32비트 문자열 버전에 대응하는 strlen, strcpy, sprintf 등도 있어야 하지 않나 싶다. C++이라면 char_traits 템플릿으로 땜빵할 수도 있겠지만 C에는 그런 게 없으니까..
그리고 템플릿이 없는 저쪽 동네 Java는 32비트 단위 문자열을 취급하는 string class 같은 것도 있어야 하지 않을까? 문자 하나도 확장 평면까지 감안해서 얄짤없이 int로 표기하는 건 직관적이지 못하고 불편하니 말이다.

7. 레퍼런스 사이트

C/C++은 마소의 C#, 애플의 Swift, 썬-오라클의 Java처럼 한 기업이 주도해서 개발하는 언어가 아니다. 그래서 C++ 라이브러리 레퍼런스 같은 걸 검색해도 딱 떨어지는 개발사의 홈페이지가 곧장 나오지는 않는다.
하지만 수 년 전부터 구글 검색에서 상위권으로 노출되고 있는 유명한 사이트는 아래의 딱 두 곳인 것 같다.

http://www.cplusplus.com
https://en.cppreference.com/w

얘들은 개인? 단체? 어디서 운영하는지 모르겠다. C++17, C++20 같은 최신 정보도 곧장 올라오는 걸 보니 유지보수도 활발히 되고 있고 만만하게 볼 퀄리티가 아니다.
마치 Doom 게임 관련 자료를 듬뿍 얻을 수 있는 위키 사이트가 doomwiki와 doom.fandom.com 요 두 계열로 나뉘듯이 말이다.

Posted by 사무엘

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를 참조할 때는 레퍼런스 카운트를 건드리지 않아야 하기 때문이다.
순환 참조는 단순히 A→B→A뿐만 아니라 A→B→C→A 같은 더 복잡한 형태로도 발생하며, 일단 발생한 것을 감지하기란 몹시 난감하다. 그러니 weak_ptr이라는 개념이 반드시 필요하다.

그럼 reference count를 건드리지 않고 shared_ptr에 접근하려면 그냥 raw 날포인터를 얻어서 간단히 써도 될 텐데 굳이 weak_ptr이 따로 존재하는 이유는? 비록 ref count를 건드리지 않더라도 날포인터보다는 더 안전한 놈이 필요하기 때문이다.

weak_ptr은 다른 shared_ptr을 가리킬 수 있다.
shared_ptr은 자신과 동일한 shared_ptr로부터 참조받은 횟수와, weak_ptr로부터 참조받은 횟수를 따로 관리한다. 그렇기 때문에 shared_ptr은 이렇게 2개의 숫자로 이뤄진 레퍼런스 데이터도 따로 동적 생성해서 포인터로 가리키면서 동작한다.

weak_ptr이 가리키는 객체에 실제로 접근하려면 weak_ptr::lock()을 호출해서 weak로부터 shared_ptr을 잠시 생성해야 한다. 이 동안은 shared_ptr의 실제 레퍼런스 카운트가 증가하기 때문에 한쪽의 스마트포인터가 소멸되더라도 dangling pointer 현상이 발생하지 않는다. 이게 weak_ptr이 날포인터와의 차이점이다.

하지만 이 lock이 언제나 성공하지는 않을 수 있다. lock이 걸리지 않았을 때 weak가 shared를 가리키고 있는 건 shared의 실제 참조 횟수에 아무 영향을 끼치지 않는다. 그렇기 때문에 이 동안은 shared가 가리키는 객체는 순환 참조 없이 소멸이 가능하다.

그럼 weak_ptr 따위 안 쓰고, 그냥 shared_ptr를 놔두고 평소엔 null을 저장했다가 lock을 걸 상황에만 원래 포인터 값을 참조하는 것과 무슨 차이가 있느냐는 의문이 생길 수 있는데.. weak_*는 그것보다 더 안전하다. 자신이 가리키는 객체가 소멸되었는지의 여부를 expired() 함수로 간편하게 알 수 있다. 레퍼런스 카운트를 이중으로 관리하고 메모리도 이중으로 관리하는 성능 오버헤드를 괜히 감수한 게 아니다.

weak_ptr은 shared_*와 마찬가지로 크기가 포인터 2개이다. 단, 사용법이 unique_*나 shared_*와는 좀 다르다.
저 둘은 ->나 * 연산자를 이용해서 자신이 가리키는 객체에 바로 접근할 수 있는 반면, weak_*는 그렇지 않다. 그리고 실제 객체를 생성하는 make_unique와 make_shared 함수는 있는 반면, make_weak는 없다. weak_*는 그 정의상 기존 shared_*로부터 유도되어 생성되는 걸 가정하기 때문이다.

이상이다. 그냥 생성자와 소멸자를 적절히 구현해 주고 ->와 *만 오버로딩 해 주면 끝일 것 같은 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 사무엘

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