이 글에 이은 글입니다. 너무 미루다가 이제서야 그 다음을 번역해서 올립니다.
양이 많아서 이번이 끝이 아닙니다. 계속해서 올리겠습니다. ^^



Concept의 이점은 템플릿 유저(역주:템플릿 코드를 쓰는 프로그래머라고 하는 의미는 아니고、타인이 미리 만든 템플릿 코드인 라이브러리를 단지 사용하는 유저로서의 프로그래머)만의 것은 아니다. 템플릿으로 구현하는 사람(역주:유저가 사용하는 템플릿 라이브러리를 만드는 진짜 프로그래머)에 있어서도 중요하다.

아래를 생각해봐요


template<ForwardIterator Iter, class V>

  requires Comparable<Iter::value_type, V>

Iter find(Iter first, Iter last, V x)

{

  while (first!=last && *first!=x) first = first+1;

  return first;

}

 

이것은 일견 올바른 듯이 보이죠. 실제 표준 라이브러리의 find()는 한 쌍의 forward iterator를 받아서 값은 이터레이터의 value_type과 비교 가능하지 않으면 안되요. 이것은 Concept을 이용하여 표준 라이브러리의 규정을 간결하게 표현하고 있어요. 그러나 이 코드의 실수는 forward iterator+연산자를 제공하고 있지 않다고 하는 곳에 있어요.  ++ 연산자 뿐이죠. 컴파일러는 위 코드의 first = first+1 부분이 잘못되어 있는 것을 정확하게 지적할 수 있어요.  C++98만으로는 이 에러를 찾아내려면 테스트나 머리 좋은 프로그래머가 필요하게 됩니다.

이것에 대해서는 나쁘다고 생각하지 않을 것이에요. 무엇보다 이번 논점은 더 복잡하고 미묘한 부분에 관한 것이지만

「에러 메세지의 좋음과 좋지 않음은 아무래도 좋다」라고 하는 사람도 있을지도 모릅니다. 뭐 꼭 변명은 아니지만 이것은 concept의 그저 하나의 이점에 지나지 않습니다. 더 중요한 이점이란 프로그래밍 스타일과 코드 품질이다. 함수 인수의 선언이나 인수의 형태 체크가 없던 C++ 이전의 C 시대를 상상할 수 있을 겁니다. 당시는 적지 않은 수의 사람이


double sqrt(double); // 모던한 함수 선언


위를 아래와 같은 익숙해진 놈에 비해 너무 장황하게 빠뜨리고 있었죠.


double sqrt();// 함수 프로토타입이 없었던 시대의 C의 함수 선언


컴파일 시간의 증가를 걱정하고 있던 사람도 있었죠. 실행 시의 오버헤드를 걱정하고 있던 사람도 있었습니다. 그래 정말로 손상됩니다. 어쨌든 int로부터 double로의 예기치 않은 형태 변환이 발생할지도 모르니까요. 너무 어렵다는 것을 걱정하고 있던 사람도 있었어요. 「과연 아마추어 프로그래머에게 함수 선언과 같은 기능을 잘 다룰 수 있을까?」라고. 호환성도 걱정되고 있었어요. 「컴파일 시 및 링크 때에 낡은 코드와 어떻게 정합성을 취하면 좋은 것인가?」. 이제 와서 어떤 시대에 뒤떨어진 C 프로그래머라도 「당시는 함수 선언조차 없었는데 도대체 어떻게 해서 해 나갈 수 있었을까요? 」라고 의심하는 정도다.

 

 

Danny Kalev

그러면 결론으로서 concept이 버려진 것은 결국 한 번에 많은 것을 너무 수정하거나 혹은 C++를 새로운 언어로 지으려고 했다고 일입니까? 대체로 C++template에 너무 빠져들어 있어서 조금 문제 있어요. 프로그래머가 읽고 쓰기 하는 코드와 컴파일러가 템플릿의 인스턴스화 시에 생성하는 실제 눈에 보이지 않는 코드란 전혀 별개죠. 말해 보면 C++은 현상 유지하는 것이 좋지 않을까요. template은 너무 제한 하지만.


Bjarne Stroustrup

아니 나는 Concept이 버려졌다고는 생각하지 않아요. 원래 난는 Concept이 많은 것을 수정한다던가 C++를 전혀 다른 새로운 언어로 바꾸는 것이라고는 생각하고 있지 않아요. Concept은 어떤 하나의 목적을 위해 도입되었던 것이에요. 제네릭 프로그래밍이라고 하는 템플릿의 고도의 사용법을 직접 언어 측에서 지원하기 위해서이죠. 현재 상태로서는 코멘트와 사양서 라고 문서 안에서 기술하고 있는 것을 직접 표현할 수 있도록 하기 위해서요. 잘 디자인 된 템플릿 코드라고 하는 것은 인수의 형태에 어떠한 조작을 하는지를 제대로 생각하고 쓰여져 있어요. 좋은 코드라고 하는 것은 그러한 필요 조건이라고 하는 생각이 문서화 되고 있는 것이에요. 표준 규격의 requirements table 같은 것이라고 생각해 준다면 좋아요. 즉 현재는 대부분의 템플릿 코드는 암묵 중에 Concept이라고 하는 생각을 사용하고 있어요.


왜 언어로 직접 concept이라고 하는 생각을 지원 할 필요가 있는가 하면 암묵적인 생각만으로는 충분하지 않기 때문이에요. 컴파일러는 주석이나 사양서나 표준 규격서나 프로그래머(당연히 나도 포함한다)의 머리 속 사양을 읽어 주거나 하지 않아요. 즉 언어로서의 명시적인 concept의 지원이 없다고 하는 것은 버그나 알기 힘든 에러 메세지의 원인이에요. 템플릿 선언에 있어서 Concept과 함수 선언의 인수(함수 프로토타입)이란 모두가 생각하는 이상으로 잘 비슷하다고 생각해요.


나는 템플릿을 「조금 문제 있다」라고 생각하고 있지 않아요. 우선 이것은 매크로는 아니에요. 컴파일러가 템플릿 코드를 변환하여 실행 코드를 생성한다는 것은 비 템플릿 코드를 치환하는 만큼 걱정하는 것은 아니에요. 이것을 걱정하거나 템플릿을 매크로라고 생각하는 사람이 있다는 것은 템플릿 인수의 필요 조건이 암묵적이기 때문이에요. 호출한 시점에서 체크되지 않는 것이죠. 그러한 「변환」을 걱정한다는 것은 너무 신경질적이다. 반대로 아무것도 걱정하지 않는다면 함수 프로토타입을 사용하지 않고 C로 쓰면 되요.


by 흥배 2009.10.22 23:30