C++ of the Day #14 - Overload resolution before access checking

오늘 내용은 뉴스 그룹에서 가져왔습니다.((c.l.c.m:overload resolution before access checking))

Question

struct S
{
public:
  void foo(long);
private:
  void foo(int);
};

....
S s;
s.foo(1);       // error, S::foo(int) is private

위의 코드와 같이 s.foo(1) 문은 컴파일 에러가 발생합니다. 이유는 C++ 컴파일러가 access checking을 하기 전에 overload resolution을 먼저 수행하기 때문입니다. 즉, 접근 권한에 관계 없이 두개의 foo 함수중 어떤 것이 인자 '1'에 더 적합한가를 확인하는데 이때 literal 1은 int이기 때문에 foo(int) 를 수행하도록 결정됩니다. 하지만 함수를 결정한 후 접근 권한을 검사해보면 이 foo(int)는 private이기 때문에 컴파일 에러가 발생하는 것이죠.

만약 overload resolution이 접근 가능한 멤버에 대해서만 동작한다면 위의 코드는 컴파일 에러 없이 foo(long)을 호출할 수 있었겠죠?
오늘의 질문은 이것입니다.

1. C++에서 컴파일을 이렇게 하는 타당한 이유는 무엇인가?
2. 다른 말로 하자면, private 멤버는 왜 보이지 않는 것(invisible)이 아니라 접근 불가능(inaccessible)인가?

Answer

먼저 첫번째 질문에 대한 답은 애석하게도 "뭐 특별한 이유가 있었던 것은 아니다"입니다. :-(

그래도 가장 그럴듯한 답은 아래 내용이 아닐까 합니다. ((D&E 책에 보면 Bjarne Stroustrup씨가 왜 이렇게 설계했는지 기억을 못한다고 하네요. ;-) ))

The design goal was that, as long as the code remains well-formed, changing a member's access level shall not change the semantics of the program.

즉, 코드가 계속 유효하면서 멤버의 접근 권한만 바뀌는 경우, 프로그램의 의미가 바뀌지 않도록 하기 위해서라는군요. 예를 들어 볼까요?

class Hello
{
public:
  void greet(long) {
    cout << "welcome";
  }
private:
  void greet(int){
    cout << "unwelcome";
  }
};
....
S s;
s.foo(1);       // call greet(long) if private: means not inaccessible but invisible.

위의 코드에서 만약 private이 invisible을 의미하였다면 overload resolution의 후보에서 greet(int)는 빠지게 되므로 greet(long)이 호출됩니다. int 에서 long 변환은 자동으로 가능하기 때문이죠.

그런데 이 코드에서 나머지 부분은 가만히 두고 private만 public으로 바꾸게 되면 literal 1은 int이므로 greet(int)가 호출됩니다. 즉, 코드는 계속 컴파일 및 실행이 되는데 전혀 다른 의미로 수행되는거죠. 단지 함수의 접근 권한만 바꾸었을 뿐인데 말이죠.

따라서 먼저 overload resolution을 처리하고 접근 권한을 확인하는 방법으로 이런 의도적이지 않은 실수를 방지할 수 있습니다. 프로그램의 의미가 모르는 사이에 바뀌는 것보다는 컴파일 에러가 발생하는게 좋겠죠?

이런 기능을 위해 C++ 언어가 위와 같은 규칙을 가지게 된것은 아니지만 이 규칙때문에 이런 기능이 생겼다고 할 수 있을 것 같습니다. 에공 뭔 말인지~ ;-)