Skip to main content

C++ of the Day #24 - 다시 ADL

Question



전에도 C++ of the Day #7 - ADL (Argument Dependent Lookup)글에서 ADL을 다룬 적이 있는데 이번엔 좀 더 난이도 있는 버전입니다. (그리고 더 자세한 설명이 있는 버전입니다. ;-) )

내용은 뉴스그룹에서 가져왔습니다. ((VC8 compiler behavior?))


template
ostream& operator<<(ostream& os, const vector& v) // (1)
{
// ...
}

namespace formatter
{
template
struct bracketed
{
bracketed(const T& t) : value(t) {}
T value;
};

template
ostream& operator<<(ostream& os, const bracketed& v) // (2)
{
return os << '[' << v.value << ']'; // (3)
}
};

int main()
{
using formatter::bracketed;

int n = 21014;
vector v;

cout << bracketed(n) << endl; // (4)
//cout << bracketed >(v) << endl; // (5)
}


위와 같은 코드에서 질문은.


  1. 왜 (4)번 라인은 컴파일이 될까?

  2. 왜 (5)번 라인은 컴파일이 되지 않을까?



답을 보시기 전에 한번 생각해 보세요.

Answer



먼저 잠깐 ADL 규칙에서 후보 함수들을 찾아내는 규칙에 대해 간단히 살펴 보면 다음과 같습니다.


  1. 호출되는 함수의 각 argument가 존재하는 class나 namespace내의 같은 이름의 함수들

  2. 일반적인 name lookup 방법에 의해 찾아진 같은 이름의 함수들 ((일반적이라고 표현한 이 방법은 표준 문서에서 말하는 unqualified name lookup입니다.))



위의 규칙에 대해서는 표준 문서에 좀 더 자세히 정의되어 있으나 일단 이렇게만 알고 있어도 문제를 해결하는데 도움이 됩니다.

일단 (4)번 라인부터 살펴 보겠습니다. 먼저 (4)번 라인의 앞부분, 즉 << endl; 부분을 뺀 부분을 다시 써 보면 다음과 같습니다.


operator<<(cout, n)


여기서 cout argument는 std::ostream& 타입이므로 이에 의해 선택되는 후보는 std::operator<< 입니다. 그리고 n argument는 const formatter::bracketed& 타입이므로 (2)번 라인에 있는 formatter::operator<< 함수를 후보에 추가합니다. 마지막으로 일반적인 name lookup 방법에 의해 찾아진 후보는 global scope에 있는 (1)번 라인의 ::operator<<이 됩니다. 컴파일러는 당연히 이중 가장 잘 match되는 (2)번 라인의 formatter namespace안에 있는 함수를 선택합니다.

그럼 위에서 선택된 (2)번에서 호출되는 (3)번 라인으로 가보겠습니다. 이 라인에서 필요한 부분은 다음과 같습니다.


operator<<(cout, v.value)


(4)번 라인에서와 같이 먼저 cout에 의해 std namespace안에 있는 operator<<가 후보에 추가됩니다. 하지만 v.value는 int 즉 primitive type이므로 후보를 추가하지 않습니다. 마지막으로 일반적인 name lookup 방법에 의해 찾아지는 후보는 (2)번 라인 그 자체가 됩니다. 왜냐하면 일반적인 name lookup은 좀 더 작은 scope에서 찾아보고 발견되지 않으면 좀 더 큰 scope에서 찾아보는 방법인데 이 경우 자신이 존재하는 가장 작은 scope인 formatter namespace scope안에서 그 자신이 같은 이름으로 발견되기 때문에 더 이상 상위 scope를 찾지 않기 때문입니다. 이 경우 컴파일러는 ambiguity 없이 std 안의 operator<<을 선택하게 되며 따라서 정상적으로 컴파일됩니다.

그럼 이제 문제가 되는 (5)번 라인을 살펴보겠습니다. 먼저 (5)번 라인은 (4)번 라인과 같은 규칙에 의해 formatter namespace안의 operator<< 함수가 선택됩니다. 다음으로 (3)번 라인에서 필요한 부분은 다음과 같습니다.


operator<<(cout, v.value)


여기서 먼저 cout에 의해 std::operator<<이 선택됩니다. 두번째로 v.value는 const std::vector& 타입으로 먼저 std::operator<<이 선택됩니다. 하지만 이것은 이미 선택되었죠. 다음으로 template argument인 int는 primitive 타입이므로 더이상 후보를 추가하지 않습니다. 다음으로 일반적인 name lookup 방법에 의해 다시 (2)번 라인 자신을 추가합니다. 하지만 이 경우에는 두 후보, 즉 std::operator<< 와 formatter::operator<< 함수 모두 vector를 처리할 수 없으므로 컴파일 에러가 발생하게 됩니다.

그렇다면 어떻게 컴파일 에러 문제를 해결할 수 있을까요?

위에서 알아본대로 이 경우 ADL에 함수가 선택되는 scope는 std 아니면 formatter가 됩니다. 따라서 global scope에 있는 함수를 std 혹은 formatter scope안으로 옮겨주면 됩니다. 이때 std 안으로 옮기는 것은 표준에 따르면 undefined behavior가 됩니다. 따라서 알아서들 사용하시길... 대개 문제는 없습니다. ;-)

만약 std와 formatter namespace 둘 다에 (1)번 라인과 같은 operator<<가 존재한다면 어떻게 될까요? 이 경우에는 컴파일러가 둘 중에 더 나은 것을 선택할 수 없으므로 ambiguity 에러가 발생하게 됩니다.

Comments

Popular posts from this blog

1의 개수 세기 - 해답

벌써 어제 말한 내일이 되었는데 답을 주신 분이 아무도 없어서 좀 뻘쭘하네요. :-P 그리고 어제 문제에 O(1)이라고 적었는데 엄밀히 얘기하자면 O(log 10 n)이라고 적었어야 했네요. 죄송합니다. ... 문제를 잠시 생각해보면 1~n까지의 수들 중 1의 개수를 얻기 위해서는 해당 숫자 n의 각 자리의 1의 개수가 모두 몇개나 될지를 구해서 더하면 된다는 사실을 알 수 있습니다. 예를 들어 13이라는 수를 생각해 보면 1~13까지의 수에서 1의 자리에는 1이 모두 몇개나 되는지와 10의 자리에는 모두 몇개나 되는지를 구해 이 값을 더하면 됩니다. 먼저 1의 자리를 생각해 보면 1, 11의 두 개가 있으며 10의 자리의 경우, 10, 11, 12, 13의 네 개가 있습니다. 따라서 2+4=6이라는 값을 구할 수 있습니다. 이번엔 234라는 수에서 10의 자리를 예로 들어 살펴 보겠습니다. 1~234라는 수들 중 10의 자리에 1이 들어가는 수는 10, 11, ..., 19, 110, 111, ... 119, 210, 211, ..., 219들로 모두 30개가 있음을 알 수 있습니다. 이 규칙들을 보면 해당 자리수의 1의 개수를 구하는 공식을 만들 수 있습니다. 234의 10의 자리에 해당하는 1의 개수는 ((234/100)+1)*10이 됩니다. 여기서 +1은 해당 자리수의 수가 0이 아닌 경우에만 더해집니다. 예를 들어 204라면 ((204/100)+0)*10으로 30개가 아닌 20개가 됩니다. 이런 방식으로 234의 각 자리수의 1의 개수를 구하면 1의 자리에 해당하는 1의 개수는 ((234/10)+1)*1=24개가 되고 100의 자리에 해당하는 개수는 ((234/1000)+1)*100=100이 됩니다. 이들 세 수를 모두 합하면 24+30+100=154개가 됩니다. 한가지 추가로 생각해야 할 점은 제일 큰 자리의 수가 1인 경우 위의 공식이 아닌 다른 공식이 필요하다는 점입니다. 예를 들어 123에서 100의 자리에 해당하는 1의 개수는 ((123/1...

CodeHighlighter plugin test page.

This post is for testing CodeHighlighter plugin which uses GeSHi as a fontifier engine. ((Those code blocks are acquired from Google Code Search .)) ((For more supported languages, go CodeHighlighter plugin or GeSHi homepage.)) C++ (<pre lang="cpp" lineno="1">) class nsScannerBufferList { public: /** * Buffer objects are directly followed by a data segment. The start * of the data segment is determined by increment the |this| pointer * by 1 unit. */ class Buffer : public PRCList { public: Buffer() { ++index_; } PHP (<pre lang="php" lineno="4">) for ($i = 0; $i $value = ord( $utf8_string[ $i ] ); if ( $value < 128 ) { // ASCII $unicode .= chr($value); } else { if ( count( $values ) == 0 ) { $num_octets = ( $value } $values[] = $value; Lisp (<pre lang="lisp">) ;;; Assignment (define-caller-pattern setq ((:star var fo...

Coverity Prevent - 소스 코드 검사 도구

이번에 회사에서 소스 코드 검사 도구를 하나 구입하는데 이것저것 비교해본 결과 Coverity Prevent 라는 툴이 가장 좋아 이걸로 결정했다고 하더군요. 간단히 말하자면 Lint 처럼 소스 코드에 대해 static analysis를 하는 도구입니다. 그래서 시험삼아 돌려본 결과를 보게 되었는데 그 품질이 정말 놀랍군요. 메모리 릭이나 초기화하지 않은 변수, 버퍼 오버런, null 체크등등 거의 정확하게 에러를 보고해 줍니다. 다음은 전체 코드에서 발견된 문제점들을 리스트 형태로 보여주는 화면입니다. 정말 많군요. ;-) 다음은 이중 하나의 에러를 자세히 보기 위해 선택하여 들어간 화면입니다. 소스 코드에 라인번호와 에러가 발생한 위치, 에러가 발생할 수 있는 조건들을 자세히 보여줍니다. 정말 '와우!'입니다. 각 함수와 같은 이름들을 클릭하면 그 함수로 바로 이동할 수 있습니다. 사용해보니 개인적으로는 purify 같은 runtime 검사 도구보다 더 맘에 드는군요. 사실 Lint 계열의 도구들은 한번도 사용해본 적이 없는데 다른 것들도 한번 구해다 써봐야겠습니다. 이 툴의 유일한 문제는 비싸다는 것이랍니다. :-)