항목 41: 템플릿 프로그래밍의 천릿길도 암시적 인터페이스와 컴파일 타임 다형성부터

내가 C++에 조예가 깊어서 글을 남기는 것이 아니라, Effecitve C++ 을 공부하는 사람들이 이 글을 보고, 도움이 되었으면 하는 생각과, 혹시 내가 틀린것이 있다면 지적해 주시지 않을까 란 생각으로 글을 올리는것임을 미리 밝힙니다.

항목 41의 이야기를 어떻게 풀어 갈지, 감이 오지 않았다. 그 이것은 항목 41을 잘 이해하지 못했다는 것을 증명하기라도 하듯, 나는 책을 여러번 반복해서 읽을 수 밖에 없었다.

시작하기 앞서 한가지만 기억하자, 템플릿 프로그래밍은 모두 컴파일 타임에 결정 된다! 나머지는 그냥 읽기만 하자. 어찌 보면 이 한가지 기억은 Goto 같은 녀석이다.. ..(왜 컴파일 타임에 결정하느냐? 라고 하면 .. 별도로 템플릿 프로그래밍에 관련된 책을 구입하여 공부하는게 좋을듯 싶다)

템플릿 프로그램밍에서의 초석은 암시적 인터페이스와 컴파일 타임 다형성을 쌓아 올리는 일이다.(... 이해하기 위해서라고 이해하면 된다). 이것부터 시작하면 바로 어려우니, 친숙하고 이해했던 것들(?)을 다시 정리하는 차원에서 .. 비슷한 개념인 비슷한 개념인 명시적 인터페이스(explicit interface)와 런타임 다형성(runtime polymorphism)에 대해서 설명 하겠다.

C++ 에서 명시적 인터페이스란 말들을 듣고라면, 여러가지 의미가 있다. 예를 들어서, 클래스 인터페이스, 함수 인터페이스, 객체 인터페이스, .. 등등 새롭게 나올수 있는 인터페이스등 ..  헷갈리는게 오히려 정상이다. 이래서 컴퓨터 공부하는게 힘들다.. 무슨 용어인지도 모르면 이야기를 들어도 뇌에 들어오지 않으니 말이다.

사설이 길었다, 바로 정리 들어가자.
// ikpil.com or ikpil.tistory.com // Explicit Interface 클래스(이름 짖기가 까다롭다) class EXPLICITINTERFACE { // 정의 부분은 크게 신경 쓸 필요도 없다. // 그냥 만든 것이니까. public: EXPLICITINTERFACE( void ) { } virtual ~EXPLICITINTERFACE( void ) { } virtual std::size_t size( void ) const { return 4; } virtual bool empty( void ) { return true; } int operator() ( void ) { return 4; } }; void signet( EXPLICITINTERFACE& w) { // 크게 신경 쓰지 말자. .. if( w.size() > 10 && w() ) { EXPLICITINTERFACE Temp( w ); Temp.empty(); } } int main(void) { // 아무 일도 없다, 그냥 .. A다 EXPLICITINTERFACE A; // 함수에 A를 넣는 것 뿐이 하는 일 없다 signet( A ); }
우선 명시적 인터페이스 부터...객체 지향 프로그램밍을 A 라는 객체가 A.size() 나 A.empty() ,A.operator() 등을 지원한다면, A 객체의 멤버 함수에는 size() empty() operator() 같은 함수들이 A 객체 클래스의 소스코드에 분명히 정의 되어 있을 것이다. 또한 어떤 타입을 매개변수로 어떤 타입을 반환하는 지도 말이다. 그렇기 때문에 w 에게 있어 size(), empty() operator() 는 w가 사용할수 있는 인터페이스라 말 할수 있다.(interface 의 사전적 의미는 의사소통, 대화, 공유영역,접전 쯤으로 이해하면 될것이다.) 즉 w는 empty(), operator() size()를 명시적으로 지원되는 인터페이스 이다!


그렇다면 런타임 다형성은 또 무엇인가?
런타임 다형성.. 이 말만 들어도 참 어렵다. 영어 Run Time 실행 시간, 다형성 한문일테니 한문을 써주는 센스가 있어야 겠다. 다형성[多形性] (많은 다, 형상 형, 모습 성) 이다!

다 풀이 하자면, 실행 시간에 많은 형상을 가진 모습을 뜻하는 것으로써 우리 객체 지향에선 이 런타임 다형성이 무엇을 뜻하는 것일까?
EXPLICITINTERFACE의 멤버 함수 중에, 몇몇개는 가상함수로 되어 있다. 이 가상 함수 호출은 런타임 다형성을 띠게 된다.(런타임 다형성은 쉽게 이해 할수 있으니 구글링 하면 된다)



자 그렇다면, 초석을 깔아 둔 명시적 인터페이스(explict interface)와 런타임 다형성(runtime polymorphism)에 대해서 이해 했다면, 바로! 암시적 인터페이스(implicit interface)와 컴파일 타임 다형성(compile-time polymorphism)에 대해서 이해해보자.

암시적 인터페이스 .. 명시적 인터페이스는 시력이 안좋은 나에게 껴서 예쁜 여자를 손쉽게 분간 할 수 있는 안경의 역활과 비슷하지만, 도수가 높은 안경을 끼고, 여자를 보면 다 이뻐 보이는 것 같은 개념이랄까? (.. 어찌보면 도수 높은 안경이 .. 더 좋다고 할 수 있겠다.)


예제 코드를 기준으로 설명을 하려 한다, 위의 코드와 별반 다르지 않다. 그 차이는 명시적으로 나와 있으니 분간 하도록...
// ikpil.com or ikpil.tistory.com // Explicit Interface 클래스(이름 짖기가 까다롭다) class EXPLICITINTERFACE { // 정의 부분은 크게 신경 쓸 필요도 없다. // 그냥 만든 것이니까. public: EXPLICITINTERFACE( void ) { } virtual ~EXPLICITINTERFACE( void ) { } virtual std::size_t size( void ) const { return 4; } virtual bool empty( void ) { return true; } int operator() ( void ) { return 4; } }; //void signet( EXPLICITINTERFACE& w) //{ // // 크게 신경 쓰지 말자. .. // if( w.size() > 10 && w() ) // { // EXPLICITINTERFACE Temp( w ); // Temp.empty(); // } //} template <typename T> void signet( T& w) { // 크게 신경 쓰지 말자. .. if( w.size() > 10 && w() ) { T Temp( w ); Temp.empty(); } } int main(void) { // 아무 일도 없다, 그냥 .. A다 EXPLICITINTERFACE A; // 함수에 A를 넣는 것 뿐이 하는 일 없다 signet( A ); }
자.. signet 의 T를 보자.. T.. 어째서 T는 정의도 없는데 컴파일이 되는가? 혹시 도수 높은 안경껴서 다 이쁜 여자로 보이는건 아닌가?(여기서 여자는 코드다; 또한 여자를 비하하는것도 아니다. 오해 없길 바란다). 그렇다 다 정상적인 코드로 컴파일러는 인식을 한다. 이때 T의 인터페이스에 size(), empty(), operator()가 있기만 하면 이쁜 여자로 보인다는 것이다.

이런 것을 암시적 인터페이스 라 할 수 있다.


그렇다면 컴파일 타임 다형성(compile-time polymorphism)은  런타임 다형성과 어떤 차이가 있나?
런타임 다형성은 .. 프로그램 실행 중에 일어나는 다형성이지만, 컴파일 타임 다형성은 컴파일러가 컴파일을 할 때, signet( A ); 를 명시적으로 표기 할 때, 템플릿으로 정한 부분이 EXPLICITINTERFACE 형으로 새롭게 만들어 진다! 만약 EXPLICITINTERFACE2 가 있다면 signet 에 EXPLICITINTERFACE2 를 넣었을 때 EXPLICITINTERFACE2에 맞게 새로운 함수가 생겨난다!


정말 신기하지 않는가? .. 나만 신기하지 뭐..  이처럼 위의 코드 처럼 template <typename T> 는 동일한 코드를 T형에 맞추어 컴파일 타임에 생성해 준다는 이야기 이다!!


끝으로 몇가지 이야기를 덧붙인다.
 template 예제소스에서 if( w.size() > 10 && w() ) 을 보면
1. w.size() 의 반환값이 operator > 를 호출한다.
2. 호출된 operator>는 매개변수 10을 받는다.
3. 2의 반환값이 operator&& 를 호출 한다.
4. operator&& 의 매개변수가 w() 의 반환값을 매개변수로 받는다.
5. 4의 반환값이 bool 형과 호환되는 형을 반환하면 .. 컴파일라는 이쁜 코드로 인식한다는 이야기이다.


이것만은 기억하자.
1. 클래스 및 템플릿은 모두 인터페이스와 다형성을 지원한다.
2. 클래스는 인터페이스가 명시적이며, 프로그래램 실행중에 다형성이 나타난다.
3. 템플릿은 인터페이스가 암시적이며, 컴파일 과정중에 다형성이 나타난다.


관련 링크
http://ikpil.tistory.com/342 <-- Effective 2판 에서의 템플릿 언제 템플릿을 쓸 것인가?
http://kldp.org/node/58115 <-- 템플릿을 보다 더 자세하게 구현할수 있는 답변이 있다.
http://cooljy.tistory.com/tag/템플릿 <-- 템플릿 사용 방법에 대한 이야기
http://www.cplusplus.com/doc/tutorial/templates.html <-- 템플릿의 개념을 영문으로 설명해준다.
http://www.npteam.net/497 <-- 템플릿 기반의 싱글톤

항목 41: 템플릿 프로그래밍의 천릿길도 암시적 인터페이스와 컴파일 타임 다형성부터

객체 지향 프로그래밍의 세계를 회전시키는 축은 명시적 인터페이스(explicit interface)와 런타임 다형성(runtime polymorphism)입니다. 예를 들어 아래 클래스(클래스 자체의 존재감이나 의미는 없습니다)가 주어졌고,

class Widget
{
public:
    Widget();
    virtual ~Widget();
    virtual std::size_t size() const;
    virtual void normalize();
    void swap(Widget& other);
    ...
};

다음 함수(마찬가지로 의미는 없습니다)가 있을 때

void doProcessing(Widget& w)
{
    if( w.size() > 10 && w != someNastyWidget )
    {
        Widget Temp( w );
        temp.normalize( );
        temp.swap( w );
    }
}
함수 안에 있는 w에 대해서 할 수 있는 부분은 다음과 같습니다.

w는 widget 타입으로 선언되었기 때문에, w는 widget 인터페이스를 지원해야 합니다. 이 인터페이스를 소스 코드에서 찾아면 이것이 어떤 형태인지를 확인할 수 있으므로, 이런 인터페이스를 가르켜 명시적 인터페이스라고 합니다. 다시 말해, 소스 코드에 명시적으로 드러나는 인터페이스를 일컫습니다.

widget의 멤버 함수 중 몇 개는 가상 함수이므로, 이 가상 함수에 대한 호출은 런타임 다형성에 의해 이루어 집니다. 다시 말해, 특정 함수에 대한 실제 호출은 w의 동적 타입을 기반으로 프로그램 실행 중, 즉 런타임에 결정됩니다.

템플릿과 일반화 프로그래밍의 세계에는 뿌리부터 뭔가 다른 부분이 있습니다. 명시적 인터페이스 및 런타임 다형성은 그대로 존재하긴 하지만 중요도는 사뭇 떨어집니다. 이 바닥에서 활개를 치고 다니는 주인공은 암시적 인터페이스(implicit interface)와 컴파일 타임 다형성(compile-time polymorphism)입니다. 어떻게 그렇게 되는지를 확인하는 방법은 그리 어렵지 않습니다. doProcessing 함수를 함수 템플릿으로 바꿀 때 무슨 일이 생기는지만 보면 되거든요.

template<typename T>
void doProcessing( T& w )
{
    if( w.size() > 10 && w != someNastyWidget )
    {
        T Temp( w );
        temp.normalize( );
        temp.swap( w );
    }
}

이번에는 doProcessing 템플릿 안의 w에 대해서 어떻게 말할 수 있을까요?

w가 지원해야 하는 인터페이스는 이 템플릿 안에서 w에 대해 실행되는 연산이 결정합니다. 지금의 경우를 보면, size normalize swap 멤버 함수를 지원해야 하는 쪽은 w의 타입, 즉 T입니다, 그뿐 아니라 T는 복사 생성자도 지원해야 하고(temp를 만들어야 하니까), 부등 비교를 위한 연산도 지원해야 합니다(someNastyWidget과 비교해야 하니까) 뒷부분을 보면 아시겠지만 이 이야기는 사실 완벽하게 정확한 것은 아닙니다. 하지만 지금은 이 정도면 충분하다고 생각합니다. 진짜 중요한 점은, 이 템플릿이 제대로 텀파일되려면 몇 개의 표현식이 '유효(valid)'해야 하는데 이 표현식들은 바로 T가 지원해야 하는 암시적 인터페이스라는 점입니다.

w가 수반되는 함수 호출이 일어날 때, 이를테면, operator> 및 operator != 함수가 호출될 때는 해당 호출을 성공시키기 위해 템플릿의 인스턴스화가 일어납니다.이러한 인스턴스화가 일어나는 시점을 컴파일 도중입니다. 인스턴스화를 진행하는 함수 템플릿에 어떤 템플릿 매개변수가 들어가느냐에 따라 호출되는 함수가 달라지기 때문에, 이것을 가리켜 컴파일 타임 다형성이라고 합니다.

혹시 템플릿을 한 번도 사용해 본 적이 없더라도, 런타임 다형성과 컴파일 타임 다형성의 차이를 헷갈리는 분이 없어야 하겠습니다. 오버로드된 함수 중 지금 호출할 것을 골라내는 과정(컴파일 중에 일어납니다)과 가상 함수 호출의 동적 바인딩(프로그램 실행 중에 일어나고요)의 차이점과 흡사하니까요. 반면 명시적 인터페이스와 암시적 인ㅌ\ㅓ페이스의 차이는 템플릿에서 처음 접하는 부분일 것 같은데요, 좀더 자세히 알아보는 시간을 갖도록 합시다.

명시적 인터페이스는 대개 함수 시그너처로 이루어집니다. 아시다시피 시그너처는 함수의 이름, 매개변수 타입, 반환 타입 등을 통틀어 부르는 용어죠, 그러니까 앞에서 보진 예제클래스인 Widget의 public 인터페이스는,

class Widget
{
public:
    Widget();
    virtual ~Widget();
    virtual std::size_t size() const;
    virtual void normalize();
    void swap(Widget& other);
};

생성자, 소멸자를 포함해서 size normalize swap 함수 그리고 이들의 매개변수 타입, 반환 타입 및 각 함수의 상수성 여부로 이루어져 있는 것이죠(게다가 컴파일러가 자동으로 만들어 놓은 복사 생성자와 복사 대입 연산자도 포함됩니다) typedef 타입이 있을 경우에는 이것도 포함될 수 있습니다. 그리고 데이터 멤버의 경우에는 데이터 멤버를 private 멤버로 만들라는 항목 22의 이야기를 대담하게 어겨 주셨다고 해도 시그너처에 들어가지 않습니다.

반면, 암시적 인터페이스는 사뭇 다릅니다. 함수 시그너처에 기반하고 있지 않다는 것이 가장 큰 차이점입니다. 암시적 인터페이스를 이루는 요소는 유효 표현식(expression) 입니다. doProcessing 템플릿의 시작부분에 있는 조건문을 다시 한 번 봐 주세요.

template<typename T>
void doProcessing( T& w )
{
    if( w.size() > 10 && w != someNastyWidget )
    {
        T Temp( w );
        temp.normalize( );
        temp.swap( w );
    }
}

이때 T(w의 타입)에서 제공될 암시적 인터페이스는 다음과 같은 제약이 걸릴 테지요.

1. 정수 계열의 값을 반환하고 이름이 size인 함수를 지원해야 합니다.
2. T 타입의 객체 둘을 비교하는 operator!= 함수를 지원해야 합니다(여기서 someNasty Widget 객체의 타입은 T라고 가정합니다).

실제로 연산자 오버로딩의 가능성이 있기 때문에 T는 위의 두 가지 제약중 어떤것도 만족시킬 필요가 없습니다. 우선 첫 번째 제약부터 보조, T가 size 멤버 함수를 지원해야 하는 것은 맞습니다. 기본 클래스로부터 물려받을 수도 있다는 점은 간과할 순 없더라도 말이죠. 그렇다고 해도 이 멤버 함수는 수치 타입을 반환할 필요까지는 없습니다. 심지어 operator>의 정의에 필요한 타입도 반환할 필요가 없고요, size() 멤버 함수가 해야 하는 일은 별거 없습니다 그저 어떤 X타입의 객체와 int(10이 int 타입이니까)가 함께 호출될 수 있는 operator>가 성립될 수 있도록 X 타입의 객체만 반환하면 임무 종료인 것입ㄴ디ㅏ. 한편, operator> 함수는 반드시 X타입의 매개변수를 받아들일 이유가 없습니다. 그 이유는 이 함수가 Y 타입의 매개변수를 받도록 정의되어 있고 X 타입에서 Y타입으로 암시적 변환이 가능하다면, 만사 오케이!이기 때문입니다.

첫 번째 제약의 경우와 비슷한 이치로, T가 operator != 함수를 지원해야 한다는 두 번째 제약도 필수 요구사항이 되지는 않습니다. operator != 함수가 X 타입의 객체 하나와 Y타입의 객체 하나를 받아들인다고 하면 이 부분은 별 걸림돌 없이 넘어갈 수 있기 때문입니다. T가 X로 변환될 수 있으며 someNastyWidget의 타입이 Y로 변환되는 것이 가능하기만 하면 operator != 함수의 호출은 유효 호출로 간주될 것입니다.

(참, 여담입니다. 위의 이야기는 operator&& 함수가 오버로드될 수 있다는 가능성을 염두에 두지 않고 한 것이기 때문에, 위의 표현식에 나온 '&&'가 놀리 곱 연산의 의미가 아니라면 이야기가 완전히 달라질 것입니다.)

사람들은 암시적 인터페이스를 이런 방법으로 생각하자마자 머리에 쥐가 나는 경우가 대부분이지만, 사실 아스피린을 먹어야 할 정도는 정말 아닙니다. 암시적 인터페이스는 그저 유효 표현식의 집합으로 구성되어 있을 뿐입니다. 표현식 자체만 뚤어지게 보면 좀 복잡해 보일 수도 있지만, 표현식에 걸리는 제약은 일반적으로 지극히 평이합니다. 예를 들어, 다음 조건식에서
if( w.size() > 10 && w != someNastyWidget ) ...
size, operator>, operator&& 혹은 operator!= 함수에 대한 제약을 일일이 집어내 보라고 하면 열 분 중 아홉 분은 난감해 하겠지만, 이 표현식에 대한 제약은 되레 집어내기가 쉽습니다. if 문의 조건식 부분은 불(boolean) 표현식이어야 하기 때문에, 표현식에서 쓰이는 것들이 정확히 어떤 타입인지 상관없이, 그리고 "w.size() > 10 && w != someNastyWidget"이 정확히 어떤 값을 내놓든 간에 이 조건식 부분의 결과 값은 bool과 호환되어야 합니다. 이 제약이 바로 doProcessing 템플릿이 타입 매개변수인 T에 대해 요구하는 암시적 인터페이스의 일부분입니다. 그럼, 그 나머지도 궁금하죠? 마찬가지입니다. 복사 생서자, normalize 그리고 swap 함수에 대한 호출이 T 타입의 객체에 대해 '유효'해야 한다는 것입니다.

템플릿 매개변수에 요구되는 암시적 인터페이스는 클래스의 객체에 요구되는 명시적 인터페이스 만큼이나 우리 피부에 가깝게 닿아 있습니다. 게다가 컴파일 도중에 정검된다는 점도 둘이 똑같습ㄴ디ㅏ. 클래스에서 제공 하는 명시적 인터페이스와 호환되지 않는 방법으로 그 클래스의 객체를 쓸 수 없듯이, 어떤 템플릿 안에서 어떤 객체를 쓰려고 할 때 그 템플릿에서 요구하는 암시적 인터페이스를 그 객체가 지원하지 않으면 사용이 불가능합니다(한번 더 말씀드리는데, 코드가 컴파일되지 않습니다).


이것만은 잊지 말자!
클래스 및 템플릿은 모두 인터페이스와 다형성을 지원합니다.
클래스의 경우, 인터페이스는 명시적이며 함수의 시그너처를 중심으로 구성되어 있습니다. 다형성은 프로그램 실행 중에 가상 함수를 통해 나타납니다.
템플릿 매개변수의 경우, 인터페이스는 암시적이며 유효 표현식에 기반을 두어 구성됩니다. 다형성은 컴파일 중에 템플릿 인스턴스화와 함수 오버로딩 모호성 해결을 통해 나타냅니다.