28-2-다.오버로딩 규칙

여기까지 객체의 연산을 위해 연산자를 오버로딩하는 두 가지 방법에 대해 연구해 보았는데 지금까지의 내용만 해도 그다지 쉽지는 않았을 것이다. 연산자 오버로딩은 아주 멋진 기능임에 틀림없지만 아주 많은 규칙과 제약이 존재한다. 이 규칙들은 연산자 오버로딩에 따른 부작용을 해소하고 안전하게 연산자를 사용할 수 있도록 마련된 것들이다. 내용이 좀 많기는 하지만 상식 범위를 크게 벗어나는 것은 없으므로 쉽게 익숙해질 수 있을 것이다.

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

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

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

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

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

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

static_cast dynamic_cast const_cast

reinterpret_cast new delete

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

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

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

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

const Time Time::operator +(Time &T) // 가능

const Time Time::operator +(int i) // 가능

const Time operator +(Time &T,int i) // 가능

const Time Time::operator +(Time &T1,Time &T2) // 불가능

const Time operator +(Time &T) // 불가능

const Time operator +(void) // 불가능

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

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

아주 당연한 얘기가 되겠지만 한 클래스가 하나의 연산자를 여러 가지 피연산자 타입에 대해 오버로딩할 수 있다. 오버로딩이란 인수의 개수나 타입이 다르면 항상 성립하므로 여러 개의 피연산자에 대한 연산자를 제공할 수 있다는 얘기다. Time 클래스에 다음 두 덧셈 연산자가 동시에 정의되어도 아무런 문제가 없다.

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

const Time operator +(int s) const { .... }

위쪽 함수는 시간에 시간을 더하는 것이고 아래쪽 함수는 시간에 정수를 더하는 것이다. 호출부에서 피연산자 타입을 보고 어떤 덧셈을 원하는지 알 수 있으므로 모호하지 않으며 실용성도 있다. 원한다면 시간에 실수나 Date를 더하는 + 연산자도 얼마든지 중복 정의할 수 있다.

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

int operator +(int a, int b)

{

....

}

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

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

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

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

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

C++의 철학은 작성하는 사람을 편리하게 하는 것보다는 만들어진 객체를 사용하는 사람을 편하게 하자는 데 있다. 보다시피 연산자 오버로딩이란 복잡한 규칙이 존재하고 섣불리 잘못 만들 경우 오동작을 할 위험이 도처에 도사리고 있지만 한 번만 잘 만들어 놓으면 여러 사람이 편리하게 사용할 수 있는 그런 장치이다. 예를 들어 str이라는 문자열에 주어진 문자열 s1, s2, s3를 차례대로 앞쪽에 삽입하고 싶다고 하자. 가령 str이 "aaa", s1이 "111", s2가 "222", s3가 "333"이라고 할 때 str을 "333222111aaa"로 만들고 싶은 것이다. 문자열을 뒤쪽에 연결하는 것은 strcat로 간단하게 해결할 수 있지만 앞쪽 연결은 표준 함수의 지원이 없어 직접 해야 한다. C의 해결 방법은 다음과 같다.

char temp[256]; strcpy(temp,str); strcpy(str,s1); strcat(str,temp); strcpy(temp,str); strcpy(str,s2); strcat(str,temp); strcpy(temp,str); strcpy(str,s3); strcat(str,temp);

앞쪽에 삽입해야 하므로 temp라는 임시 버퍼도 필요하고 복사 및 연결을 여러 번 반복적으로 수행해야 한다. strcat 표준 함수는 뒤쪽에 덧붙이기만 할 뿐 앞쪽에 삽입하지는 못하기 때문이다. 뿐만 아니라 str이 나머지 문자열을 모두 포함할 수 있는 충분한 길이를 가지는가도 항상 신경써야 하며 그렇지 못할 경우 위험해지기까지 한다. 물론 sprintf라는 좀 더 간단한 방법도 있고 앞쪽에 삽입하는 함수를 따로 만들 수도 있지만 비효율적이고 불편하기는 마찬가지다. 그러나 이 문제를 C++ 객체와 연산자 오버로딩을 사용하면 정말 간단해진다.

str=s3+s2+s1+str;

단, 한 줄로 끝난다. 단순히 코드의 길이만 짧아지는 것이 아니라 문제를 푸는 과정이 단순해지는 것이다. 물론 이 코드의 내부에서는 C의 코드와 똑같은 동작을 하겠지만 사용자에게는 이런 상세한 과정이 숨겨지므로 몰라도 상관없다. 이 연산이 제대로 수행되기 위해서는 operator +가 연쇄적인 연산을 잘 지원할 수 있도록 해야 하며 교환 법칙도 만족해야 하고 객체가 버퍼를 지능적으로 관리할 필요도 있다. 물론 이렇게 만들기 위해서는 덧셈 연산자뿐만 아니라 생성자, 파괴자, 대입 연산자 등도 규칙에 맞게 잘 작성해야 한다. 하지만 객체를 작성하는 개발자 혼자서 한 번만 이런 모든 부담을 감수하면 이 객체를 사용하는 수천, 수만명의 사용자는 아주 행복하게 이 객체를 잘 활용할 수 있을 것이다.