C ++가 개념 구현을 위해 D의 접근 방식을 채택 할 수없는 이유는 무엇입니까?

많은 사람들이 알고 있듯이, concepts , 템플릿 인수에 대한 가능한 유형을 제한하는 C ++의 접근 방식은 C ++ 11에 포함되지 않았습니다.

D 프로그래밍 언어 2.0에는 일반 프로그래밍과 비슷한 기능이 있습니다. 그 해결책은 나에게 매우 우아하고 단순 해 보입니다.

그래서 제 질문은 C ++이 비슷한 접근법을 사용할 수없는 이유 입니다.

• C ++ 개념의 목표는 D 구현이 제공하는 것보다 클 수 있습니까?
• 아니면 C ++의 레거시로 인해 그러한 접근 방식을 채택하지 못합니까?
• 아니면 다른?

답변 주셔서 감사합니다.

추신 : D의 일반적인 프로그래밍 파워의 예를 보려면 다음을 참조하십시오 : https : //.com/questions/7300298/metaprogramming-in-c-and-in-d/7303534#7303534

C ++ 표준은 표준 문서이며 향후 문서에서 거의 영향을받지 않는 규칙을 설정합니다. 따라서위원회는 업데이트와 관련하여 매우 신중한 접근 방식을 취했습니다.

표준 라이브러리에 추가하는 것은 다소 쉬웠습니다. 많은 라이브러리가 오랫동안 Boost에있었습니다.

그러나 언어의 핵심 개념에 대한 추가는 먼저 컴파일러를 수정해야하기 때문에 실험하기가 훨씬 어렵습니다. 컴파일러 지원없이 C ++ 03 기능 (템플릿 내보내기)이 지정되었습니다. 결과는 무섭습니다. EDG 컴파일러 프론트 엔드의 구현 자들은이를 거의 달성하지 못한 엄청난 작업 (수년)으로보고했습니다. 다른 컴파일러는 그것을 구현하려고 시도하지 않았습니다. 편안한 상황이 아닙니다.

라이브러리와 비슷 constexpr하거나 static_assert쉬운 기능 (이미 라이브러리에서 에뮬레이션 됨). Lambdas는 다양한 다른 언어로 잘 이해되고 구현되어 있으며 광범위한 연구가 이미 진행되었으므로 주로 구문 문제였습니다.

반면 개념에 너무 판단하고 새로운 및 해보지 . 그것들은 제 시간에 간신히 지정되었고, 개념에 대한 증거는 없었으며, 따라서 그들은 그들을 기다리거나 실수하기보다는 거부당했습니다.

왜 D를 따르지 않습니까? 그렇지 않다는 말은 없습니다. 위원회는 마감일없이 처음부터 다시 생각하고 언어의 다른 기능과 상호 작용하는 방식을 확인하기 위해 컴파일러에 포함시킬 것을 권장했습니다. 개념과 개념지도를 분리하는 문제가 있습니다. 그것들은 하나로 묶어야합니까?

참고 : 현재 인디애나 대학교의 Larisse Voufo가이 실험에 전념 한 Clang 지점이 있습니다.

2011 년 표준의 경우, C ++ 개념이 작업 중이 었으며 "충분히 구워지지"않았기 때문에 결국이 표준에서 제외되었습니다. C ++ 개념을 계속 연구하여 다음 표준으로 만들 수 있습니다. 그러나 일부 사람들은 D의 템플릿 제약과 유사한 다음 표준에 대한 제안을 할 것입니다. 그것이 발생하는지 여부는 여전히 남아 있습니다. 내가 아는 한, 2011 표준에 대한 그러한 제안은 없었기 때문에 그것이 그것의 장점에 관계없이 그 표준으로 만들 수있는 기회는 없었지만, 다음 표준으로 그것을 만들지 않을지는 완전히 알 수 없습니다. 이 지점에서.

C의 ++이 컴파일 타임에 할 수있는 일에 일반적으로 더 제한되어 있기 때문에 D의 템플릿 제약 조건과 유사한 것을 C ++에 대해 구현할 수없는 주요 이유는 알지 못합니다. D에서와 마찬가지로 ( constexpr물론 소개가 확실히 도움이 되지만 ).

그래서 짧은 대답은 D의 템플릿 제약과 비슷한 것이 C ++에 없었던 기술적 인 이유가 없다는 것입니다.

문제는 그러한 제안이 다음 표준에 대해 이루어질 지 여부와 유사한 제안이 만들어지는 것과 비교할 수있는 방법 (예 : 개념 관련 제안)입니다. 수용 가능한 제안을 할 수 있다고 가정 할 때, 개념이나 D의 템플릿 제약과 유사한 것이 그에 대한 요구가 많기 때문에 다음 표준으로 만들 것이라고 완전히 기대합니다. 문제는 누구나 견고하고 "충분히 구운"제안을 받아 들일 수 있는지 여부입니다.

D의 템플릿이 제한적이라는 것을 의미합니까?

내가 아는 한, boost :: concept 대신 C ++ 개념이 제안되었습니다. 여기서 문제는 boost는 C ++ 03 용으로 작성된 라이브러리라는 것입니다. C ++ 11에는 C ++ 03에서 허용하는 것과 다른 방식으로 특정 사항을 구현할 수있는 다른 구문 기능이 있습니다 (따라서 새로운 구문을 활용하여 부스트 자체를 다시 작성할 수 있음).

표준위원회는 개념을 지정하는 데 너무 오래 걸렸기 때문에 개념을 삭제했습니다 (따라서 c ++ 11 승인이 다시 지연됨). 아마도 다음 C ++ 릴리스에서 나올 것입니다.

한편 D 구문은 C ++과 다르고 D 자체는 컴파일 타임에 일부 표현식 평가 기능을 유지합니다. C ++은 일부 레거시 코드를 중단하지 않고 항상 가질 수는 없습니다 (D에는없는 역사를 가지고 있음). C ++ 자체가 지금 가지고 static_assert와 costexpr, 그 컴파일시 평가 능력을 향상시킬 수 있습니다. 앞으로 비슷한 수준에 도달 할 수 있습니다.

Herb Sutter의 QA는 15 분 마크에서 컨셉에 대해 이야기합니다.

http://channel9.msdn.com/Shows/Going+Deep/Herb-Sutter-C-Questions-and-Answers

당신이 그것을 좋아한다면, 여기에 다른 하나가 있습니다 : http://channel9.msdn.com/Shows/Going+Deep/Conversation-with-Herb-Sutter-Perspectives-on-Modern-C0x11

이제 당신의 질문에 관해서. 왜 D 버전이 아닌가? 왜 그것을 사용합니까? C ++는 매우 복잡하고 안정적인 언어입니다. 각 기능은 일반적으로 수십 년 동안 지원되어야하므로 매우 신중하게 선택해야합니다. 첫 번째 C ++ 표준을보고 수정본을 따르는 경우, 더 이상 사용되지 않는 기능이 있지만 여전히 지원해야하는 기능이 있습니다. 따라서 개념을 100 % C ++에 맞게 설계하는 것이 좋습니다.

C ++ 0x에 포함되지 않은 이유는 무엇입니까? 잘 되었기 때문에. 제안서의 길이는 100 페이지이며 구현하기가 매우 어렵습니다. 이 기능이 표준에 포함될 때까지 성숙하려면 더 많은 시간이 필요하다고 결정되었습니다.

간단히 말해, C ++에는 D보다 훨씬 더 많은 역사적인 수하물이 있습니다. C ++에 대량의 기록 코드가있어 제대로 작동해야한다는 사실이 아니라면 엄청나게 많은 것들을 구현하는 것이 훨씬 쉽습니다. 그리고 예상대로. D는이 문제가 없습니다.