원 글은 http://www.devx.com/cplus/Article/42448/0/page/1  에 있습니다.

제가 위의 영문 글을 번역하는 것은 아니고(영어가 한참 떨어집니다.-_-) 일본어로 번역된 것이 있어서 이것을 제가 다시 한국어로 번역하는 것입니다. 그래서 번역 질이 많이 떨어질테니 제 번역 글이 이상하면 바로 원문을 보세요^^;

내용이 꽤 길어서 한번에 다 못하고 조금씩 할 때마다 올리겠습니다.




Page 1: Concepts: Disappointment Without Defeat

Danny Kalev

 이번 concept의 실패에 대해 어떻게 받아 들입니까? 이번 사건을 어떻게 생각합니까? 이것은 혹 장래적으로 신기능을 제안하는 방해가 된다고 생각합니까?

 

Bjarne Stroustrup

 C++0x에 concept을 넣지 않으면 결정했던 것에 대해서 말인가요?  나로서는 concept이  실패했다고는 생각하지 않아요. 이번 문제는개인적으로는 usability의 문제라고 생각하는데  몇 주만 있으면 수정할 수 있었다고 생각하고 있다. 뭐 위원회는 그만큼 빨리 해결할 수 없다고 생각하고 있던 것 같아요. 모두 concept의 아이디어 자체는 마음에 든다고 하더군요. 한 번 드래프트로부터 떼어지면 한번 더 들어갈 수 있으려면 또 긴 시간이 걸린다고 그토록 말해 두었지만.「실패」와「몇 백만명의 프로그래머가 사용하는데 충분한 규격은 아니었다」라고 하는 것은 크게 차이가 난다고 말할 수 있어요.

 작은 돌을 마을의 여기로부터 저쪽에 이동시키는 것은 모래를 움직이는 것과 같을 정도로 문제없겠지요. 그러나 작은 돌이 어디에 이동하든지 아무도 신경 쓰지 않는다든가(구두 안에 있는 경우는 다르겠지만) 모래를 움직이는 것이 때로는 매우 중요한 경우도 있어요. 결국은 현실에 넓게 사용되고 있는 C++를 변경하는 것은 어렵지만 몇 백만명의 프로그래머가 혜택을 받을지도 모르는 것이에요. 이것이야말로 네가 대단한  반발도 많기는 하지만  C++를 개량하려고 하고 있는 이유에요.

이번 일을 어떻게 생각할까? 유감이다. 하지만 움츠리지는 않아 더 심하게 되어 버렸을지도 모르는이니까. 예를 들면 문제가 있는 「concept」를 규격에 넣어 버렸을지도 모르지 않아?

 

 

Danny Kalev

 컨셉의 규격 제정에는 7년이나 걸리고 있지요. 그렇지만 STL의 개발은 그 반정도의 기간이었어요. 어째서 concept은 이 정도 어려웠습니까?

 

Bjarne Stroustrup

나는 concept은 2002년부터 시작 되었다고 생각하고 있어요. 내가 최초의 설계 페이퍼를 발표한 것은 2003년이다. Alex Stepanov가 완전한 STL의 구현을 Andrew Koenig와  내게 보인 것은 1994년이었다. 하지만 2002년부터 2009년과 1994년부터 1998년은 비교할 방법이 없어요. Alex는 적어도1976년 부터 STL을 개발하고 있었으니까.

그러나 당신의 질문에 답해 보면 Concept의 규격을 설계하는 것은 어렵다라고 하는 것도 C++의 형태 시스템 그 자체이기 때문이다. concept의 규격을 올바르게 설계한다는 것은 C++ 규격을 보다 명확하게 하는 것이다. C++ 표준 라이브러리의 규정도 보다 자세하게 쓰지 않으면 되지 않아요. concept의 규격을 올바르게 설계한다는 것은 C++ 규격  불명확한 부분을 정리하는 것이다. 또 concept의 규격을 올바르게 설계하고 있으면

  1. 컴파일 시간이 극단적으로 증가하지 않아요 
  2. 실행 시  퍼포먼스가 내려가지도 않아요 
  3. 제네릭 프로그래밍을 제한할 것도 없어요.

 

내가 프랑크푸르트 앞의 페이퍼(역주:N2906:Simplifying the use of concepts인가)에서 걱정한 것은 마지막 항목이다. 모두 처음만을 신경쓰고 있다. 

생각컨대 모두 concept이 무엇을 하는 것으로 어떻게 있어야할 것인가에 대해 제대로 알고 있지 않는 것  같다. 예로 나타내 보이면 Concept이  있으면 차이가  분명하게 다른 sort()를 4 종류 쓸 수 있다.

template<Container C>
  void sort(C& c); 
template<Container C, Comparator Cmp>
  void sort(C& c, Cmp cmp);
template<RandomAccessIterator Iter> 
  void sort(Iter p, Iter q); 
template<RandomAccessIterator Iter, Comparator Cmp>
  void sort(Iter p, Iter q, Cmp cmp);

 

대부분의 사람은 차이를 간단하게 알 것이다. 그리고 왜 C++98에서  규정하지 않았던 것일까라고 생각할 것이다. sort()는 한 쌍의의 랜덤 억세스 이터레이터와 혹은 비교 함수도 인수로 취한다. 대체로 모두 더 간단한 sort()에 컨테이너를 통째로 건네주기를 바란다. 이 예에서는 Concept을  사용하여 템플릿 인수에 무엇이 필요한가를 명시하는 것에 의해서 무엇을 말하고 싶은가를 표현하고 있는 것이다. 그 결과 overload 할 수 있거나 템플릿 인수가 잘못 되어 있었을 경우에는 곧바로 에러 메세지를 얻을 수 있다는 것이다. 예를 들어 sort(lst.begin(),lst.end()) 라고 써 두고 lst가 실은 list였던 경우 C++98의 에러 메세지는 뒤 늦어 링크 때가 되어 대체로  이유를 모르는 것이 된다. Concept가 있으면 곧바로 에러를 낼 수 있고 게다가 정확하다. 그래그래 형태 체크와 overload에 필요한 것은 선언 뿐이다. 보통 함수와 같이 정의함수 본체)는 어디에라도 쓸 수 있다는 것이다.

 

왜 이 구현이 어려운 것인가. 이 예는 간단하게 설명 구현을 할 수 있지만 템플릿을 쓸 때 매우 미묘한 형태의 상세에 의존하고 있다. 예를 들면 템플릿 인수의 형태는 trivial 소멸자가 없으면 안된다든가 템플릿 인수의 형태는 move-constructible가 아니면 되지 않는다든가 템플릿 인수의 형태는 union이 아니면 되지 않으면 안된다든가. 왜냐하면 그 코드에 대해서 그런 것이 매우 중요하기 때문이다. 나의 경험으로는 누구에게도 중요하지 않은 C++의 형태 시스템이라고 하는 것은 존재 하지 않는다. 어느 곳에서든지 이용되는 모든 가능성을 concept으로  망라하는 것은 매우 노력이 걸린다. 그리고 완벽하게 concept으로 망라 하지 못하면 문제가 된다.







by 흥배 2009.09.03 00:30