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