Danny Kalev

장래에 대해서는 어떻게 생각합니까? 지금부터 어떻게 됩니까? Technical Report 같은 느낌으로Concept를 나중에 추가하는 것입니까? 혹은 완전 초보나 아직도 깨달음을 얻지 않은 우둔한 코더라도 사용할 수 있는 완전히 새로운 규격을 넣는 날이 오는 것입니까? concept의 폐지는 현행 드래프트에 한층 더 큰 영향을 주는 것입니까?

 

Bjarne stroustrup

어휴, 편견이 심한 유도 심문 같은 질문이네요

 

가장 먼저 C++0x는 이미 합의된 개량을 모두 도입하여 제정되었어요. 예를 들어 concurrency의 지원, 표준 라이브러리의 개량과 확장, 통일적인 초기화, lambda, move semantics, 범용적인 정수 표현 등등. 제가 썼던 C++0x FAQ를 읽어보세요. 이미 이 단계에서는 대규모 변경은 들어가지 않아요. C++0x에는 중요한 개량이 많이 있어요. 몇 개인가는 이미 GCCMicrosoft 등이 구현하고 있어요. 새로운 언어와 같다고 느낄 것이에요.

 

2번째로 C++은 모든 유행을 쫓는 일은 하지 않아요. 실용을 위해 천천히 호환성을 생각하면서 진화해 나가요. 최첨단 기능이 가득한 언어라든지 극단적으로 작은 언어라든지 독자 기능이 가득한 언어라고 하는 오징어 한 언어를 갖고 싶다면 그 외에 얼마든지 있을 것이요. 다만 만약 이 앞 몇 십년 이라도 사용하는 프로그램을 위해 충분히 유연하고 보다 성능이 좋은 그 외 예를 볼 수 없을 정도 범용적이고 어떤 하드웨어에도 움직이는 언어를 갖고 싶으면 C++로 하세요.

 

3번째로 많은 사람이 어떠한 방법으로 C++에 있어서의 Concept의 좋은 점과 올바른 이용 방법을 찾아낼 것이에요. 「나중에 추가」하는 것은 아무도 생각하고 있지 않아요. C++의 표준화는 그처럼 되지 않아요. 프랑크푸르트 이전의 Concept 규격에 "simplifying the use of concepts" 제안으로 개량을 더하면 개인적으로는 만족이 가는 것이 수개월에 완성될 것이에요. 하지만 그런 일은 없을거에요. concept을 기본으로부터 다시 생각히여 지금까지 얻을 수 있던 경험을 바탕으로 한다고 해도 거의 스크래치로부터 규격을 고쳐 써고 실험할 것이에요. 5년 단위의 시간이 걸릴 것이겠죠. 무엇보다 concept은 다른 아이디어에 이길 정도의 이점을 나타내지 않으면 되지 않아요. 만약 리플렉션이 우수하다면 대신에 그쪽에 주력 할 것이에요.

conceptTR(Technical Report)에 향하고 있다고는 생각되지 않아요. 형태 시스템에 깊게 관련되고 있기 때문에 TR라고 하는 것은 그것 없이도 해 나갈 수 있는 만큼 분리할 수 있는 것에 대해서 실시해요. 형태 시스템은 완전하게 완수할지 아무것도 하지 않을 지의 양자택일이에요.

 

 

 

Danny Kalev

그러면 C++에 관해서는 낙관적인 견해를 하고 있군요.

 

Bjarne stroustrup

저는 옛날도 지금도 주의 깊고 낙관적으로 생각하고 있어요. 저는 「 나의 언어, , 설계 사상을 가지고 있으면 너희들의 별볼일 없는 문제 전부 해결해 줄 수 있어! 내일이라도 세계를 정복해 주지! 후하하하하!」등의 낙관적인 견해는 있지 않아요. 저시는 C++이 「단지 단지」 몇 백 만명의 프로그래머를 지원할 수 있고 많은 환경에 소프트웨어의 개발 환경을 제공하여 고도의 어플리케이션 개발에 사용된다고 하는 것만으로 충분히 만족해요. 「소프트웨어의 환경」이라고 하는 것은 임베디드계이거나 시스템 개발이거나 자원의 제약이 어려운 환경이거나 C++에 최적인 분야의 것이에요. C++0xC++98보다 보다 좋은 툴이 될 것이에요.

 

지금으로서는 위원회는 C++0x를 아담하게 포장하고 출하하지 않으면 않되요. x16진수가 되지만. 그리고 구현이 다 모일 것이에요. 몇 개의 기능이나 라이브러리는 이미 나돌고 있어요. 거기서 프로그래머는 위원회의 다대한 작업의 혜택을 얻을 수 있다는 것이에요.

 


< 끝 >


Bjarne Stroustrup Concept와 미래를 말하다 - 1  http://jacking.tistory.com/443

Bjarne Stroustrup Concept와 미래를 말하다 - 2  http://jacking.tistory.com/467

Bjarne Stroustrup Concept와 미래를 말하다 - 3  http://jacking.tistory.com/474

Bjarne Stroustrup Concept와 미래를 말하다 – 4 http://jacking.tistory.com/559

Bjarne Stroustrup Concept와 미래를 말하다 – 5  http://jacking.tistory.com/652

Bjarne Stroustrup Concept와 미래를 말하다 – 6  http://jacking.tistory.com/678

Bjarne Stroustrup Concept와 미래를 말하다 – 7  http://jacking.tistory.com/679

Bjarne Stroustrup Concept와 미래를 말하다 – 8  http://jacking.tistory.com/686

Bjarne Stroustrup Concept와 미래를 말하다 – 9  http://jacking.tistory.com/695

 

저작자 표시
신고
by 흥배 2010.07.21 08:30

Danny Kalev

흥미롭네요. C++98template의 컴파일 방법으로서 현실적으로 사용되고 있는 inclusion 모델과 exportDouglas Gregor가 텍사스와 인디애나라고 말하는 같고, 두 개의 사상을 하나의 제안에 정리하려고 한 결과입니까? 아무래도 그런 식으로 동일 시 하는 것은 잘 되지 않을 것 같네요.

 

 

Bjarne stroustrup

그래요. export의 실패는 templateinclusion 모델) separate compilation 모델을 하나로 정리하려고 한 것입니다. 다만 당신이나 모두에게 알려 주고 싶은 것은 당시 어느 쪽의 방법도 실제로 사용되고 있었던 것입니다. 표준의 방법이 아무래도 필요했고 어느 쪽의 모델도 강하게 지지를 받고 있었습니다. 그러한 이유로 절충안은 만들기 힘들었습니다. 이쪽을 세우면 저쪽이 서지 않으니까요.


반성해 보면 양쪽 모두의 모델을 절대로 지원할 필요가 없었기 때문에 벤더는 inclusion 모델만을 구현했을 것입니다. EDGexport를 구현하고 있습니다. 하지만 모든 주요한 벤더가 다 할 때까지 는 아무리 귀찮아도 사용하고 싶어하지 않는 것 같습니다. 당시의 저는 그런 것은 고려하고 있지 않았으며 위원회가 실패했던 것도 명확한 사용 구분을 생각하지 않았던 것이라고 생각합니다. 위원회를 꾸짖기 전에 조금 더 생각해 주세요. 「지금 현재 문제가 있다」라는 거소가 「장래 문제가 될지 모른다」 어느 쪽을 선택하는가 라는 것은 개인으로서는 매우 어려운 일이에요. 머리가 좋은 사람끼리 생각해도 어렵습니다.

 

concept 제안의 근본적인 차이를 분별하는 것은 매우 어려운 일입니다. 이 문제를 깨닫고 있지 않는 사람마저 있어요. 어려운 것은 「도대체 무엇이 근본적인 차이인가?」라고 하는 것입니다. 당연 논의의 상당수는 concept map이었습니다. 이미 나타난 것처럼 concept mapmapping을 위해서 필요한 기능입니다. 그 자체가 훌륭하다고 생각하는 사람도 있었습니다. 비록 비어서 무슨 형이나 조작도 정의하지 않는다고 하더라도 말이죠. 프랑크푸르트 이전의 concept의 규격 설계에서는 빈 concept map을 요구하는 concept과(explicit concept, mapping이 필요하지 않은 한 concept map을 필요로 하지 않는 conceptautomatic concept)이 있었습니다. "simplifying the use of concepts" 페이퍼로의 논점은 concept map은 애매성의 해결에 적절하지 않다는 것입니다. 이것이 당신의 질문에 대한 답입니다. concept map의 올바른 사용법에 관한 논의의 결론은 표준화 위원회에 의한 언어 사양에 반영 되는 것이 당연하고 concept와의 순조로운 해결의 방법이 제공되어야 한다는 것입니다. 다른 안은 다른 사상의 코드를 동일시로 하는 것으로 쓰기의 좋은 것은 아니었습니다. 거기서 올바른 사용법이라고 하는 것에 관련해서 격렬한 논의가 있었습니다.

 

 

 

Danny Kalev

C++유저는 적당히 하라고 생각하고 있는 것은 아닐까요? 논의가 좋은 예인 것 같습니다. concept만이 아니었죠. 가베지컬렉션이든가 리플렉션이라든지 GUI라고 하는 매우 갖고 싶은 기능이 C++에는 절대 들어갈 것 같지 않지요. 거기에 비하면 실험적으로 난해한 기능만 논의되고 있고. 이 코멘트에 있듯이 이제 C++라는 것은 끝난 것일까요? 언어 자체가 너무 복잡하여 더 이상 온전하게 개량 할 수 없게 되고 있는 것은 아닐까요?

 

 

Bjarne stroustrup

그 「매우 갖고 싶은 기능」이라는 것들이 이론이 많은 것이 문제예요. 단지 고함치듯이 주장만 하고 온전하게 논의를 하지 못했어요. 저는 개인적으로 GC를 좋아하고 C++0x에는 GC ABI도 들어갑니다. 단지 유감스럽지만 표준 GUI 따위는 무리입니다. 왜냐하면 세상에는 독자 구현이 너무 많기 때문입니다. 많은 업계가 자신의 GUI로 둘러싸고 싶어합니다. 「실험적으로 난해」라고 하는 것은 대체로 「내가 좋아하는 다른 언어에는 없어서 나에게 있어서는 이해 불가능한 기능」을 의미하는 것은 아닐까요? 이전에는 클래스 계층과 가상 함수가 그러한 기능이었습니다.

 

C++이 끝나는 것 일은 없습니다. 그러 말은 C++의 흉내를 내고 있는 무리들이 하는 말입니다.

C++의 표준화 방법은 확실히 늦고 어렵습니다. 단지 이미 말한 것처럼 가벼운 느낌의 실험적인 방법보다는 좋아요. 다른 방법이라고 하면 상업 언어의 진화는 빠릅니다. 왜냐하면 돈도 있고 다수의 환경을 고려 하지 않아도 되고 C++ 정도의 하위 호환성을 신경 쓸 필요가 없어니까요. Visual Basic을 기억하겠죠? C++VB만큼 빨리 진화하지 않는다고 자주 말해지고 있습니다. 하지만 C++은 기존의 코드를 가능한 한 부수지 않고 진화해 왔던 것입니다. 저는 아직도 숭고한 벨 연구소 같은 연구실이 새로운 아이디어를 실험하려면 최적의 장소라고 생각합니다.

많은 현장은 아직껏 C++98 조차 따라잡고 있지 않아요. 이것은 다른 언어에 말할 수 있는 것이지만.




Bjarne Stroustrup Concept와 미래를 말하다 - 1  http://jacking.tistory.com/443

Bjarne Stroustrup Concept와 미래를 말하다 - 2  http://jacking.tistory.com/467

Bjarne Stroustrup Concept와 미래를 말하다 - 3  http://jacking.tistory.com/474

Bjarne Stroustrup Concept와 미래를 말하다 – 4 http://jacking.tistory.com/559

Bjarne Stroustrup Concept와 미래를 말하다 – 5  http://jacking.tistory.com/652

Bjarne Stroustrup Concept와 미래를 말하다 – 6  http://jacking.tistory.com/678

Bjarne Stroustrup Concept와 미래를 말하다 – 7  http://jacking.tistory.com/679

Bjarne Stroustrup Concept와 미래를 말하다 – 8  http://jacking.tistory.com/686


저작자 표시
신고
by 흥배 2010.07.19 09:00

Danny Kalev

「위원회에 의한 설계」라고 하는 접근은 실패의 원인이군요. concept이 비판 받는 것도 그 때문인 것 같군요. 예를 들면 export입니다.(나중에 알았지만 John SpicerBerlin 회의에서 비슷한 것을 말한다. 회의록은 여기. 무엇으로 위원회가 표준화 하는 것을 기존의 유효성이 보증되고 있는 것으로 한정하지 않을까요? 실제 그렇게 해서 STL이 만들어졌었죠. 그러면 C++0x도 좀 더 빨리 규격을 제정 할 수 있었지 않았을까요?

 

 

Bjarne stroustrup

1996년 시점에서 STL을 「기존의 유효성이 보증되고 있는」 물건이라고 생각하는 사람은 많이 있었다고는 생각되지 않습니다. 한층 더 라이브러리의 제안과 언어 기능의 제안은 많이 다른 것이에요. 라이브러리의 제안을 예측하는 것은 비교적 간단합니다.

프랑크푸르트 회의에서 제시가 지적한 것은

l  어느 사람은 「상용 구현이 없는 것을 표준화 하지 말아야 한다」라고 주장하고 있습니다.

l  주요한 벤더는 표준 규격 없이 구현을 하지 않습니다(상용적으로 이점이 있는 독자 기능이 아닌 한).

 

이 문제를 피하는 방법으로서는 실증을 위한 실험적인 구현을 제공하는 것입니다. 단지 이것은 논의를「충분히 완전한 구현 이라는 것은 어느 정도인가?」와 「실험적 구현의 표준 규격에 있어서의 기준도는 어느 정도 정확한가?」라고 하는 것으로 바뀔 뿐입니다.

 

Concept에서는 실험적인 구현인 ConceptGCC와 실제로 움직이는 STL이 있었습니다. 어느 사람에게 있어서는 이것으로는 충분하지 않았습니다. 단지 제가 생각컨대 많은 사람이 구현 문제에 너무 신경 쓰고 있어서 설계의 문제에는 무관심했습니다. 설계와 구현만으로는 불충분합니다. 기능을 사용한 라이브러리도 필요합니다. 그 라이브러리를 사용한 실제의 프로젝트도 필요합니다. 뭐 그렇다면 완벽하겠지만 그렇게 몇 년이나 실험만 하고 있을 틈은 없습니다. 누가 그런 실험적인 구현 후에 프로젝트나 제품을 만들까요? 만일 누군가가 했다고 해도 어떻게 그렇게 빠른 단계의 구현상의 경험을 바탕으로 미묘하게 다른 표준 규격을 제정 할 수 있다고 말할까요? 얻을 수 있는 것은 비호환 독자 기능이 증가해 가는 것 정도의 물건입니다. C++98C++0x의 사이가 긴 공백 기간이 Apple이나 Microsoft가 독자「기술」을 내고 있는 이유입니다. 단지 아무것도 그들에게 한정한 이야기는 아닙니다. 기업이라고 하는 것은 업계의 쉐어와 이익을 추구하는 것입니다. 언어 설계의 범용성을 위해 있는 것은 아닙이다.

따라서 일반적으로 새로운 아이디어를 평가하는 것은 어렵고 넓게 사용되고 있는 언어에 대하여 하는 것은 한층 더 곤란합니다. 불가능한 것이라고는 생각하지 않지만 저는 대부분은 실험적인 구현으로 충분하다고 생각합니다. 비록 완전하지 않았다고 하더라도 기능을 100% 구현하고 있지 않을지도 모르고, 다른 기능과의 균형이 충분하지 않을지도 모르고, 성능이 최적화되어 있지 않을지도 모르고, 디버그 기능이 빠져 있거나, 에러 메세지가 완전하지 않을지도 모르는 등등. 현실에서는 어느 정도의 실험이 충분할지 어떨지를 판단하지 않으면 안됩니다. 그러나 이것은 어느 기능에 필요한 것이 모두 받아 들여진다는 것은 아닙니다. 거기에 더해 필요한 것은 규격의 검증, 단순성, 완전성, 범용성, 확장성, usability, 사람에게 가르칠 수 있을지?

 

많은 설계안을 검증하지 않으면 안됩니다. 대부분의 경우 그저 몇 안 되는 규격 설계의 차이가 일반 프로그래머에게 있어서의 편리한 사용을 아득하게 바꿉니다. 구현 중시로 놓치는 것이 많은 것은 여기입니다. 저시는 「전형적인 이용 예」와 「중요한 이용 예」를 모아서 많은 설계를 시험하고 있습니다. WG21 사이트에 있는 initializer listinitialization에 관한 많은 페이퍼가 이 어프로치를 실천하고 있습니다. 한층 더 저는 튜토리얼 쓰기, 학생에게 복수의 설계안을 시험하게 하는 것을 하고 있습니다. 물론 다른 언어 기능과의 균형이나 장래의 확장을 검증하는 것도 필요합니다.

 

더 재 빠르게 라고 단순하게 「위원회에 의한 설계」이외 방법으로 게다가 금전적 원조가 필요 없고, 기업의 영향도 받지 않는 듯한 규격 설계 방법이 있다고 생각하는 것은 실수입니다. WG21에서는 「위원회에 의한 설계」를 가능한 한 없애려고 하고 있습니다. 대부분의 설계는 개개인이 하고 모두의 앞에 가지고 와서 개량해 나갑니다. 그래서 잘 되기도 합니다.

 

John Spicer는 프랑크푸르트 회의에서 export의 문제를 채택하여 제라고 말했습니다. 다른 무리도 말했다고 생각합니다. 그것은 좋은 예입니다. 그러나 그것으로부터 무엇인가 단 하나의 교훈인 듯한 것을 꺼낼 수는 없었습니다. 제가 export에 관해서 말하는 것은 너무 지나치게 규모를 확대하여 복수의 기술 안을 도입하는 것은 좋지 않을까라고 말한 것입니다. 물론 더 명확한 설계를 해야 합니다.




Bjarne Stroustrup Concept와 미래를 말하다 - 1  http://jacking.tistory.com/443

Bjarne Stroustrup Concept와 미래를 말하다 - 2  http://jacking.tistory.com/467

Bjarne Stroustrup Concept와 미래를 말하다 - 3  http://jacking.tistory.com/474

Bjarne Stroustrup Concept와 미래를 말하다 – 4 http://jacking.tistory.com/559

Bjarne Stroustrup Concept와 미래를 말하다 – 5  http://jacking.tistory.com/652

Bjarne Stroustrup Concept와 미래를 말하다 – 6  http://jacking.tistory.com/678

Bjarne Stroustrup Concept와 미래를 말하다 – 7  http://jacking.tistory.com/679

 



출처 : http://www.devx.com/cplus/Article/42448/0/page/1

저작자 표시
신고
by 흥배 2010.06.23 20:30

Page 4: Commitees and Standardization

 

Danny Kalev

당신은 몇 번이나 100명의 위원회라고 하는 것은 「혁신적인 설계에 최적인 장소는 아니다」라고 말하고 있습니다. ISO 표준화 위원회는 너무 사람이 많은 것은 아닌가요? RubyPhtyon은 「선 독재제」(역주:구현이 하나 밖에 없고, 기본적으로 단지 한 명이 독단으로 개발하고 있으며 그 구현이 그대로 사양이 되는 언어를 말하는 것)모델을 사용하여 표준화를 하고 있지요. Linux는 커뮤니티 프로세스군요. 더 무엇인가 지금의 시대에 맞는 다른 프로세스로 표준화 하는 것을 생각해 보면 어떻습니까? 지금 같이 쓸데없이 꼼꼼하고 불편한 것이 아닌 더 모두가 직접 참가할 수 있는 느낌으로

 

 

Bjarne stroustrup

저의 문서를 읽어봐 주세요. 표준화와 진화 모델에 대한 염려가 쓰여져 있습니다.HOPL3 paperHOPL2 paper. 그것은 차치하고 저는 「좀 더 모두가 직접 참가할 수 있다」라는 것이 향상으로 연결된다고는 생각되지 않아요. 언어의 논의에 있어서 보통「목소리」는 대체로 단기적인 것의 견해를 하고 있으며 유행에 좌지우지되고 있고 게다가 단 하나의 기능 밖에 생각하고 있지 않아요. 대부분이 「간단하고 완벽한 해결 방법」인지를 복잡한 문제에 적용할 수 있다고 믿고 있으며기존의 몇 십억 행의 코드、몇 백만 명의 프로그래머에 대한 교육이라고 하는 것에 대한 배려가 충분하지 않아요. 몇 년이나 참을성이 많고, 설계, 표준화를 위해 많은 귀찮은 세부를 명확하게 하는 일을 하고 싶은 사람은 거의 있지 않아요. 제가 본 곳은 「커뮤니티 프로젝트」라고 하는 것들은 이미 잘 알려진 개념이 존재하는 것밖에 유효하지 않아요. 예를 들어 Linux에 있어서의 Unix등이에요. 근본적으로 다른 설계 사상으로부터 추려 나누는 것은 어려운 일이에요. 그것과 C++의 표준화는 완전한 자원봉사 작업인 것을 알아 두어 주었으면 합니다. 만약 C++이 조금이라도 보수를 지불하게 되어 있으면 또 다른 물건이 되었을지도 모르죠.

저는 독재주의를 좋아하지 않지만 단기적으로 보면 효율적으로 선정을 푸는 것일 수도 있겠네요.하지만 제가 생각컨대 대부분의「선 독재자」라고 하는 것은 대체로 그 힘에 빠져서 일반에서 받아 들이지 않는 개인적인 취미의 기능을 넣거나 할 것입니다. 즉 제멋대로인 독단으로 달려버립니다.

 

C++에서는 독재라고 하는 것은 아직 전혀 행해지고 있지 않아요. 최초기를 지나면 단 하나의 구현은 존재하지 않아요. C++은 그 정도의 스크립트 언어와는 비교가 되지 않는 정도로 많은 기업의 근간에 짜 넣어져 왔습니다. 한층 더 1980연대 후반부터 1990연대에는 HPIBMIntelMicrosoftSun과 같은 기업은 단지 한 명의 독단에 좌우되는 언어를 착실한 비즈니스로 사용하고 싶다고는 생각하지 않았습니다. 여태껏 그렇다고 생각합니다. C++ 표준화의 일은 주요한 유저에 의해서 되고 있습니다.





Bjarne Stroustrup Concept와 미래를 말하다 - 1  http://jacking.tistory.com/443

Bjarne Stroustrup Concept와 미래를 말하다 - 2  http://jacking.tistory.com/467

Bjarne Stroustrup Concept와 미래를 말하다 - 3  http://jacking.tistory.com/474

Bjarne Stroustrup Concept와 미래를 말하다 – 4 http://jacking.tistory.com/559

Bjarne Stroustrup Concept와 미래를 말하다 – 5  http://jacking.tistory.com/652

Bjarne Stroustrup Concept와 미래를 말하다 – 6  http://jacking.tistory.com/678


저작자 표시
신고
by 흥배 2010.06.12 08:30

Danny Kalev

최근의 DDJ 기사에서 「ConceptC++0x의 근간을 이루는 신기능이다」라고 쓰고 있지요. 어떤 사람은 C++0x의 「주요 기능」이라고 단언했었어요(N2893. 그렇지만 Concept이 들어가지 않는다고 정한 것은 어쩐지 무정하네요. 예를 들면 Herb Sutter블로그에 쓰고 있습니다만 concept 연기에 관한 Web 상의 코멘트를 읽고 있으면 기술적인 부정확함은 물론이고 C++0xConcept이 들어가지 않는다고 하는 것은 굉장히 중대한 일이라고 생각하고 있는 것 같다. 이상한 일이다」라든가. 결국 Concept 어떻게 되도 상관 없는 것이네요. 어째서 이런 기능에 바보같이 시간과 일손을 소모했습니까?

 

 

Bjarne stroustrup

내가 썼던 것을 전부 인용하면

Concepttemplate의 사용을 보다 논리적으로 하거나 표준 라이브러리의 규격을 고쳐 쓰거나 하는 것에 근간을 이루는 신기능이며 또 제네릭 프로그래밍을 일반적으로도 사용할 수 있도록 하기 위한 주요한 기능이다.

이것은 단지

ConceptC++0x의 근간을 이루는 신기능이다」

라고 하는 것은 꽤 인상이 달라집니다.

그리고 저로서는 concept 자체를 「주요 기능」이라고 말하거나 하지 않았습니다. 그렇다고 하는 것도 어느 하나의 기능만을 가지고 그 언어의 「주요」라고 하는 등이라고 하는 것은 의미를 알 수 없습니다. 대부분의 사람에게 있어서 C++0x의 가장 중요한 신기능이란 병렬처리(concurrency)의 표준 지원이라고 생각하지 말세요. concept과 같이 taskatomic type 등을 직접 사용하는 것은 극히 일부의 프로그래머 뿐이지만 혜택을 받는 사람은 많습니다. C++0x의 개량은 보다 더 프로그램을 쓰거나 개발 환경을 만드는데 도움이 되는 툴에 중점을 두고 있습니다. 단지 그 기능 자체 뿐입이라고 잘라서 말할 수 있는 것은 아닙니다.

제가 생각컨대 concept이란 중요했고 또 장래도 중요하게 될 것입니다. 템플릿의 usability를 향상시켜 제네릭 프로그래밍의 범위를 펼쳐、고품질 라이브러리의 지원을 위한 중요한 기능입니다. 몇 십년의 장기적으로 봐도 중요합니다. 하지만 일반 프로그래머에 있어서 이 앞의 수년의 중요도라고 하는 것은 그만큼은 아닐 것입니다. 손을 쓸 수 없게 되기 전에 concept이 어쩔 수 없이 필요한 시대에 이르기 전에 개량한 concept을 넣을 수도 있을 것입니다.

장기적인 것의 견해가 중요합니다. 원래 Concept은 많은 C++0x의 개량점 중 하나 밖에 지나지 않는 것입니다. 비록 Concept이 없어도 C++0xC++98 보다 아득하게 뛰어난 툴이 될 것입니다.




Bjarne Stroustrup Concept와 미래를 말하다 - 1  http://jacking.tistory.com/443

Bjarne Stroustrup Concept와 미래를 말하다 - 2  http://jacking.tistory.com/467

Bjarne Stroustrup Concept와 미래를 말하다 - 3  http://jacking.tistory.com/474

Bjarne Stroustrup Concept와 미래를 말하다 – 4 http://jacking.tistory.com/559

Bjarne Stroustrup Concept와 미래를 말하다 – 5  http://jacking.tistory.com/652


저작자 표시
신고
by 흥배 2010.06.11 08:30
정말 오랜만에 나머지 번역하고 있습니다. 언제쯤 끝날지...-__-;;;


Bjarne Stroustrup Concept와 미래를 말하다 - 1  http://jacking.tistory.com/443

Bjarne Stroustrup Concept와 미래를 말하다 - 2  http://jacking.tistory.com/467

Bjarne Stroustrup Concept와 미래를 말하다 - 3  http://jacking.tistory.com/474

Bjarne Stroustrup Concept와 미래를 말하다 – 4 http://jacking.tistory.com/559


 


Danny Kalev

저는 그다지 Concept의 팬이 아닙니다만 conceptrequires 키워드의 필요성은 알고 있습니다.

그래도 왜 concept map이나 axiom 등이 필요합니까? 개인적으로는 언어를 무의미하게 복잡화 시키고 탁상 공론으로 비 현실적인 장난감이라고 생각합니다. 도움이 되는 이용 방법도 있겠지만 처음은 기본적인 곳부터 시작하여 나중에 주의 깊게 확장해 가는 것이 좋지 않을까요?

 

 

Bjarne stroustrup

.. ~. 키워드 수의 삭감이 목적은 아닙니다. 제네릭 프로그래밍을 지원하기 위해서 필요합니다. concept을 편리하게 하려면 현행의 성공 예를 명확화 해서 지원하지 않으면 안됩니다. concept이 받아 들여지기 위해서는 현행의 성공 예를 완전하게 지원하지 않으면 안됩니다. 그렇지 않으면constrainedunconstrained template가 뒤죽박죽 될 뿐입니다. concept이 받아 들여지기 위해서는 「구태 의연한 unconstrainedtemplate로부터 「concept baseconstrainedtemplate로의 간단한 변환 방법을 제공하지 않으면 안됩니다. 이야기는 빗나가지만 제가 프랑크푸르트 전의 컨셉 규격의 설계에 대한 usability에의 염려는 이것도 관계하고 있습니다.

 

concept map에 대해서 생각해 보죠. concept에 임의의 형태를 적용시키는 어떠한 기구가 필요합니다. 이 기능이 없으면 그 concept을 염두로 설계된 형태만 사용할 수 있습니다. 당신이 행운의 별에서 태어났다면 우연히 시그너쳐가 일치하고 있을지도 모르겠네요. 원래 완전한 신기능이기 때문에 유저끼리 서로 협조하면 concept에 일치하는 형태를 강제할 수 있을 것이라고 생각할지도 모릅니다. 그런데 C++라고 하는 것은 1972년부터의 역사를 가지고 있고 넓게 사용되고 있는 언어입니다. 이미 많은 상상도 할 수 없는 듯한 형태가 있고, 매일 매일 새로운 형태나 concept이 만들어지고 있습니다.

 

잠시 여기서 말해 둘 것이 최근 10년 정도부터 개발자들은 이미 concept을 발명하였고 템플릿을 그 concept에 따라서 쓰고 있습니다. 그러한 「concept」은 단지 명시화 되어 있지 않은 정도 입니다. 대체로 필요 사항 등 문서도 불완전하고 제멋대로인 가정도 포함되어 있습니다.

 

그러한 이유로 기존의 concept 예를 들면 random access iterator와 기존의 형태 예를 들면 int*를 예로 들겠습니다. 여기서 형태를 concept을 요구하는 템플릿 인수로 사용하고 싶다고 합니다. 도대체 어떻게 하면 좋을까요? 언어에 concept map이 없으면 꾸며낼 수 밖에 없습니다. 예를 들면 RandomAccessIterator는 멤버형(역주:규격적으로 말하면 클래스에 네스트 된 형태)으로서value_type이 없으면 안됩니다. RandomAceessIterator를 사용하는 템플릿 코드는 그 이름을 인수의 형태의 멤버 명으로서 사용합니다. 그런데 int*에는 value_type 등이라고 하는 멤버는 없습니다. 원래 int*에는 멤버 따위가 없습니다. 그렇다고 하는 것은 Dennis Ritche가 포인터에 멤버 등이 필요 없다고 1972년에 결정했기 때문입니다. 타임 머신도 있지 않는한 당시 int*에 멤버를 덧붙이는 것은 할 수 없고, 그 때문에 C with value_type(역주:C with classes의 패러디)등이라고 하는 언어를 1994년 시점에서 발명하는 것도 할 수 없었던 것입니다.

 

언어에 concept map이 없으면 자신이 map을 만들 수 밖에 없습니다. 이 「map」은 int*의 래퍼 클래스로 value_type을 멤버로 가지고 있으며 다른 random access 조작도 할 수 있습니다. 행운과 뛰어난 컴파일러를 타고 나면 int*와 정말 변함 없는 성능을 얻을 수 있을 것입니다. 그리고는 모든 int*Self 클래스의 RandomAccessIterator로 래핑 할 뿐입니다. 제네릭 프로그래밍의 경험이 있으면 이런 류의 래퍼 클래스나 비슷한 아이디어인 traits는 자주 보았을 것입니다. 이러한 workaround 코드는 일반적이고 제네릭 코드에서는 간단합니다. 다만 쓰는 것은 귀찮고 대체로는 범용적이지 않고 극히 한정된 것 밖에 동작하지 않습니다. 전문가가 아니면 이해 하기 어렵습니다. 그래서 문제의 원인입니다.

concept_map은 이러한 현실적이고 근본적인 문제의 직접적인 해결 방법입니다. 예를 들면

 

template<class T> concept_map RandomAccessIterator<T*> {

typedef T value_type;

};

 

이것은 T* RandomAccessIterator로서 사용하면 그 value_typeT라고 하는 의미입니다. 위와 같이 어떤 문법이 제일 좋은 것인가에 대해서는 논의가 있지만 이러한 것을 표현할 필요가 있습니다. 「이러한 것을 표현」하는 것은 실제로 필요합니다. 완벽하고 범용적인 workaround 등이 존재하지 않습니다. 그러니까 언어 기능으로서 반드시 필요합니다. concept map 없이 concept을 사용한 제네릭 코드 등을 쓰고 싶다고는 생각하지 않습니다.

 

simplifying the use of concepts에서의 논의를 또 언급 하지 않겠지만 제가 말하고 싶었던 것은 concept map은 쓸데 없이 너무 사용되고 복잡하고 사용하기 어렵다고 하는 것입니다. 저는 그 문제를 해결하기 위한 제안을 했습니다. 무엇이든 존재하지 않는 조작을 덧붙이거나 이름을 바꾸거나 하여 형태를 concept에 일치시키기 위한 구조로서 concept map은 경험상 필요하고 논의의 여지도 없는 것입니다.

 

이미 설명한 것처럼 concept는 지정된 문법에 대해서 동작합니다. 어느 형태가 구체적인 이름에 의한 조작이나 형태를 가지고 있지 않으면 안 된다고 하는 것을 명시합니다. 예를 들면 random access iterator로서 사용하기 위해서는 그 형태는 *, ++, [], value_type 등을 제공하고 있지 않으면 안 되는 것 등입니다. 상식적으로 생각하면 이러한 조작은 「올바른 일을 한다」라고 보여지고 있으며 그 「올바른 일」은 어딘가 다른 문서에 쓰여져 있습니다. 이 경우 C++ 표준 규격입니다. 이것은 concept이 언어 측에서 지원 되고 있는지 어떤지에 관련되지 않고 하나입니다. 템플릿에 대한 문서라고 하는 것은 의미적인 필요 사항을 모두 쓴 것입니다. 좋은 문서일수록 그 필요 사항도 자세하게 쓰여지게 됩니다. 여기서의 문제란 도대체 어디까지 의미적인 필요 사항을 언어 측에서 지원하면 좋은 것인가? 또 어떻게 지원하는 것인가? 라고 하는 것입니다.

 

axiom에서는 코드 중에 자세한 의미 상의 규약을 간단한 문법으로 기술할 수 있습니다. 예를 들면

 

concept ForwardIterator<typename X> : InputIterator<X>, Regular<X> {

  requires Convertible<postincrement_result, const X&>;

  axiom MultiPass(X a, X b) {

   if (a == b) *a <=> *b;

   if (a == b) ++a <=> ++b;

  }

}

 

이 기술은 ForwardIterator이란 InputIterator이며 == 등을 제공하여 Regular이며 시퀀스에 대해서multiple pass라고 하는 공리가 성립됩니다. <=>라는 것은 동등 연산자입니다. ForwardIteratorab에 대해서 ab가 동일하다면 *a에 대한 조작은 *b에 대한 조작과 동일하다 입니다. 고등학교의 대수학에 약한 녀석들은 맨발로 도망갈 것입니다. 그러나 기술된 논리라고 하는 것은 고전적으로 범용적이고 의미를 기술하는데 효과적입니다.

 

axiom의 규격 설계에는 두 개의 목적이 있습니다.

l  보다 자세한 문서를 기술시키는 것.

l  프로그래머는 코드 상에서 직접 개발 환경에 정보를 전할 수 있는 것.

 

많은 무리는 axiom의 목적을 아래와 같이 잘못 생각하고 있습니다.

 

l  axiom은 컴파일러에 의해 좋은 코드를 생성시키기 위한 것이라는 등.
실제 axiom는 특히 그러한 용도가 뛰어나지 않습니다. 제가 사용하는 형태라고 하는 것은 수학적인 법칙에 따르는 것은 아니기 때문입니다. double과 같은 부동 소수점수(실수)는 실수의 법칙에는 따르지 않습니다. 실수에는 NaN 등이 없기 때문입니다. int의 종류는 정수의 법칙에는 따르지 않습니다. 수학적인 정수는 오버플로우 등이 없습니다. 만약 axiom을 최적화를 위해 설계하고 있었다면 지금쯤 대 실패했을 것입니다.

 

l  axiom은 형태를 증명하기 위한 것이 라는 등등.
수학을 공부할 때 공리라고 하는 것은 증명을 하기 위해서 사용하는 것입니다. 저도 C++ 컴파일러에 정리의 증명 기능 따위를 제안할 생각은 없습니다.

 

l  제안되고 있는 술어 이론(역주:predicate logic)의 문법으로 충분히 의미 기술을 할 수 있는 것인가? 더 확장해서는 안 되는 것인가? 등등.
술어 이론은 매우 길고 또 훌륭한 역사를 자랑하고 있으며 표현력이 있습니다. 저는 모험적으로 확장하거나 하지 않습니다.

 

라는 것은 axiom의 사용 목적과 자주 있는 오해를 설명한 것입니다. 그럼 남은 이용 방법은 도움이 되는가 하면 도움이 된다고 말할 수 있습니다. concept의 문서에는 많은 공리를 이용하고 있다고 하는 현실이 있습니다. 그러나 이점이라고 하는 것은 실제로 나타내 보이는 것이 어렵습니다.

여기서 axiom의 구체적인 사용법을 설명 하거나 하지 않지만(자세한 것은 N2887 참조)concept을 사용하는데 있어서의 어려운 문제에 문법상은 거의 같지만 의미가 다른 복수의concept이라고 하는 것이 있습니다. 예를 들어 foward iteratorinput iterator입니다. 저는 다음의 concept의 설계에서는 더 axiom을 전면적으로 밀어 내고 의미상의 차이를 취급하기 쉽게 할 생각입니다.

 


저작자 표시
신고
by 흥배 2010.05.11 08:30

Concept이 빠진 이후 Bjarne Stroustrup와 이것에 대해서 이야기를 한 글을 번역 중이지만 너무 길어서 언제 끝날지 몰라서 간략하게 왜 빠졌는지 간추려봅니다.

 

 


Concept이 빠진 이유는 여러가지 있지만 가장 큰 이유는 concept map을 암무적으로 생성할지 안 할지에 대한 것이었음.

 

어떤 concept에 대해서 대응하는 concept map을 암묵적으로 생성할지, 아니면 만약 concept map이 빈 것이라도 명시적으로 정의를 해야 하느냐의 문제. 즉 어느 타입은 그 concept의 요구를 만족한다는 것을 명시적으로 선언해야만 하느냐에 관한 것이다. 이렇게 하여 시그네쳐의 일치만이 아닌 명확하게 이 타입은 이 concept을 만족하고 있다는 것을 선언 할 수 있다.

하지만 이 방법은 빈 concept map이지만 concept를 만족하기 위해 선언해야만 하므로 귀찮은 일이다.

 

 

프랑크프루트 회의에서의 해결책은 기본 concept는 암묵적으로 대응하는 concept map을 생성하고 explicit가 붙어진 경우는 concept map(만약 빈 것이라도) 명시적으로 선언 해야한다는 것을 제안하였다.

 

하지만 concept라는 것이 아주 미묘하고, 너무 엄격하고 꽤 어려운 기능이며 concept 코드를 올바르게 쓰는 것도 쉽지 않다. 게다가 프랑크푸르트 회의까지 제대로된 구현도 없었다. Douglas Gregor Concept GCC는 꽤 불안전하여 사용할만한 수준이 아니었다.

 

이런 이유로 표준화 위원회에서도 이제 됐다라는 분위가 퍼졌음. 그리고 근본적인 사상의 차이로 표결에 들어갔음. 이미 드래프트에 들어가 있는 Concept를 뺄 것인가 말 것인가

이 투표에서 Bjarne Stroustrup, Douglas Gregor도 삭제 하는 것에 표를 던졌음.

 

 

출처 : http://cpplover.blogspot.com/2010/03/blog-post_19.html

저작자 표시
신고
by 흥배 2010.03.22 08:30
Bjarne Stroustrup Concept와 미래를 말하다 - 1  http://jacking.tistory.com/443

Bjarne Stroustrup Concept와 미래를 말하다 - 2  http://jacking.tistory.com/467

Bjarne Stroustrup Concept와 미래를 말하다 - 3  http://jacking.tistory.com/474





Danny Kalev

「검사나 밸런스」에 대해서 좀 더 구체적으로 이야기 해보죠. Boost라고 하는 단체에서는 비공식적인 새로운 라이브러리를 위원회가 표준 규격에 넣기 전에 실제 환경에서 사용하여 더욱 더 많은 C++ 프로그래머로부터 피드백을 얻을 수 있었습니다. 그러나 위원회는 코어 언어 기능에 대해서는 비슷한 「실험장」을 가지고 있지 않습니다. 결국은 많은 코어 언어 기능은 착실한 실제 경험이나 테스트도 없이 워킹 드래프트에 들어가고 있지 않습니까?  Concept은 즉 그런 것이었던 것이 아닙니까? 코어 C++ 실험 단체라고 하는 물건은 개미입니까? 도움이 된다고 생각합니까?

 

Bjarne stroustrup

concept에 대한 당신의 생각은 틀렸습니다. 그런 것이라면 우리들은 그러한 「실험장」을 가지고 있었습니다. 그것은 conceptGCC로 주로 인디애나나 텍사스 A&M 대학에서 concept을 연구하고 있던 무리이며 주로 Boost에서 concept을 라이브러리에서 사용하려 하고 있던 무리입니다. concept에 대해서 걱정하고 있던 일이라고 하는 것은 그러한 연구가 충분했던 것일까라는 것과 규격 설계는 충분히 가다듬어지고 있었는가?(우리들은 이것이 제일 걱정이었다), 더 긴 시간이 필요하여 규격 제정을 늦추는 것은 아닐까 라고 하는 것(이것이 대부분의 사람들이 걱정하고 있던 것)입니다.

실제 모든 신기능은 몇몇 컴파일러로 실험되고 있었던 것입니다. 문제는「규격 설계를 규정하는데  충분한 실험은 어느 정도인가」라고 하는 것이에요. 기능마다 대답은 바뀔 것이라고 생각합니다.

주요 C++ 유저나 C++ 벤더로부터 연간 수만 달러 정도의 지원금을 모집하여 이러한 「C++ 설계 및 검증 연구실」로 되는 것을 설립 운영하는 것은 이치에 맞습니다. 하지만 아무도 흥미를 가지고 있지 않는 것 같습니다. 코몬즈의 비극에 잘 비슷하지만 무리들은 오히려 그 100배의 돈을 몇몇 제품에 쏟아 넣어 또 다른 상업적 이익을 얻고 싶은 듯한 것 같습니다.

 

 

Danny Kalev

잘 모르는겠는데 Conceptrvalue reference는 데쟈브라는 생각이 듭니다. 당초 rvalue reference대부분의 유저에게도 알기 쉽다라는 것이 아닙니까. 그렇지만 지금은 다른군요. 아마추어 프로그래머도 move constructor라든가 함수의 오버 로딩의 룰 변경이라든지 void A::f(); void A::f()&; and void A::f()&&;은 전부 다른 의미이고 rvalue는 이젠 lvalue가 되지 않는다든가 이러한 것을 알고 있지 않으면 안됩니다. rvalue referenceConcept과 같이 너무 복잡하여 불안정하고 쓸데 없이 터무니없이 커지고 있는 것이 아닐까요? 정말로 넣을 가치가 있습니까?

 

Bjarne stroustrup

한 번 더 말하지만 「아마추어」라고 말 하는 것은 그만두는 편이 좋아요. 원래 실제 우리들은 밖에서 보면 모두 「아마추어」입니다. 현대의 소프트웨어는 한 명의 인간으로 어떻게 할 수 없을 만큼 복잡해서 모두 아마추어로 낮추어져 버립니다. 우리들도 대부분의 일에 관해서 「아마추어」이고 당시도 그렇습니다. 우리들이 모두 대부분 「아마추어」이기 때문에 그러한 말투는 그만두고 빨리 공부를 시작하세요. 「분할하여 공략」(원어:분할 통치 "Divide and conquer")가 기본. abstractionlayering은 도움이 되는 방법입니다.

모든 언어 설계라고 하는 것은 레이어라는 생각이 듭니다. 무엇보다 간단한 예로 말하면 프로그래머는 단지 std::vector로 행렬 클래스를 사용했을 때에 그 퍼포먼스가 향상하고 있는 것을 깨달을 것입니다. 더 자세하게 보면 move constructor가 퍼포먼스 향상의 이유라고 하는 것에 깨달을 것입니다. 컨테이너를 move하는 것은 copy보다 쌉니다. 한층 더 다음 레벨에서는 프로그래머는 move constructorperfect forwarding 함수를 사용합니다. 이것은 단지 std::move()std::forward()를 사용하면 좋은 것뿐입니다. 여기서 rvalue reference에 대해서 무엇인가 특별히 이해해 두지 않으면 안 되는 것도 있을 겁니다만 대부분의 프로그래머는 거기까지 깊이 관여하지 않을 것입니다. 생각컨대 대부분의 프로그래머는 「A::f()&&;는 도대체 어떤 의미일까」라든가 「std::move()는 도대체 어떻게 구현 되어 있지」등이라고 하는 의문이 끓는 일은  없을 것입니다. 그러한 의문은 이해해야 한다고 하는 이유가 있어야만 이해하려고 합니다. 대부분의 프로그래머는 더 의미가 있는 고급 코드를 쓰는 것에 시간을 소비합니다. 원하는 것은 좋은 프로그래머이지 언어 오타쿠는 아닙니다.

당신이 conceptrvalue reference를 비슷하다는 느낌을 받은 것은 틀린 것은 아닙니다. 양쪽 모두 형태 시스템의 문제입니다. 그러므로 근본적으로 방대하고 복잡합니다. 양쪽 모두 「유저 인터페이스」를 가지고 있으며 세부가 신경이 쓰이는 프로그래머를 멀리해 줍니다. 그러나 「concept」은 방대하다는 것 이상의 것으로 장기적으로는 rvalue reference보다 중요합니다.




저작자 표시
신고
by 흥배 2010.01.25 09:00

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
| 1 2 |