- 클래스 및 템플릿은 모두 인터페이스와 다형성을 지원한다.
- 클래스의 경우, 인터페이스는 명시적이며 함수의 시그니처를 중심으로 구성되어 있다. 다형성은 프로그래밍 실행 중에 가상 함수를 통해 나타난다.
- 템플릿 매개변수의 경우, 인터페이스는 암시적이며 유효 표현식에 기반을 두어 구성된다. 다형성은 컴파일 중에 템플릿 인스턴스화와 함수 오버로딩 모호성 해결을 통해 나타난다.
템플릿 프로그래밍의 암시적 인터페이스 & 컴파일 타임 다형성
객체 지향 프로그래밍에서 명시적 인터페이스와 런타임 다형성은 매우 중요하다.
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는 Widget 타입으로 선언되었기 때문에, w는 Widget 인터페이스를 지원해야 한다.
이 인터페이스를 소스 코드에서 찾으면 이것이 어떤 형태인지를 확인할 수 있으므로, 이런 인터페이스를 명시적 인터페이스라고 한다. 즉, 소스 코드에 명시적으로 드러나는 인터페이스를 말한다.
Widget의 멤버 함수 중 몇 개는 가상 함수이므로, 이 가상 함수에 대한 호출은 런타임 다형성에 의해 이루어진다.
즉, 특정한 함수에 대한 실제 호출은 w의 동적 타입을 기반으로 런타임에 결정된다.
doProcessing 함수를 함수 템플릿으로 바꿀 때 생기는 일을 보자.
template<typename T>
void doProcessing(T& w)
{
if(w.size() > 10 && w != someNastyWidget)
{
T temp(w);
temp.normalize();
temp.swap(w);
}
}w가 지원해야 하는 인터페이스는 이 템플릿 안에서 w에 대해 실행되는 연산이 결정한다.
지금의 경우 size, normalize, swap 멤버 함수를 지원해야 하는 쪽은 w의 타입, T이다.
그뿐 아니라 T는 복사 생성자도 지원해야 하고 부등 비교를 위한 연산도 지원해야 한다.
이처럼 지금의 템플릿이 제대로 컴파일되려면 몇 개의 표현식이 유효해야 하는데 이 표현식들은 바로 T가 지원해야 하는 암시적 인터페이스이다.
w가 수반되는 함수 호출이 일어날 때, 이를테면 operator> 및 operator!= 함수가 호출될 때는 해당 호출을 성공시키기 위해 템플릿의 인스턴스화가 일어난다. 이러한 인스턴스화가 일어나는 시점은 컴파일 도중이다.
인스턴스화를 진행하는 함수 템플릿에 어떤 템플릿 매개변수가 들어가느냐에 따라 호출되는 함수가 달라지기 때문에, 이것을 가리켜 컴파일 타임 다형성이라고 한다.
런타임 다형성과 컴파일 타임 다형성의 차이는 오버로드된 함수 중 호출할 것을 골라내는 과정과 가상 함수 호출의 동적 바인딩의 차이점과 비슷하다. 명시적 인터페이스와 암시적 인터페이스의 차이는 좀 더 자세히 알아봐야 한다.
명시적 인터페이스는 대개 함수 시그니처로 이루어진다.
class Widget {
public:
Widget();
virtual ~Widget();
virtual std::seiz_t size() const;
virtual void normalize();
void swap(Widget& other);
};시그니처란 생성자, 소멸자를 포함해서 size, normalize, swap 함수 그리고 이들의 매개변수 타입, 반환 타입 및 각 함수의 상수성 여부로 이루어져 있는 것이다. typedef 타입이 있을 경우에는 이것도 포함된다.
데이터 멤버는 public으로 선언하여도 시그니처에 해당하지 않는다.
반면, 암시적 인터페이스는 다르다.
함수 시그니처에 기반하고 있지 않는다. 암시적 인터페이스를 이루는 요소는 유효 표현식이다.
template<typename T>
void doProcessing(T& w)
{
if(w.size() > 10 && w != someNastyWidget)
{
...T에서 제공될 암시적 인터페이스에는 다음과 같은 제약이 걸린다.
- 정수 계열의 값을 반환하고 이름이 size인 함수를 지원해야 한다.
- T 타입의 객체 둘을 비교하는 operator!= 함수를 지원해야 한다.
실제로는 연산자 오버로딩의 가능성이 있기 때문에 T는 위의 두 가지 제약 중 어떤 것도 만족시킬 필요가 없다.
첫 번째 제약을 보면 T가 size 멤버 함수를 지원해야 하는 것은 맞다. 기본 클래스로부터 물려받을 수 있지만 이 함수가 수치 타입을 반환할 필요까지는 없다. 심지어, operator>의 정의에 필요한 타입도 반환할 필요가 없다.
size 멤버 함수가 해야하는 일은 어떤 X 타입의 객체와 int가 함께 호출될 수 있는 operator>가 성립될 수 있도록, X 타입의 객체만 반환하면 된다.
operator> 함수는 반드시 X 타입의 매개변수를 받아들일 이유가 없다. 이 함수가 Y 타입의 매개변수를 받도록 정의되어 있고 X 타입에서 Y 타입으로 암시적인 변환이 가능하다면 된다.
두 번째 제약을 보면 T가 operator!= 함수를 지원해야 한다는 점을 볼 수 있다.
첫 번째 제약과 마찬가지로 operator!= 함수도 필수 요구사항이 되지 않는다.
operator!= 함수가 X 타입의 객체 하나와 Y 타입의 객체 하나를 받아들인다고 하면 문제가 되지 않는다.
T가 X로 변환될 수 있으며 someNastyWidget의 타입이 Y로 변환되는 것이 가능하기만 하면 opertor!= 함수의 호출은 유효 호출로 간주될 것이다.
암시적 인터페이스는 유효 표현식의 집합으로 구성되어 있을 뿐이다.
표현식에 걸리는 제약은 일반적으로 평이하다.
if(w.size() > 10 && w != someNastyWidget) ...이 표현식의 제약을 보면, if문의 조건식 부분은 bool 표현식이어야 하기 때문에, 표현식에서 쓰이는 것들이 정확히 어떤 값을 내놓든 간에, bool과 호환되어야 한다.
이 제약이 바로 doProcessing 템플릿이 타입 매개변수인 T에 대해 요구하는 암시적 인터페이스의 일부이다.
암시적 인터페이스의 다른 부분은 복사 생성자, normalize, swap 함수에 대한 호출이 T 타입의 객체에 대해 유효해야 한다는 점이다.
클래스에서 제공하는 명시적 인터페이스와 호환되지 않는 방법으로 그 클래스의 객체를 쓸 수 없듯이, 어떤 템플릿 안에서 어떤 객체를 쓰려고 할 때 그 템플릿에서 요구하는 암시적 인터페이스를 그 객체가 지원하지 않으면 사용이 불가능하다. 컴파일 조차 되지 않는다.
