Danny Kalev

Concept이 워킹 드래프트에 들어가고 나서 수 개월 후인 20003월에 Howard Hinnant가 묻었어요. 「아마추어 프로그래머에게까지 Concept을 강요하는 리스크는 어때요? 이점은 있는 것인가요?」라고. 규격의 설계 단계에서 이런 의견이 나오지 않았다는 것은 놀랐습니다.  위원회에는 더 체크나 밸런스가 필요한 것이 아닙니까? 특히 Concept 같은 큰 신기능에 대해서는.


Bjarne stroustrup

위원회는 완벽하지 않아요. 어떤 단체도 그렇죠. 하지만 당신이 생각하고 있는 것보다는 좋아요. 멤버 여러 명은 그러한 질문을 채택하여 위원회를 제멋대로라던가 사악하다고 말하겠지만요.

리스크를 걱정하거나 리스크와 이점을 고려한 것은 아무것도 Howard시작해라고 하는 것은 아니에요.  Concept에 종사해 온 모든 사람이 첫 번째부터 생각하고 있던 일이에요. 원래 나는 템플릿 규격의 설계의 첫 날부터 템플릿 인수의 체크 이점과 결점에 대해서 생각하고 있었어요. 1986년부터 생각하고 있었던 것이에요. D&E를 읽어보세요. 지금 Concept이 없는 이유라고 하는 것은 1988년 당시는 유연성과 범용성, 퍼포먼스, 뛰어난 조기 체크를 실현하려면 어떻게 하면 좋을지 몰랐어요. 내가 아는 한 당시는 아무도 몰랐어요. 결국 나는 후기 체크와 심한 에러 메세지를 희생하여 유연성과 범용성과 퍼포먼스를 중시했던 했어요. 2006년에는 난는 문제 해결 방법을 알고 있었어요. 이 차이는 크죠. 2009년의 문제는 일부의 무리가 오랜 세월의 연구와 구현과 라이브러리 설계의 경험을 가지고 있어도 아직 「충분하지 않다」라고 생각하고 있던 것이에요. Concept의 일부는 아직 표준에 들어가기까지 개량이 필요하다라고 말하는 것이죠. 특히 나로서는 Concept의 이용 경험으로부터 얻을 수 있던 결과가 충분히 Concept의 규격 설계에 반영되어 있지 않다고 생각해요.

Howard가 리스크와 이점에 대해 질문했는지 나는 잘 기억하고 있지 않아요. 그러한 질문을 한 사람이 있던 것은 확실하지만 실제 질문은 이용에 관한 것이었어요. 나의 "simplifying the use of concepts" 문서에 의하면

그 스레는 Howard Hinnant이 라이브러리의 설계 방침에 대해 두 가지 방법이 있는 것에 대하여 질문한 것으로부터 시작되었죠. 하나는 전문가도 아닌 많은 아마추어 유저도 Concept map을 쓸 필요가 있는 것이고 또 하나는 별로 우아하지 않지만 Concept map과 원래 concept 자체를 사용하지 않는 것으로 아마추어 유저가 concept을 이해할 필요를 없애는 것이었어요.

이미 Alisdair Meredith가 비슷한 질문을 하고 있었죠. auto concept의 사용은 레거시 코드에만 추천 되어야 할 것일까?

내가 그 때도 지금 현재도 걱정하고 있는 일은 usability이에요.

위원회는 ISO의 룰에 따라서 운영되고 있죠. 딱딱하고 보수적이에요. 완전하게 공평하죠. 누구라도 경험, 교양, 상업 목적의 여하를 불문하고 참가 할 수 있고 나라 단위로의 공평한 투표가 실시되죠. C++ 위원회의 문서는 Web 상에서 공개되고 있어요. C++ 위원회는 파이오니아에요. 또한 국제 표준 위원회와 개개의 멤버들은 항상 C++ 개발자와 관련되려고 노력하고 있어요. 나의 출판물이나 인터뷰, 발언록은 그 것의 아주 일부에 지나지 않아요.

온 세상에서 사용되고 있는 언어를 대폭 바꾸는 것은 매우 어려운 일이에요. 그것은 어느 의미로 좋은 일로 다른 독자(원어:proprietary) 언어와 비교해서 C++의 최대의 이점이란 변화하기 어렵다고 하는 것이죠. 나는 더 이상 「체크나 밸런스」가 필요하다고는 생각하지 않아요. 강하게 말하면 장기적인 물건의 견해에 너무 붙잡혀 있다는 것 정도일까요.





나머지는 다음에...^^



Bjarne Stroustrup Concept와 미래를 말하다 - 1 
Bjarne Stroustrup Concept와 미래를 말하다 - 2


출처 : http://cpplover.blogspot.com/2009/08/bjarne-stroustrupconcept_14.html

원문http://www.devx.com/cplus/Article/42448/0/page/1



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



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
10월 7일 KGC 2009에서 오후 4시30분에 했던 강연의 자료입니다.

KGC 참석자에게 배포된 CD에 있는 것과 제가 강연한 것과 문서가 같지 않기 때문에 올립니다.

저는 강연 문서를 만들 때 청중을 따분하지 않게 하기 위해 글을 문서에 많이 넣지 않고 현장에서
제 말로 전달하기 때문에 아마 이 문서만으로 보면 저의 강연을 제대로 알기 힘든 점이 있을 것입니다.

질문이 있으면 덧글 달아주세요.^^

ps : 이 날 시간이 부족해서 후반 부의 parallel에 대해서는 거의 스킵을 했는데 이 부분은 다음에 강연을 하게 될 때 꼭 하겠습니다. 그리고 부족하나마 마지막 참고자료에 있는 VSTS 2010 팀스터디 블로그에 가면 관련 글이 있습니다.





by 흥배 2009.10.11 14:12

원 글은 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


프랑크푸르트까지


샌프란시스코 회의로부터 6,7개월 동안 표준 규격과 표준 라이브러리의 문면에 여러가지 개량이 더해져 갔다. 프랑크푸르트 회의가 가까워짐에 따라 두 개의 문제가 부상했다. 구현 경험에 대한 우려와 통합된 concept 규격에 대한 사상의 어긋남이다.


구현 경험의 우려라고 하는 것은 ConceptGCC의 불완전함이다. 예를 들면 컴파일의 퍼포먼스가 낮은 것이나 고도의 기능이 부족한 것(scoped concept mapassociated template다.

위원회의 위원들은 concept 베이스의 표준 라이브러리를 평가하는데 제품 레벨의 품질을 가지는 구현이 없는 현재 상태로서는 언어와 라이브러리의 concept 규격에는 아직도 많은 결함이 남아 있을 것을 우려했다. 이러한 결함은 C++0x 규격의 발행을 더욱 늦추고, 최악의 경우 결함 투성이의 규격을 내게 된다.


동시에 concept에 관한 다수의 최고조에 달한 논의가 위원회의 메일링 리스트에서 이루어지고 있었다. 대부분 현행 규격의 사용하기 어려움의 문제이다.

예를 들면 경우에 따라서는 라이브러리의 constrained template의 요구를 채우기 위해서 유저는 빈 concept map을 쓰지 않으면 안 된다. 유저는 그러한 concept map을 문법 상의 쓰레기라고 간과할 것이다.


논의는 Bjarne Stroustrup의 페이퍼 Simplifying the use of concepts에 집약되었다. 이러한 설계에 대한 불안은 인디애나와 텍사스의 사상이 지금과 얼마나 큰 격차였는지를 이야기하고 있다. 끝으로 Stroustrup 박사의 페이퍼는 소위 명시적인 concept을 삭감하려고까지 제안하고 있었다. 이것은 2005년부터의 concept의 근본적인 문제이며 원래 처음부터의 문제였다.




프랑크푸르트에서의 투표


C++ 위원회는 프랑크푸르트 회의의 처음부터 대략 반나절에 걸쳐 concept의 경우에 도착해 논의했다. Stroustrup 박사는 다음의 세 개의 선택에 대해 투표를 시켰다.

1.    C++0x의 현행 규격의 Concept을  유지한다.

2.    ”Simplifying the use of concepts”의 제안을 받아 들여 C++0xconcept을 존속시킨다.

3.    C++0x로부터 concept을 삭제한다.


녹초가 된 위원회의 위원들과 함께 나는 concept 삭제에 투표했다. 왜냐하면 언어의 미래를 생각했을 때 C++0xconcept에 있어서 최선의 선택은 삭제하는 것다라고 생각했기 때문이다.


개인적으로는 현행 규격을 통과해야 한다고 생각한다. 이것이 근본적으로 올바른 설계라고 믿고 있다. 그렇지만 현시점에 있어서 합의를 얻지 못하고 있는 것은 분명하다. 넓은 C++ 업계에 받아 들여지기 이전에 우리 중에서도 합의에 이르지 않으면 안 된다.

구현 경험에 관한 우려는 당연한 일이다. 이런 이유로 C++0x에서 concept을 삭제하기에 충분하다.


두 번째 선택인 설계의 대폭적인 변경을 더해 C++0xconcept과 함께 발행하는 것은 도저히 지지할 수 없다.  큰 변경을 하는 것은 지극히 위험하다. 이 경우 구현 경험이 없는 것, 사용 경험이 없는 것, 신 설계가 움직일지를 검증하기 위한 기술력이 부족하다.

ConceptGCC에서 조차 충분한 구현 경험은 아니라고 생각하는 사람이 있다. 변경한 설계의 착실한 구현 등 우선 나올 것은 없다. 원래 이 문제에 관한 사상의 상위의 경위를 생각하면 우리가 제안된 변경에 합의할 수 있을 리가 없다.


다른 선택 사항도 있었다. 예를 들면 C++0x를 한층 더 수년 늦추어 합의를 얻는다는 것이다. 그러나 그런 연기는 받아 들여질 리가 없다. conceptC++0x로부터 삭제하는 것이 무엇 보다 나은 선택 사항이었던 것이다. 한편 위원회는 concept에 찬성이며 장래 착실한 제안을 하면 또 논의할 것이다. 다음의 기사에서는 이 실패로부터 배운 것과 장래의 방법에 대해 말하려고 한다.

 

 

출처 : http://cpplover.blogspot.com/2009/08/douglas-gregor.html






by 흥배 2009.08.12 18:30

7월에 프랑크푸르트에서 열렸던 C++0x 표준 위원회 모임에 대한 이야기가 올라온 글이 있어서 번역했습니다.

( 글의 전체적인 내용은 Concept 시작과 끝에 대하여 이야기 하고 있습니다 )

 

 

 

What Happened in Frankfurt? « C++Next


프랑크푸르트에서 무엇이 있었는가?

C++0x의 발전에 흥미가 있는 사람은 이미 뉴스를 들었을 것이라고 생각한다.  ISO C++ 위원회는 20097월 프랑크푸르트 회의에서 C++0x의 드래프트로부터 Concept을 제외하는 것을 투표로 결정했다. ConceptC++0x의 중요한 기능으로 삭제는 꽤 쇼크를 준 것일 것이다.

여기서 나는 ConceptC++0x에 넣기에 즈음해서 한 노력과 결과적으로 실패한 이유를 말하려고 한다.

 

Concept의 역사

C++ 프로그래머는 항상 더 좋게 template를 사용하고 싶다고 생각하고 있었다. 계약적(원어:constraintsC++template는 적어도 Bjarne StroustrupThe Design and Evolution of C++15.4를 참조)(역주:일본 타이틀 C++의 설계와 진화)무렵부터 있었다.  Jeremy Siek Andrew Lumsdaine는 이 계약적인 체크 기능을 concept으로 확장하여 근본적으로는 template의 정의를 형태 체크하도록 행동하는 것을 나타냈다.Siek2000) 


2003Bjarne StroustrupGabriel Dos Reis는 일련의 제안서를 써서(N1510N1522N1536C++언어에 대해 concept이 어떻게 표현할 수 있는가 하는 것을 고찰했다.


본인의 concept과의 관계는 20051월부터 Concepts for C++0x를 공저 한 것으로부터 시작되었다. 이것은 인디애나 제안으로 불리고 있는 것이다. 그 바로 후에 Bjarne Stroustrup Gabriel Dos ReisA Concept Design (Rev. 1)라고 하는 제안을 저술했다. 이것은 텍사스 제안으로 불리게 되었다.


Concept이 처음 C++ 위원회에서 논의된 것은 20054월의 노르웨이에서 행해진 릴레함메르 회의부터였다. 인디애나 제안과 텍사스 제안은 분명하게 설계 사상을 달리하는 것이었다. 물론 서로의 주장은 여러 가지 있었지만 가장 근본적인 차이는  concept에 있어서 데이터로서의 형에 matching 시키는가 하는 것이었다. 텍사스 제안은 모든 것에 있어서 암묵적인(자동적인)matching(예를 들면 현행 규격의 auto concept과 같은 것)을 선호했다. 인디애나 제안은 모든 것에 있어서 명시적으로 타당성을 나타나고 있고 remapping 가능(예를 들면현행 규격의 concept map과 같은 것)인 것을 선호했다.


릴레함메르 후 나는 6개월에 걸쳐 ConceptGCC를 구현했다. 최초로 유일한 concept을 구현하고 있는 실험적인 컴파일러다. 이 컴파일러는 실제 구현을 제공하는 것을 의도하고 있었다. ConceptGCC에서의 경험은 인디애나 제안을 훌륭할만큼 개량할 있었다. 나는 200510월의  회의에서 ConceptGCC를 피로했다. 위원회의 반응은 대개 양호했다. 그러나 일부의 위원은 두 개의 제안이 현저하게 동떨어져 가는 것을 걱정했다.(역주:인디애나 제안과 텍사스 제안의)저자들은 협력하여 통합한 제안을 쓰기 시작했다. 우리는 많은 회의를 하여 세부를 밝혀내고 최종적으로 최초의 통합된 제안20066월에  발표했다. 동시에 ConceptGCC의 표준 라이브러리 개발이 진행되어 우리는 최초의 제안서인 표준 라이브러리에 있어서의ConceptN2036-N2041을 참조되었고)를 다 썼다.


우리는 위원 회외에서 몇 번이나 회의를 실시했다. 회의마다 새로운 논의와 거기에 따르는 제안서의 변경이 이루어졌다. 최대의 변경은 or constraints 삭감, scoped concept map의 도입, forwarding function 생략 이다. 또 이 시점에서 나는 최초의 드래프트인 concept 규격서에 있어서의 문면을 다 썼다. 이것은 후에 언어와 라이브러리 양쪽 모두에서 꽤 많이 개정되어 가게 되었다.


20089월 샌프란시스코 회의에서 concept은 마침내 워킹 페이퍼에 받아들여져 최초의 C++0x candidate draft (CD1)에 들어갔다. C++0x의 릴리스 후보 드래프트에 제14판으로 받아들여졌던 것이다. 이것은 코어 언어 정도 분량의 C++0x 표준 라이브러리를 차지한다



출처 : http://cpplover.blogspot.com/2009/08/douglas-gregor.html


분량이 많아서 두편으로 나누어 올립니다. 두 번째부터 본격적인 프랑크푸르트 이야기가 나옵니다.



by 흥배 2009.08.11 06:30

클로져 사용하기 2

 

<Code 4> 에서는(세 번째 글의 마지막 예제) 하나의 변수만을 캡쳐했지만 복수의 변수를 캡쳐하는 것도 가능할까요? 네 당연히 가능합니다.


‘[]’ 사이에 캡쳐할 변수를 선언하면 됩니다.

[ &Numb1, &Numb2 ]

 

그럼 ‘[&]’로 하면 어떻게 될까요? 이렇게 하면 람다 식을 정의한 범위 내에 있는 모든 변수를 캡쳐할 수 있습니다.


............ 나머지 글은 여기에서 보세요^^;





by 흥배 2009.06.24 01:09

클로져 사용하기 1

 

그럼 이제 클러져에 대해서 알아 보겠습니다.

람다를 사용할 때 람다 식 외부에 정의되어 있는 변수를 람다 식 내에서 사용한 후 결과를 그 변수에 그대로 저장하고 싶을 때가 있습니다. 이럴 때 클로져를 사용하면 됩니다.

클로져는 참조나 복사로 전달이 가능합니다. 참조를 사용하는 경우는 &을 사용하면 됩니다.

람다 표현의

  

[](파라메터) { }

에서 앞의 ‘[]’ 사이에 클로져할 변수를 기술하면 됩니다.


... 나머지 글은 여기에서 봐 주세요^^

by 흥배 2009.06.17 09:00

C++에서의 람다 사용 법

 

람다 사용 방법은 아래와 같습니다.

[](파라메터) { }

 

int 값에 50을 더한 후 반환하는 람다 함수 

[](int x) { return x + 50; }

 

위 방법은 반환 값의 type“x+ 50”의 값의 type으로 추정되어 반환됩니다.

만약 반환 값 type을 지정하고 싶다면

 

[](int x) -> int { return x + 50; }

라고 하면 됩니다. 그리고 참고로 반환하지 않을 것이면 반환하지 않아도 됩니다.

또한 클로져를 사용하면 “[]” 사이에 참조를 넘길 수도 있습니다.

 

그럼 람다 사용 방법을 좀 더 알기 쉽도록 여러 가지 사용 예를 보여 드리겠습니다.



....... 나머지는 여기서 봐 주세요 ^^;

by 흥배 2009.06.10 00:13

RValue Reference에 관한 글의 마지막으로 Perfect Forwarding에 대해서 설명합니다.

 

 

인수 전달 문제

 

< Code 1. >

void inner(int& i)

{

}

 

template <typename T> void outer(T& t) {

           inner(t);

}

 

 

int main()

{

           int a = 5;

           outer(a);

 

           outer(6);

           return 0;

}


<Code 1>을 컴파일 하면 outer(6)에서 컴파일 에러가 발생합니다.

error C2664: 'outer' : cannot convert parameter 1 from 'int' to 'int &'라는 에러 결과가 출력됩니다. <Code 1>을 컴파일 하기 위해서 파라메터에 const를 포함하는 함수를 재정의 해야 합니다.

 

...........나머지 글은 여기에서 봐 주세요^^;

by 흥배 2009.05.27 01:15
| 1 2 3 4 |