항목 41 : 템플릿 프로그래밍의 천릿길도 암시적 인터페이스와 컴파일 타임 다형성부터
객체 지향 프로그래밍의 세계를 회전시키는 축은 명시적 인터페이스와 런타임 다형성입니다.
예를 들어 아래와 같은 코드가 주어졌고
1
2
3
4
5
6
7
8
9
|
class Widget {
public:
Widget();
virtual ~Widget();
virtual std::size_t size() const;
virtual void normalize();
void swap(Widget& other);
...
};
Colored by Color Scripter
|
다음의 함수가 있을 때,
1
2
3
4
5
6
7
8
9
|
void doProcessing(Widget& w)
{
if(w.size() > 10 && w != someNastyWidget)
{
Widget temp(w);
temp.normalize();
temp.swap(w);
}
}
Colored by Color Scripter
|
doProcessing 함수 안에 있는 w에 대해 말할 수 있는 부분은 다음과 같습니다.
- w는 Widget 타입으로 선언되었기 때문에, w는 Widget 인터페이스를 지원해야 합니다. 이 인터페이스를 소스 코드에서 찾으면 이것이 어떤 형태인지를 확인할 수 있으므로, 이런 인터페이스를 가리켜 명시적 인터페이스라고 합니다. 다시 말해, 소스 코드에 명시적으로 드러나는 인터페이스를 일컫습니다.
- Widget의 멤버 함수 중 몇 개는 가상 함수이므로, 이 가상 함수에 대한 호출은 런타임 다형성에 의해 이루어집니다.다시 말해, 특정한 함수에 대한 실제 호출은 w의 동적 타입을 기반으로 프로그램 실행 중, 즉 런타임에 결정됩니다.
템플릿과 일반화 프로그래밍은 뭔가 다른 부분이 있습니다. 명시적 인터페이스 및 런타임 다형성은 중요도는 떨어집니다. 암시적 인터페이스와 컴파일 타임 다형성이 중요도가 높습니다.
1
2
3
4
5
6
7
8
9
10
|
template<typename T>
void doProcessing(T& W)
{
if(w.size() > 10 && w != someNastyWidget)
{
T temp(w);
temp.normalize();
temp.swap(w);
}
}
Colored by Color Scripter
|
이번에는 doProcessing 템플릿 안에 w에 대해서 어떻게 말할 수 있을까요?
- w가 지원해야 하는 인터페이스는 이 템플릿 안에서 w에 대해 실행되는 연산이 결정합니다. 지금의 경우를 보면, size, nomalize, swap 멤버 함수를 지원해야 하는 쪽은 w의 타입, 즉 T입니다. 그뿐 아니라 T는 복사 생성자도 지원해야 하고, 부등 비교를 위한 연산도 지원해야 합니다. 중요한 점은, 이 템플릿이 제대로 컴파일되려면 몇 개의 표현식이 '유효'해야 하는데 이 표현식들은 바로 T가 지원해야 하는 암시적 인터페이스라는 점입니다.
- w가 수반되는 함수 호출이 일어날 때, 이를테면 operator> 및 operator!= 함수가 호출될 때는 해당 호출을 성공시키기 위해 템플릿의 인스턴스화가 일어납니다. 이러한 이스턴스화가 일어나는 시점은 컴파일 도중입니다. 인스턴스화를 진행하는 함수 템플릿에 어떤 템플릿 매개변수가 들어가느냐에 따라 호출되는 함수가 달라지기 때문에, 이것을 가리켜 컴파일 타임 다형성이라고 합니다.
명시적 인터페이스는 대개 함수 시그너처로 이루어집니다. 시그너처는 함수의 이름, 매개변수 타입, 반환 타입 등을 통틀어 부르는 용어입니다.
암시적 인터페이스를 이루는 요소는 유효 표현식입니다.
1
2
3
4
5
6
7
8
|
template<typename T>
void doProcessing(T& W)
{
if(w.size() > 10 && w != someNastyWidget)
{
...
}
}
Colored by Color Scripter
|
이때 T에서 제공될 암시적 인터페이스에는 다음과 같은 제약이 걸릴 것입니다.
- 정수 계열의 값을 반환하고 이름이 size인 함수를 지원해야 합니다.
- T 타입의 객체 둘을 비교하는 operator!= 함수를 지원해야 합니다(someNastyWidget 객체의 타입은 T라고 가정합니다).
실제로는 연산자 오버로딩의 가능성이 있기 때문에 T는 위의 두 가지 제약 중 어떤 것도 만족시킬 필요가 없습니다.
첫 번째 제약은 T가 size 멤버 함수를 지원해야 하는 것은 맞지만 수치 타입을 반환할 필요까지는 없습니다. 심지어, operator>의 정의에 필요한 타입도 반환할 필요가 없습니다. 그저 어떤 X 타입의 객체가 int(10이 int 타입이라서 입니다.)가 성립될 수 있도록, X 타입의 객체만 반환하면 됩니다.
두 번째 제약도 필수 요구사항이 되지 않습니다. operator!= 함수가 X 타입의 객체 하나와 Y 타입의 객체 하나를 받아들인다고 하면 이 부분은 별 걸림돌 없이 넘어갈 수 있기 때문입니다. T가 X로 변환될 수 있으며 someNastyWidget의 타입이 Y로 변환되는 것이 가능하기만 하면 operator!= 함수의 호출은 유효 호출로 간주될 것입니다.
꼭 잊지 말아야 할 것!
1. 클래스 및 템플릿은 모두 인터페이스와 다형성을 지원합니다.
2. 클래스의 경우, 인터페이스는 명시적이며 함수의 시그너처를 중심으로 구성되어 있습니다. 다형성은 프로그램 실행 중에 가상 함수를 통해 나타납니다.
3. 템플릿 매개변수의 경우, 인터페이스는 암시적이며 유효 표현식에 기번을 두어 구성됩니다. 다형성은 컴파일 중에 템플릿 인스턴스화와 함수 오버로딩 모호성 해결을 통해 나타납니다.
'언어 > C++' 카테고리의 다른 글
[Effective C++] 템플릿으로 만들어진 기본 클래스 안의 이름에 접근하는 방법을 알아 두자 (0) | 2020.02.12 |
---|---|
[Effective C++] typename의 두 가지 의미를 제대로 파악하자 (0) | 2020.02.11 |
[Effective C++] 다중 상속은 심사숙고해서 사용하자 (0) | 2020.02.09 |
[Effective C++] private 상속은 심사숙고해서 구사하자 (0) | 2020.02.08 |
[Effective C++] "has-a(...는...를 가짐)" 혹은 "is-implemented-in-terms-of(...는...를 써서 구현됨)"를 모형화할 때는 객체 합성을 사용하자 (0) | 2020.02.07 |