31-1-라.임의 타입 지원 조건

함수 템플릿의 본체 코드는 임의의 타입에 대해서도 동일하게 동작해야 하므로 타입에 종속적인 코드는 사용할 수 없다. 기본 타입에 대해 이미 오버로딩되어 있는 +, - 등의 연산자를 사용하거나 cout과 같이 피연산자의 타입을 스스로 판별할 수 있는 코드만 사용해야 한다. printf 함수처럼 타입에 따라 서식을 미리 결정해야 하는 함수는 함수 템플릿에서 쓰지 않는 것이 바람직하다. 다음 함수를 보자.

template <typename T>

void PrintValue(T value)

{

printf("value is %d\n",value);

}

템플릿으로 되어 있어서 임의의 타입을 받을 수는 있지만 출력 코드에서 %d 서식을 사용하고 있으므로 사실상 정수 호환 타입만 출력할 수 있다. 정수 이외의 타입을 %d 서식으로 출력하면 어떤 값이 출력될 지 알 수 없다. 좀 더 범용성을 높이려면 cout으로 출력하는 것이 유리한데 cout은 임의 타입을 출력할 수 있고 사용자 정의 타입도 << 연산자만 적절하게 오버로딩되어 있으면 똑같은 방법으로 출력할 수 있다.

앞 예제의 Add 함수 템플릿은 + 연산자로 피연산자를 더하는데 + 는 대부분의 기본 타입에 대해 오버로딩되어 있으므로 아무 타입이나 잘 더할 수 있을 것 같다. 그러나 이 연산자를 쓸 수 있는 정수, 실수, 문자형 등의 수치형에 대해서만 사용할 수 있을 뿐이다. 문자열(char *)을 더할 때는 포인터끼리 더할 수 없으므로 strcat 함수를 사용해야 한다. 더하는 알고리즘이 완전히 다르므로 Add 함수를 사용할 수 없다. 물론 + 연산자를 오버로딩하고 있는 문자열 객체라면 이 함수로 연결할 수 있을 것이다.

템플릿 본체에 사용된 모든 코드와 호환되는 타입에 대해서만 구체화할 수 있다. 두 값 중 큰 값을 찾는 Max 템플릿은 단순히 > 연산자와 삼항 조건 연산자만으로 값의 대소를 판단할 뿐이다. 지극히 간단해서 별다른 제약이 없을 것 같지만 이 간단한 템플릿도 안 통하는 경우가 있다. 다음 예제를 보자.

예 제 : MaxObject

#include <Turboc.h>

template <typename T>

T Max(T a, T b)

{

return (a > b) ? a:b;

}

struct S {

int i;

S(int ai) : i(ai) { }

//operator >(S &Other) { return i > Other.i; }

};

void main()

{

int i1=3,i2=4;

double d1=1.2,d2=3.4;

S s1(1),s2(2);

Max(i1,i2);

Max(d1,d2);

Max(s1,s2);

}

Max는 두 값 중 큰 값을 리턴하는데 정수나 실수에 대해서는 잘 동작한다. 그러나 구조체 S에 대해서는 동작하지 않는데 구조체끼리는 > 연산자로 비교할 수 없기 때문이다. 구조체에 > 연산자를 오버로딩해 놓으면 이때는 S객체끼리 대소 비교가 가능해 지므로 Max(s1, s2) 호출도 잘 컴파일된다. S가 > 연산자를 오버로딩하지 않더라도 이 호출을 주석으로 처리하면 Max(S, S)가 구체화되지 않으므로 아무 일 없다는 듯 잘 컴파일된다.

컴파일러는 구체화된 템플릿 함수에 대해서만 에러 체크를 할 뿐이지 템플릿 자체에 대해서는 상세한 점검을 할 수 없다. 템플릿을 정의할 때는 어떤 타입이 전달될지 모르므로 컴파일러는 템플릿의 모양만 기억해 둘 뿐 구문상의 에러 체크를 하지 않는다. 심지어 다음과 같은 템플릿도 아무 문제없이 컴파일된다.

template <typename T>

void Some(T arg)

{

arg.ar[34]=arg.next;

arg.next->value=1234;

}

이 템플릿은 인수로 전달받은 arg가 구조체이고 이 구조체안에 크기가 최소한 35이상인 ar 배열이 멤버로 포함되어 있으며 next는 다른 구조체를 가리키는 포인터이고 next가 가리키는 구조체의 value 멤버는 정수형 변수라는 것을 가정하고 있다. 이 가정이 맞는지 아닌지는 실제로 전달되는 T가 어떤 타입인가에 따라 달라지는 것이므로 컴파일러는 구체화될 때까지는 에러 체크를 보류할 수밖에 없는 것이다. 오타가 있거나 if = for + while; 같은 말도 안되는 구문까지도 일단은 컴파일된다.

템플릿은 인수로 전달된 임의의 타입에 대해 동작할 수 있는 함수의 형틀이지만 그 본체에서는 전달될만한 타입을 모두 지원하는 범용적인 코드만 작성해야 한다. 또는 템플릿으로 전달된 타입이 해당 템플릿의 본체 코드의 요구 조건을 모두 만족해야 한다. 그렇지 않을 경우 잘 사용하던 템플릿도 특정 타입에 대해 구체화했을 때 갑자기 에러가 발생할 수도 있다. 다음 예제로 테스트해 보자.

예 제 : SwapPerson

#include <Turboc.h>

template <typename T>

void Swap(T &a, T &b)

{

T t;

t=a;a=b;b=t;

}

class Person

{

private:

char *Name;

int Age;

public:

Person() {

Name=new char[1];

Name[0]=NULL;

Age=0;

}

Person(const char *aName, int aAge) {

Name=new char[strlen(aName)+1];

strcpy(Name,aName);

Age=aAge;

}

Person(const Person &Other) {

Name=new char[strlen(Other.Name)+1];

strcpy(Name,Other.Name);

Age=Other.Age;

}

/*

Person &operator =(const Person &Other) {

if (this != &Other) {

delete [] Name;

Name=new char[strlen(Other.Name)+1];

strcpy(Name,Other.Name);

Age=Other.Age;

}

return *this;

}

//*/

virtual ~Person() {

delete [] Name;

}

virtual void OutPerson() {

printf("이름 : %s 나이 : %d\n",Name,Age);

}

};

void main()

{

Person A("이승만",10);

Person B("박정희",20);

A.OutPerson();B.OutPerson();

Swap(A,B);

A.OutPerson();B.OutPerson();

}

예제의 선두에는 앞에서 만들어서 이미 테스트가 완료된 Swap 템플릿이 정의되어 있다. 변수 교환 알고리즘이 워낙 간단해서 별 문제가 없을 것 같지만 Person 객체에 대해서는 제대로 동작하지 않으며 끝낼 때 다운된다. Swap 템플릿은 변수값 교환을 위해 세 번 대입을 하므로 이 코드가 이상없이 동작하려면 대입이 가능해야 하고 대입에 의해 별다른 문제가 없어야 한다. 그러나 예제의 Person 클래스는 대입 연산자를 제대로 정의하지 않아 템플릿의 코드와는 맞지 않다.

Person 객체 A와 B에 대해 Swap(A,B)를 호출했을 때 어떤 일들이 벌어지는지 상상해 보자. 컴파일러는 함수 호출부의 타입을 보고 Swap(Person, Person) 함수를 구체화하여 형식 인수 a, b로 실인수 A, B를 전달한다. Person에는 복사 생성자가 정의되어 있으므로 여기까지는 아주 정상적이다. 그러나 교환을 위해 a를 t에 대입하는 순간 t는 얕은 복사에 의해 a와 버퍼를 공유하게 되며 이 상태에서 t의 값을 b가 대입받았다. Swap 함수가 종료될 때 a는 b의 값을 무사히 대입받았지만 b와 t가 버퍼를 공유하며 지역 객체 t가 파괴되면서 b의 버퍼를 정리해 버린다. main으로 돌아 왔을 때 실인수 B의 버퍼가 이중 해제되므로 다운되는 것이다.

틀린 코드임에도 불구하고 컴파일 에러가 발생하지 않는 이유는 대입 연산자는 디폴트가 있으므로 일단 대입은 가능하기 때문이다. 디폴트 대입 연산자에 의한 얕은 복사가 문제의 원인이었으므로 깊은 복사를 하는 대입 연산자를 정의하면 문제가 해결된다. 예제의 주석으로 묶여있는 대입 연산자를 풀어 보면 아무 이상없이 잘 동작할 것이다.

템플릿은 지금 당장 잘 컴파일되고 이상없이 동작하는 것처럼 보이더라도 타입이 바뀌면 어떻게 될지 장담할 수 없다. 완벽할 수는 없겠지만 템플릿은 가급적이면 많은 타입을 지원할 수 있도록 범용적인 코드를 작성해야 하며 템플릿의 인수로 사용될 클래스는 템플릿 본체가 요구하는 모든 기능을 지원해야 한다. 가장 이상적인 타입은 기본 타입인 int이므로 int와 똑같은 방식으로 동작하는 클래스를 만든다면 거의 안전하다. 왜 클래스가 완전한 타입 흉내를 내려고 그토록 몸부림을 치는지 이해할 수 있겠는가?