32-1

연산자 함수

기본형의 연산자

연자자를 오버로딩할 수 있다는 것은 C++언어의 큰 특징이며 클래스가 타입임을 보여주는 단적인 예.

기본형의 연산문 중 대표적으로 덧셈 연산문을 보면 다음과 같은 구문이 가능하다.

int i1=1,i2=2;

double d1=3.3,d2=4.4;

int i=i1+i2; // 정수 덧셈

double d=d1+d2; // 실수 덧셈

연산 결과 i는 3이 되고 d는 7.7이 될 것이다. 덧셈 연산자인 +는 피연산자의 타입이 달라도 문제없이 정확하게 연산을 해 낸다. 이 연산이 성립하는 이유도 알고보면 나름대로 복잡하다. 정수형과 실수형은 길이도 다르고 비트 구조도 상이해서 각 타입을 더하는 알고리즘이 분명히 다르겠지만 똑같은 연산자로 두 타입의 덧셈이 가능한 것이다.

이렇게 되는 이유는 덧셈 연산자가 피연산자의 타입에 따라 오버로딩되어 있기 때문이다. 즉, 정수 덧셈을 하는 코드와 실수 덧셈을 하는 코드가 각각 따로 작성되어 있으며 컴파일러는 덧셈 연산자의 양변에 있는 피연산자의 타입을 점검한 후 둘 다 정수일 경우 정수끼리 더하는 코드를 호출하고 둘 다 실수일 경우 실수끼리 더하는 코드를 호출한다. 정수의 경우 부호가 같으면 절대값을 더하고 부호가 다르면 절대값끼리 빼고 부호는 큰 쪽을 따를 것이며 실수의 경우 지수를 일치시킨 후 덧셈을 할 것이다. 인수의 타입이 다르면 같은 이름으로 함수를 중복 정의할 수 있는 것처럼 연산자도 피연산자의 타입에 따라 중복 정의할 수 있다. + 기호를 덧셈을 하는 함수의 이름이라고 했을 때 이 함수의 원형은 아마도 다음과 같이 오버로딩되어 있을 것이다.

int +(int, int);

double +(double, double);

위쪽 함수는 정수끼리 더한 후 정수를 리턴하고 아래쪽 함수는 실수끼리 더한 후 실수를 리턴한다. i1+d1같이 정수와 실수를 섞어서 더할 경우는 컴파일러의 형변환 기능에 의해 i1이 실수로 상승 변환된 후 실수끼리 덧셈을 하게 될 것이다. 또 포인터와 정수의 덧셈도 산술적인 덧셈과 다르게 정의되어 있는데 이 연산도 일종의 오버로딩된 예라고 할 수 있다.

그러나 연산자의 이런 중복 정의는 어디까지나 컴파일러가 기본적으로 제공하는 타입에 대해서만 적용되며 사용자가 직접 정의하는 타입인 클래스에 대해서는 이런 규칙이 적용되지 않는다. 다음 예제는 복소수를 표현하는 Complex 클래스의 객체끼리 + 연산자로 더한다.

#include <Turboc.h>

class Complex

{

private:

double real;

double image;

public:

Complex() { }

Complex(double r, double i) : real(r), image(i) { }

void OutComplex() const { printf("%.2f+%.2fi\n",real,image); }

};

void main()

{

Complex C1(1.1,2.2);

Complex C2(3.3,4.4);

C1.OutComplex();

C2.OutComplex();

Complex C3;

C3=C1+C2;

C3.OutComplex();

}

이 상태로 컴파일해 보면 C3=C1+C2; 연산문에서 "Complex 클래스는 + 연산을 정의하지 않았다"는 에러가 발생한다. 사용자 정의 타입인 클래스의 객체끼리 더하는 방법은 클래스별로 고유하기 때문에 클래스를 만든 사람이 덧셈 연산을 직접 정의할 필요가 있다.

C3=C1+C2; 연산문이 제대로 컴파일되려면 복소수에 대한 덧셈 연산자를 중복 정의해야 한다. 복소수끼리 더할 때 실수부는 실수부끼리 허수부는 허수부끼리 더한다

개발자가 컴파일러에게 복소수끼리 더하는 방법을 알려 줘야 하는데 이것을 연산자 오버로딩이라고 한다. 새로 만들어지는 + 연산자는 아마도 다음과 같은 원형을 가질 것이다.

Complex +(Complex, Complex);

두 개의 Complex 객체를 인수로 취하고 그 합을 구해 Complex형으로 리턴한다. 정수끼리 더할 때나 실수끼리 더할 때 사용하는 똑같은 + 연산자로 복소수끼리도 덧셈을 할 수 있도록 중복 정의하는 것이 바로 연산자 오버로딩이다. 고정된 타입만 제공되는 C에서는 이런 기능이 그다지 필요하지 않았었다. 그러나 C++은 사용자가 타입을 정의할 수 있게 되었고 사용자가 만든 타입도 기본 타입과 똑같은 자격을 주기 위해 연산 방법을 정의할 필요가 생겼다. 그래야 사용자가 정의한 타입이 컴파일러가 제공하는 기본 타입과 대등한 자격을 가지며 일관된 방법으로 사용할 수 있기 때문이다.

클래스가 완전한 타입이 되려면 int가 할 수 있는 모든 일을 할 수 있어야 한다. 이 절의 주제가 바로 객체의 연산 방법을 정의하는 것이며 더 직관적으로 얘기 하자면 임의의 객체에 대해 A=B+C; 가 가능하도록 하는 것이다. 물론 + 뿐만 아니라 *나 ==, % 등 대부분의 연산자도 오버로딩할 수 있다. 개념은 무척이나 간단하지만 복잡한 규칙이 존재하며 또한 많은 함정들이 도사리고 있다.

연산자 함수

시간을 표현하는 Time이라는 클래스를 정의했다면 시간끼리 더할 수 있는 방법도 제공할 필요가 있는데 시간이란 과연 어떻게 더할 수 있을까? 시간이라는 타입은 시, 분, 초의 세 가지 요소로 구성되며 적어도 int나 double 같은 기본 타입보다는 훨씬 더 복잡한 처리가 필요하다. 초는 초끼리 더하고 분은 분끼리 더해야 하며 시는 시끼리 각각 더하되 각 자리에서 60이 넘는 결과가 나오면 자리 올림 처리를 해야 한다. 예를 들어 1:26:42초라는 시간과 2:38:55초라는 시간을 더하면 3:64:97초가 되는 것이 아니라 4:5:37초가 되어야 한다.

#include <Turboc.h>

class Time

{

private:

int hour,min,sec;

public:

Time() { }

Time(int h, int m, int s) { hour=h; min=m; sec=s; }

void OutTime() {

printf("%d:%d:%d\n",hour,min,sec);

}

const Time AddTime(const Time &T) const {

Time R;

R.sec=sec + T.sec;

R.min=min + T.min;

R.hour=hour + T.hour;

R.min += R.sec/60;

R.sec %= 60;

R.hour += R.min/60;

R.min %= 60;

return R;

}

};

void main()

{

Time A(1,1,1);

Time B(2,2,2);

Time C;

A.OutTime();

B.OutTime();

C=A.AddTime(B);

C.OutTime();

}

1:36:42와 5:42:29 시간끼리 더해도 자리 올림까지 고려하여 7:19:11라는 정확한 연산을 한다. Time 클래스가 시간 포맷에 대해 캡슐화를 잘 하고 있으며 AddTime이라는 이름의 멤버 함수를 정의함으로써 시간 객체끼리 더하는 방법을 컴파일러에게 알려 주었으므로 main에서는 AddTime 함수를 호출하여 A와 B를 더하기만 하면 된다. 동작상의 문제는 전혀 없지만 연산을 위해 함수를 호출하는 방식이 연산자를 쓰는 방법에 비해 직관적이지 못하며 기본형의 연산문과 모양이 다르다는 것도 불만이다. 그래서 이런 동작을 하는 연산자 함수를 정의할 수 있다.

사실 연산자는 모양이 좀 특이한 함수라고 볼 수 있는데 인수를 취한다는 것과 연산 결과를 리턴한다는 점에서 함수와 공통적이다. 연산자 함수의 이름은 키워드 operator 다음에 연산자 기호를 써서 작성하는데 연산자 기호를 명칭으로 쓸 수 없으므로 operator라는 키워드를 앞에 두는 것이다. 덧셈 연산자 함수의 이름은 operator +가 되는데 중간의 공백은 무시되므로 operator+라고 붙여 써도 상관없다. 함수명은 명칭이므로 영문자, 숫자, _만 쓸 수 있지만 연산자 함수의 이름은 예외적으로 기호를 사용할 수 있다. 연산자 자체가 기호로 되어 있으므로 여기에는 예외를 적용할 수밖에 없다. 위 예제에서 AddTime이라는 함수의 이름을 operator +로 바꿔 보자.

class Time

{

....

const Time operator +(const Time &T) const {

....

}

};

리턴값, 인수, 본체는 그대로 두고 AddTime이라는 이름만 operator +로 바꾼 것 뿐이다. 이렇게 연산자 함수를 정의하면 이 클래스 타입의 객체를 좌변으로 가지는 + 연산자를 쓸 수 있다. main 함수의 AddTime 호출문도 다음과 같이 수정한다.

void main()

{

Time A(1,1,1);

Time B(2,2,2);

Time C;

A.OutTime();

B.OutTime();

C=A+B;

C.OutTime();

}

C=A.AddTime(B)가 C=A+B로 바뀌었는데 함수의 본체 코드가 똑같으므로 동작도 완전히 동일하다. 그렇다면 AddTime 일반 함수와 operator +연산자 함수는 과연 어떤 차이점이 있을까 비교해 보자.

첫 번째로 연산자 형태의 호출 방식이 길이가 짧아 타이핑하기 편리하며 오타가 발생할 가능성도 극히 낮다.

두 번째로 연산자 함수는 호출 형식이 연산문 형태로 작성되기 때문에 훨씬 더 직관적이고 기본형의 연산 방법과 일치하므로 사용하기 쉽다. A+B라는 표현식 자체가 A와 B를 더한다는 것을 잘 표현한다.

세 번째로 연산자는 함수와는 달리 우선 순위와 결합 방향의 개념이 있어 괄호를 쓰지 않아도 연산 순서가 자동으로 적용되어 편리하다. 어떤 객체 A와 B의 곱과 C와 D의 곱을 더해 E에 대입한다고 해 보자.

일반 함수 : E=(A.Multi(B)).Add(C.Multi(D));

연산자 함수 : E=A*B+C*D;

어느쪽이 더 보기 좋고 읽기 좋은지는 굳이 강조하지 않더라도 쉽게 판단될 것이다.

오버로딩 규칙

연산자 오버로딩은 아주 멋진 기능임에 틀림없지만 아주 많은 규칙과 제약이 존재한다. 이 규칙들은 연산자 오버로딩에 따른 부작용을 해소하고 안전하게 연산자를 사용할 수 있도록 마련된 것들이다. .

1) 연산자 오버로딩은 이미 존재하는 연산자의 기능을 조금 바꾸는 것이지 아예 새로운 연산자를 만드는 것은 아니다. 원래 C++ 언어가 제공하는 기존 연산자만 오버로딩의 대상이며 C++이 제공하지 않는 연산자를 임의로 만들 수는 없다. 예를 들어 C++은 누승 연산자를 제공하지 않는데(대신 pow라는 표준 함수를 제공한다.) 이런 목적으로 **라는 완전히 새로운 연산자를 정의하고 싶으며 C++이 이를 허용한다고 해 보자. 그렇다면 c=a**b; 라는 연산식이 가능해지는데 컴파일러가 이 식을 해석할 때 두 가지 모호한 상황이 발생한다.

우선 이 연산식을 a를 b만큼 누승하라는 것인지 아니면 a와 포인터 b가 가리키는 곳의 내용을 읽어 곱하라는 것인지를 판별할 수 없다. a**b는 a 누승 b로 볼 수도 있고 a*(*b)로 볼 수도 있어 구문 분석 단계에서 모호함이 발생한다. 그리고 새로 만들어진 연산자의 우선 순위와 결합 순서를 어떻게 정할 것인지도 문제가 된다. c=a**b+d라는 식이 있을 때 누승이 먼저인지 덧셈이 먼저인지를 컴파일러가 임의로 결정할 수 없다. 만약 이것을 정 가능하게 하자면 사용자가 새로 만든 연산자의 우선 순위를 지정할 수 있는 문법을 만들어야 하는데 연산자 하나를 쓰기 위해 이런 복잡한 지정까지 해야 한다면 차라리 안 쓰는 것이 더 나을 것이다.

C++이 사용하지 않는 문자인 $, @ 같은 기호를 새로운 연산자로 정의할 수 있다면 나름대로 편리하겠지만 오버로딩이란 이미 존재하는 것을 중복 정의하는 것이지 없는 걸 아예 새로 만드는 것이 아니므로 이 경우도 부적당하다. 사용자가 임의로 연산자를 만들 수 있도록 하는 것은 이론상 분명히 가능하지만 이런 기능을 지원하기 위해 대폭적인 문법의 확장이 필요하며 예기치 못한 부작용이 생길 수 있다. 득보다 실이 더 많기 때문에 C++은 아예 새로운 연산자를 만드는 문법은 제공하지 않는다.

2) 이미 존재하는 연산자 중에도 오버로딩의 대상이 아닌 것들이 있다. 다음 연산자들은 기능을 변경할 수 없다. 즉, 오버로딩의 대상이 아니다.

.(구조체 멤버 연산자) ::(범위 연산자) ?:(삼항 조건 연산자)

.*( 멤버 포인터 연산자) sizeof typeid

static_cast dynamic_cast const_cast

reinterpret_cast new delete

이 연산자들은 C++의 클래스와 관련된 중요한 동작을 하기 때문에 클래스를 기반으로 하는 연산자 오버로딩의 재료로 쓰기에는 무리가 있다. 클래스의 멤버를 지정하는 . 연산자의 동작을 바꿔 버리면 어떤 혼란이 올지 가히 상상이 갈 것이다. 삼항 조건 연산자는 피연산자가 셋이나 되기 때문에 오버로딩을 하더라도 다른 연산자에 비해 더 복잡한 규칙이 필요할 것으므로 아예 오버로딩하지 못하도록 되어 있다. 이런 몇 가지 특수한 연산자만 빼고 나머지 연산자들은 모두 오버로딩할 수 있으므로 연산자가 부족한 상황은 발생하지 않을 것이다.

오버로딩 가능한 연산자 중에도 가급적 오버로딩을 삼가해야 하는 것도 있다. 언어가 제공하는 연산자는 우선순위 규칙이 명확하게 정의되어 있어 좌우의 피연산자 중 어떤 것이 먼저 평가될지 예측 가능하다. 그러나 함수로 오버로딩되면 인수의 평가 순서가 정의되지 않으므로 원치 않는 부작용이 발생할 수도 있다. 예를 들어 콤마 연산자의 경우 좌에서 우로 순서대로 평가하지만 함수로 오버로딩되면 이런 우선 순위가 더 이상 적용되지 않는다. 함수의 인수는 보통 우에서 좌로 평가되어 연산자의 평가 순서와는 반대로 되어 있는데 순서가 의미가 있을 때는 문제가 될 수도 있다.

&&, || 논리 연산자의 경우 문법적으로는 허용된다 하더라도 그 효과를 예측하기 어려우므로 가급적이면 이 연산자들은 오버로딩하지 말아야 한다. 사실 이 연산자들이 오버로딩되어야 하는 경우도 거의 없는 편이다.

3) 기존 연산자의 기능을 바꾸더라도 연산자의 본래 형태는 변경할 수 없다. 여기서 본래 형태라고 하는 것은 피연산자의 개수와 우선 순위를 말한다. + 연산자는 원래 피연산자를 두 개 취하는 이항 연산자이므로 오버로딩된 후에도 이항 연산자여야 하며 반드시 피연산자 두 개를 가져야 한다.

우선 순위나 결합 순서도 변경할 수 없다. + 연산자의 기능을 바꾸어 곱셈이나 누승을 하도록 오버로딩했다 하더라도 이 연산자의 우선 순위는 원래의 + 연산자의 것과 동일하다. 컴파일러는 연산자가 논리적으로 어떤 연산을 하는지 다른 연산과의 관계가 어떠한지까지는 판단할 수 없다. 따라서 완전히 새로운 연산을 정의하고자 할 때 적당한 우선 순위를 가지는 연산자를 골라 오버로딩해야 한다.

다른 언어는 누승 연산을 위해 ^ 기호를 사용한다. 그래서 ^ 연산자를 누승 연산자로 재정의한다면 베이직 언어처럼 편리하게 누승 연산을 할 수 있을 것이다. 그러나 C++에서 원래의 ^ 연산자는 곱셈보다 우선 순위가 늦고 심지어 덧셈이나 뺄셈보다도 우선 순위가 늦어 모양이 직관적이더라도 누승 연산자로 재정의하기에는 어울리지 않는다. 2^3+4는 12여야 상식적이지만 +의 순위가 높아 128이 되어 버린다.

4) 오버로딩된 연산자의 피연산자 중 적어도 하나는 사용자 정의형이어야 한다. 연산자의 기능을 바꾸는 목적은 객체에 대한 고유한 연산 방법을 정의하기 위한 것이므로 반드시 객체와 관련있는 연산자만 중복 정의할 수 있다. C++이 기본적으로 제공하는 타입에 대해서는 연산자를 오버로딩할 수 없다. 만약 다음과 같은 연산자 함수를 만들 수 있다고 해 보자.

int operator +(int a, int b)

{

....

}

이 함수는 정수형의 덧셈 연산을 완전히 새로 정의하는데 정수형의 덧셈은 언어의 가장 기본적인 동작이고 CPU의 원자적인 연산이기 때문에 이 동작이 바뀌게 되면 파급효과가 너무 엄청날 것이다. 그래서 컴파일러는 기본형에 대한 연산자 오버로딩은 거부하며 "최소한 하나의 피연산자는 클래스 타입이어야 한다"는 에러 메시지를 출력한다.

사실 위에서 보인 두 개의 정수를 더하는 연산자는 시스템에 이미 존재한다. 오버로딩이란 인수의 개수나 타입이 달라야 하므로 위 연산자는 오버로딩의 대상이 될 수도 없다. 오버로딩이란 이미 존재하는 함수의 기능을 바꾸는 것이 아니라 타입에 따라 다르게 동작하는 함수를 중복 정의하는 것이므로 기본 타입에 대한 연산자는 만들 수 없는 것이다.

강제적인 규칙은 아니지만 연산자의 논리적 의미는 가급적 유지하는 것이 바람직하다. + 연산자를 오버로딩한다면 어떤 클래스에 대해서라도 덧셈의 의미를 가지는 연산을 하는 것이 좋다. 그래야 연산자에 대한 사용자들의 기존 상식을 보호할 수 있다. + 연산자를 더하기와는 전혀 상관없는 다른 연산으로 오버로딩해 버리면 이 객체를 사용하는 사람은 혼란스러워할 것이다. 그러나 이 규칙은 어디까지나 권장 사항일 뿐이므로 불가피할 경우는 지키지 않아도 상관없다.

예를 들어 표준 입출력 스트림인 cout은 쉬프트 연산자인 << 를 모양이 마음에 든다는 이유로 출력 연산자로 재정의하는 만행을 저지르기도 한다. 기본 문법에는 제공되지 않는 완전히 새로운 연산을 정의할 경우는 적당한 우선 순위를 가지고 모양이 좀 그럴싸해보이는 연산자 하나를 선택할 수밖에 없을 것이다.

연산자를 적절하게 오버로딩하면 복잡한 것을 간결하게 논리적으로 표기할 수 있고 어떤 동작을 한다는 것을 명확하게 표현할 수 있어 가독성에 유리하다. 또한 이미 익숙해진 연산자를 직관적인 방법으로 활용할 수 있으므로 생산성 향상에도 큰 기여를 한다. 그러나 연산자 오버로딩에는 여러 가지 부작용도 있음을 알아야 한다. 모든 문법이 마찬가지겠지만 연산자 오버로딩은 꼭 필요할 때, 그리고 논리적으로 무리가 없을 때에 한해 규칙에 맞게 안전하게 사용해야 한다.

C++의 철학은 작성하는 사람을 편리하게 하는 것보다는 만들어진 객체를 사용하는 사람을 편하게 하자는 데 있다. 보다시피 연산자 오버로딩이란 복잡한 규칙이 존재하고 섣불리 잘못 만들 경우 오동작을 할 위험이 도처에 도사리고 있지만 한 번만 잘 만들어 놓으면 여러 사람이 편리하게 사용할 수 있는 그런 장치이다.

함수와 예외 처리

예외를 던지는 throw는 보통 try 블록 내부에 있어야 한다. 그러나 함수 안에서는 try 블록없이 throw만 있을 수도 있다. 이때는 함수를 호출하는 호출원이 try 블록을 가져야 한다. 다음 예제는 0으로 나누는 함수 divide를 작성하고 이 함수에서 인수로 전달된 d가 0일 때 throw로 예외를 던진다. main에서 4번 throw를 호출하는데 각 경우에 어떻게 처리되는지 보자.

#include <Turboc.h>

void divide(int a, int d)

{

if (d == 0) throw "0으로는 나눌 수 없습니다.";

printf("나누기 결과 = %d입니다.\n",a/d);

}

void main()

{

try {

divide(10,0);

}

catch(const char *message) {

puts(message);

}

divide(10,5);

// divide(2,0);

try {

divide(20,0);

}

catch(int code) {

printf("%d번 에러가 발생했습니다.\n",code);

}

//*/

}

함수 실행중에 throw를 만나면 대응되는 catch를 찾기 위해 자신을 호출한 호출원을 거슬러 올라가야 한다. 첫 번째 divide 호출문에서 예외가 발생하면 divide 함수는 자신을 호출한 main으로 돌아와서 대응되는 catch문을 찾아 이 코드를 실행한다. catch는 throw가 던진 에러 메시지 문자열을 화면으로 그대로 출력할 것이다. 만약 main과 divide 사이에 다른 함수들이 있더라도 마찬가지로 main까지 복귀한 후 예외가 처리된다.

함수가 호출될 때는 스택에 각 함수의 스택 프레임이 생성되며 스택 프레임에는 함수 실행에 필요한 여러 가지 정보들이 저장된다. 함수가 리턴할 때 스택 프레임은 정확하게 호출 전의 상태로 돌아가도록 되어 있다. 예외가 발생했을 때 호출원의 catch로 곧바로 점프해 버리면 스택이 항상성을 잃어 버리므로 이후 프로그램이 제대로 실행될 수 없을 것이다. 그래서 throw는 호출원으로 돌아가기 전에 자신과 자신을 호출한 함수의 스택을 모두 정리하고 돌아가는데 이를 스택 되감기(Stack Unwinding)라고 한다.

첫 번째 divide 호출문이 예외를 던질 때 main의 catch가 이 예외를 처리한 후 그 다음 문장을 아무 이상없이 실행할 수 있는 이유는 throw가 스택 되감기를 하여 main의 스택 프레임을 divide 호출 전의 상태로 복구하기 때문이다. 두 번째 divide(10,5)는 올바른 인수를 전달했으므로 예외가 발생되지 않으며 호출 후 정상적인 절차대로 리턴한다.

세 번째 divide(2,0) 호출은 두 번째 인수가 0이므로 예외가 발생하는데 이때 이 예외를 받아줄 catch문이 없다. 함수 호출부가 try 블록에 있지 않기 때문인데 이때는 예외를 처리할 수 없으므로 디폴트 처리되어 프로그램이 강제로 종료된다. 설사 try안에 있더라도 예외를 받아줄 catch가 없으면 이때도 처리되지 않는데 네 번째 호출문 divide(20,0)의 경우 try안에 있고 catch도 있지만 divide가 던지는 char * 타입의 catch는 없으므로 역시 처리되지 않고 프로그램은 종료된다.

throw는 대응되는 try 블록의 catch를 찾기 위해 스택에서 위쪽 함수를 찾아 올라가면서 호출 스택을 차례대로 정리하는데 이때 각 함수들이 지역적으로 선언한 객체들도 정상적으로 파괴된다. 다음 예제를 통해 스택을 되감는 절차를 연구해 보자.

#include <Turboc.h>

class C

{

int a;

public:

C() { puts("생성자 호출"); }

~C() { puts("파괴자 호출"); }

};

void divide(int a, int d)

{

if (d == 0) throw "0으로는 나눌 수 없습니다.";

printf("나누기 결과 = %d입니다.\n",a/d);

}

void calc(int t,const char *m)

{

C c;

divide(10,0);

}

void main()

{

try {

calc(1,"계산");

}

catch(const char *message) {

puts(message);

}

puts("프로그램이 종료됩니다.");

}

main의 try 블록에서 calc를 부르고 calc는 지역 객체 C를 선언한다. 그리고 예외를 일으키는 divide(10,0)을 호출하는데 이 함수에서 throw에 의해 문자열 예외가 던져진다. 이 때의 스택 상황은 다음과 같을 것이다.

divide에서 예외가 발생했으므로 이 함수는 더 이상 실행할 수 없다. 그래서 이 예외를 처리할 catch문을 찾는데 함수 내부에서는 catch가 없으므로 일단 자신을 호출한 calc 함수로 돌아간다. 이 과정에서 자신의 스택 프레임은 정리하는데 이렇게 하지 않으면 호출원이 예외를 처리하더라도 제대로 실행될 수 없기 때문이다.

calc에서 다시 catch를 찾는데 이 함수도 catch를 가지고 있지 않으므로 같은 방식으로 스택을 정리한다. 이때 calc의 인수 t와 m, 지역변수 C가 파괴되는데 C는 객체이므로 정상적인 파괴를 위해 파괴자가 호출된다. calc가 main으로 리턴하면 main의 catch(char *)로 점프하여 예외를 처리한다. 스택 되감기를 하면서 리턴되는 함수의 모든 지역 객체를 파괴하는데 만약 파괴자를 호출하지 않는다면 예외만 처리될 뿐 생성된 객체들이 제대로 해제되지 않아 프로그램의 상태는 여전히 불안해질 것이다. 파괴자는 단순히 메모리만 정리하는 것이 아니라 때로는 DB 연결 해제, 프로그램 상태 변경 등의 중요한 일을 할 수도 있으므로 반드시 호출해야 한다.

throw가 대응되는 catch를 찾기 위해 스택 되감기를 해야 하는 이유는 아주 명백하다. throw는 catch로의 점프 동작을 하는데 함수간에 아무렇게나 점프를 해 버리면 스택의 호출 정보는 엉망이 되어 버린다. 호출원으로 돌아갈 때는 스택도 호출원의 것으로 정확하게 복구해야 하며 그러기 위해서는 자신을 호출한 모든 함수의 스택을 일일이 정리해야 하는 것이다. 위 예에서 main의 마지막에 있는 puts가 제대로 실행되려면 catch가 예외를 처리한 후 스택의 최상단에는 main의 스택 프레임이 있어야 하며 그러기 위해서는 divide의 throw가 divide와 calc의 스택을 정리해야 하는 것이다.

중첩 예외 처리

예외 처리 구문은 중첩 가능하다. 즉 try 블록안에 또 다른 try 블록이 있을 수 있으며 중첩 단계에는 별다른 제약이 없다. 다음 예제는 학번, 이름, 나이를 입력받아 그대로 출력하는데 학번과 나이는 반드시 양수여야 하며 이름은 최소한 4자 이상이어야 한다. 한국 사람 이름은 최소한 2글자 이상이므로 아무리 짧아도 4바이트 이상이어야 한다는 규칙은 아주 자연스럽다.

#include <Turboc.h>

void main()

{

int Num;

int Age;

char Name[128];

try {

printf("학번을 입력하시오 : ");

scanf("%d",&Num);

fflush(stdin);

if (Num <= 0) throw Num;

try {

printf("이름을 입력하시오 : ");

gets(Name);

if (strlen(Name) < 4) throw "이름이 너무 짧습니다";

printf("나이를 입력하시오 : ");

scanf("%d",&Age);

if (Age <= 0) throw Age;

printf("입력한 정보 => 학번:%d, 이름:%s, 나이:%d\n",Num,Name,Age);

}

catch(const char *Message) {

puts(Message);

}

catch(int) {

throw;

}

catch(int n) {

printf("%d는 음수이므로 적합하지 않습니다.\n",n);

}

최초 바깥쪽의 try 블록에서 학번 Num을 입력받는데 이 값이 음수(0도 포함)일 경우 잘못된 값이므로 Num을 예외로 던진다. 이 예외는 바깥쪽의 catch(int n)가 받아 처리할 것이다. 학번이 제대로 입력되었을 경우 이름과 나이를 입력받는데 이름 길이가 4보다 작을 경우 문자열로 된 예외를 던진다. 이 예외는 안쪽의 catch(const char *)가 받아서 처리한다.

나이가 음수일 경우는 안쪽의 catch(int)로 예외를 던진다. 이때 안쪽에서 정수형 예외를 처리하기에 부적당하다거나 아니면 이미 바깥쪽에서 같은 종류의 예외를 처리하고 있다면 안쪽의 catch에서는 이 예외를 직접 처리하지 않고 바깥쪽의 예외 처리기에게 넘기는 것이 더 편리하다. catch 블록에서 예외를 다시 던질 때는 예외 객체를 지정할 필요없이 throw 명령만 단독으로 사용한다. 받은 객체를 그대로 다시 넘기는 것이므로 예외 객체를 명시할 필요가 없으며 직접 처리하지 않으므로 catch의 괄호안에 예외 객체의 이름을 줄 필요도 없다.

catch에서 바깥쪽 catch로 점프할 때는 throw 명령만 단독으로 사용하는데 만약 바깥쪽에 적절한 catch가 없으면 이 예외는 디폴트 처리되어 프로그램이 강제 종료된다. 이 예제는 한 함수안에서 try를 중첩시켜 다소 억지스러운 면이 있는데 예외를 던지는 함수끼로 서로 호출하다 보면 예외 처리 블록을 중첩해야 하는 경우가 있다.

예외 클래스 계층

예외 클래스도 클래스이므로 상속할 수 있고 다형성도 성립한다. 비슷한 종류의 예외라면 예외 클래스의 계층을 구성하여 반복되는 코드를 줄일 수 있고 가상 함수에 의해 예외 처리에도 다형성을 적용할 수 있다. 다음 예제는 숫자를 입력받되 100 이하의 양의 짝수만 입력받으며 나머지 숫자는 모두 예외로 처리한다.

#include <Turboc.h>

class ExNegative

{

protected:

int Number;

public:

ExNegative(int n) : Number(n) { }

virtual void PrintError() {

printf("%d는 음수이므로 잘못된 값입니다.\n",Number);

}

};

class ExTooBig : public ExNegative

{

public:

ExTooBig(int n) : ExNegative(n) { }

virtual void PrintError() {

printf("%d는 너무 큽니다. 100보다 작아야 합니다.\n",Number);

}

};

class ExOdd : public ExTooBig

{

public:

ExOdd(int n) : ExTooBig(n) { }

virtual void PrintError() {

printf("%d는 홀수입니다. 짝수여야 합니다.\n",Number);

}

};

void main()

{

int n;

for (;;) {

try {

printf("숫자를 입력하세요(끝낼 때 0) : ");

scanf("%d",&n);

if (n == 0) break;

if (n < 0) throw ExNegative(n);

if (n > 100) throw ExTooBig(n);

if (n % 2 != 0) throw ExOdd(n);

printf("%d 숫자는 규칙에 맞는 숫자입니다.\n",n);

}

catch (ExNegative &e) {

e.PrintError();

}

음수에 대한 예외를 처리하는 ExNegative를 가장 최상위 클래스로 두고 음수에 대한 에러 메시지를 출력하는 PrintError를 가상 함수로 정의했다. 그리고 이 클래스를 상속하여 ExTooBig이라는 클래스를 정의하여 100을 초과하는 큰 수에 대한 예외를 처리하도록 했으며 ExTooBig으로부터 홀수 예외를 처리하는 ExOdd라는 클래스를 정의했다. 루트 예외 클래스인 ExNegative가 PrintError를 가상 함수로 정의했으므로 파생 클래스의 PrintError도 모두 동적으로 결합되는 가상 함수이다.

main에서 이 비슷한 예외들을 처리할 때는 에러 내용에 맞는 예외 객체를 생성하여 던지기만 하면 된다. catch는 각 예외 객체를 따로 처리할 필요없이 루트 예외 객체인 ExNegative에 대해서만 처리하면 되는데 왜냐하면 이 클래스로부터 파생된 클래스들은 모두 ExNegative와 IS A 관계에 있기 때문이다. catch에는 전달받은 예외 객체 e로부터 PrintError 함수만 호출하면 e의 타입에 맞는 가상 함수를 호출할 수 있어 예외의 종류를 판별하는 일은 신경쓰지 않아도 된다. e.PrintError가 다형적으로 에러를 처리한다.

예외의 비용

이상으로 C++의 예외 처리 기능에 대해 연구해 봤는데 언어 차원에서 예외 처리 구문을 지원한다는데서 큰 의미를 찾을 수 있다. 그러나 고도로 정교한 프로젝트가 아닌 한 실무에서 이 기능을 전면적으로 사용하는 데 대해서는 다소 회의적으로 평가하는 사람도 있다. 왜냐하면 C++의 예외 처리 기능을 사용하면 프로그램의 성능이 눈에 뛸 정도로 느려지기 때문이다. 프로그램의 안정성과 유지, 보수의 편의성은 증가하지만 프로그램이 비대해지고 느려지는 반대 급부를 쉽사리 무시할 수는 없다.

예외 처리 구문에 의한 성능 저하는 상당한 정도인데 특히 스택 되감기 기능은 호출한 모든 스택을 정리하는 대 공사를 한다는 점만 봐도 얼마나 성능에 취약할지 상상이 간다.

그러나 try, catch라는 키워드를 쓰는 것만으로도 프로그램의 용량은 무시못할 정도로 비대해지는 또 다른 문제가 있다. 왜냐하면 발생 빈도가 아무리 희박하다 하더라도 예외가 발생했을 때의 코드를 모조리 작성해 넣어야 하기 때문이다. 그래서 성능이 아주 중요하다면 C++의 예외 처리 기능을 사용하지 말아야 하며 전통적인 if문을 사용하는 것이 더 바람직할지도 모른다.

C++의 예외 처리 기능은 모든 면에서 완벽하다고 할 수 없고 컴파일러의 지원도 아직 미완성 단계이다. 아무리 좋아 보여도 전통적인 if 문을 모조리 예외 처리 구문으로 바꿀 수는 없다. 상황에 따라 예외를 처리하는 방법은 특수하기 때문에 모든 if문이 무난하게 예외 처리 구문으로 잘 변환되는 것은 아니다. 함수 내부에서 예외가 발생했을 때 호출원을 거꾸로 거슬러 올라가면서 스택을 정리하고 모든 객체를 파괴하는 것은 멋진 기능이기는 하다. 아무리 깊은 함수에서 예외가 발생했더라도 이를 잡아 낼 수 있으니 말이다. 그러나 동적으로 할당된 메모리는 그렇지 못한데 다음 예제를 보자.

#include <Turboc.h>

class SomeClass { };

void calc()

{

SomeClass obj;

char *p=(char *)malloc(1000);

if (TRUE/*예외 발생*/) throw 1;

free(p);

}

void main()

{

try {

calc();

}

catch(int) {

puts("정수형 예외 발생");

}

calc가 예외를 일으킬 때 지역 객체 obj의 파괴자가 호출되어 필요한 정리를 한다. obj가 아무리 많은 메모리를 쓰더라도 문제되지 않는다. 그러나 예외 발생전에 malloc이나 new로 할당한 메모리는 해제될 기회가 없어 메모리 누수가 발생할 것이다. 메모리 할당 원칙에 의해 일단 할당한 메모리는 명시적으로 해제하지 않는 한 임의로 회수할 수 없다. throw는 남은 뒷부분의 코드를 무시하고 무조건 예외 핸들러로 점프해 버리기 때문이다.

예외 처리 기능은 기본적으로 예외가 발생했을 때 적당한 핸들러를 찾아 점프하는 기능이다. 제어를 옮길 뿐이지 그 자체로 예외를 복구하지는 못한다. catch에서 어떤 조치를 취한 다음에 try 블록 안으로 다시 리턴할 수는 없다. 다음 예제를 보자.

#include <Turboc.h>

void main()

{

int i;

try {

printf("1~100사이의 정수를 입력하시오 : ");

scanf("%d",&i);

if (i < 1 || i > 100) throw i;

printf("입력한 수 = %d\n",i);

}

catch(int i) {

printf("%d는 1~100 사이의 정수가 아닙니다.\n",i);

}

1~100사이의 정수만 입력받기 위해 규칙에 어긋난 변수가 입력되면 예외 처리하도록 했다. 잘 동작하지만 틀린 입력을 적발할 수 있을 뿐이지 다시 입력하도록 하지는 못한다. 그렇게 하려면 while이나 for 등의 루프로 감싸 정확한 값이 입력될 때까지 반복하는 수밖에 없다. 그렇다면 다음과 같이 하는 것과는 무엇이 다른가?

for (;;) {

printf("1~100사이의 정수를 입력하시오 : ");

scanf("%d",&i);

if (i >= 1 && i <= 100) break;

printf("%d는 1~100 사이의 정수가 아닙니다.\n",i);

}

printf("입력한 수 = %d\n",i);

전통적인 루프로 성공할 때까지 반복하도록 했다. 어차피 루프가 필요하다면 그냥 if문으로 점검하는 것이 훨씬 더 편리하다. 깊은 호출 단계의 함수라면 예외 처리 구문의 장점이 드러나지만 적어도 단일 함수내에서는 if문이 훨씬 더 읽기 쉽고 성능도 좋다. 이 외에도 예외 처리는 스택 되감기 중 파괴자에서 예외 발생시의 애매함, 예외 핸들러에서 예외가 발생한 지점을 알 수 없다는 한계들이 존재한다. 그리고 견고한 프로그램을 만드는 것도 중요하지만 발생가능한 모든 예외를 일일이 다 처리한다는 것도 사실 비현실적이다.

아무리 좋은 기능이라도 남발하면 좋지 않으므로 꼭 필요한 곳에 잘 조절해서 쓰도록 하자. 비주얼 C++의 경우 예외 처리 구문을 사용할 것인지 아닌지를 프로젝트 옵션으로 선택할 수 있도록 되어 있는데 이 옵션을 끄면 스택을 되감는 코드는 생성하지 않는다. 컴파일러가 이런 옵션을 제공한다는 것은 무조건적인 사용이 좋기만 한 것이 아니라는 반증이기도 하다.