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