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