C ++는 D보다 어떤 기능을 수행합니까?

나는 최근에 D를 배우고 있으며 언어에 익숙해지기 시작했습니다. 나는 그것이 무엇을 제공하는지 알고, 아직 모든 것을 사용하는 방법을 모른다. 그리고 나는 D 관용구 등에 대해 많이 모른다. 그러나 나는 배우고있다.

나는 D를 좋아한다. 어떤 언어 로 C를 대대적으로 업데이트하고 훌륭하게 수행 하는 좋은 언어 이다. 그 기능들 중 어느 것도 "볼트 된"것처럼 보이지 않지만 실제로는 잘 생각되고 잘 설계되었습니다.

당신은 종종 D가 C ++이 되어야한다고 들었습니다. (불필요한 화염 전쟁을 피하기 위해 각자와 스스로 결정해야 할 것인지에 대한 질문을 남깁니다). 또한 여러 C ++ 프로그래머로부터 C ++보다 D를 훨씬 더 좋아한다고 들었습니다.

나 자신은 C를 알고 있지만 C ++을 알고 있다고 말할 수는 없습니다. C ++가 D보다 언어 보다 더 나은 것이 있다고 생각되면 C ++과 D를 모두 알고있는 누군가의 의견을 듣고 싶습니다 (보통 "타사 라이브러리가 더 많음"또는 "더 많은 리소스가 있음"또는 D보다 C ++가 필요한 작업이 더 많습니다 ").

D는 C ++의 많은 문제를 해결하기 위해 매우 숙련 된 C ++ 프로그래머 ( D 커뮤니티의 도움을 받아 Walter Bright 와 Andrei Alexandrescu )가 설계했지만 실제로는 나아지지 않은 것이 있었습니까? 그가 놓친 것? 더 나은 해결책이 아니라고 생각하십니까?

또한 D 1.0이 아니라 D 2.0 에 대해 이야기하고 있습니다.

C ++가 D보다 더 잘하는 것의 대부분은 메타적인 것입니다. C ++에는 더 나은 컴파일러, 더 나은 도구, 더 성숙한 라이브러리, 더 많은 바인딩, 더 많은 전문가, 더 많은 자습서 등이 있습니다. 보다 성숙한 언어에서 기대합니다. 이것은 논쟁의 여지가 없다.

언어 자체에 관해서는 C ++이 D보다 더 나은 점이 몇 가지 있습니다. 아마도 더 있을지 모르지만 여기에 내 머리 꼭대기를 나열 할 수있는 몇 가지가 있습니다.

C ++은 유형 시스템을 더 잘 이해하고
있습니다. 현재 D의 유형 시스템에는 몇 가지 문제점이 있는데, 이는 설계에 대한 감독으로 보입니다. 예를 들어, 구조체에 const의 전이성 및 postblit 생성자가 값 유형에서 작동하는 방식으로 인해 클래스 객체 참조 또는 포인터가 포함되어 있으면 const 구조체를 비 const 구조체에 복사하는 것은 현재 불가능합니다. Andrei는이 문제를 해결하는 방법을 알고 있지만 자세한 내용은 밝히지 않았습니다. 문제는 확실히 고칠 수 있지만 (C ++ 스타일의 복사 생성자를 소개하는 것이 하나의 해결책 일 것입니다), 현재 언어의 주요 문제입니다.

나를 괴롭힌 또 다른 문제는 논리적 const가 없다는 mutable것입니다 (예 : C ++에서는 그렇지 않습니다 ). 이것은 스레드 안전 코드를 작성하는 데는 좋지만 const 객체 내에서 게으른 초기화를 수행하는 것을 어렵게 만듭니다 (불가능합니까?) (첫 번째 호출에서 반환 된 값을 구성하고 캐시하는 const 'get'함수를 생각하십시오).

마지막으로, 이러한 기존의 문제를 주어, 나는 타입 시스템 (나머지 방법에 대한 걱정 pure, shared그들이 사용에 투입되면, 등) 언어의 다른 모든 것들과 상호 작용합니다. 표준 라이브러리 (Phobos)는 현재 D의 고급 유형 시스템을 거의 사용하지 않으므로 스트레스를받을 지에 대한 질문은 합리적이라고 생각합니다. 나는 회의적이지만 낙관적입니다.

C ++에는 유형 시스템 사마귀 (예 : 비 전이 성, 불필요 iterator한 구성 요소가 있음 const_iterator)가있어 아주 추악하지만 C ++의 유형 시스템이 부분적으로 약간 잘못되었지만 D와 같은 작업을 수행하는 것을 막지는 않습니다. 때때로 그렇습니다.

편집 : 분명히하기 위해, C ++에는 더 나은 시스템이 아니라고 생각하는 유형 시스템이 있다고 생각합니다 . 기본적으로 DI에서는 C ++에없는 유형 시스템의 모든 측면을 사용하는 데 위험이 있다고 생각합니다.

D는 때때로 너무 편리합니다.
C ++에 대해 자주 듣는 비판은 저수준 문제를 숨기고 있다는 것입니다. 예를 들어 a = b;변환 연산자 호출, 과부하 할당 연산자 호출 등과 같은 많은 작업을 수행하는 것과 같은 간단한 할당은 다음과 같습니다 . 코드에서보기가 어렵습니다. 어떤 사람들은 이것을 좋아하지만 어떤 사람들은 그렇지 않습니다. 어느 쪽이든, D에는 더 (더 좋은?)으로 인해 같은 것들로 opDispatch, @property, opApply, lazy당신이 기대하지 않는 것들로 무고한 찾고 코드를 변경할 수있는 잠재력을 가지고있다.

나는 이것이 개인적으로 큰 문제라고 생각하지 않지만, 일부는 이것을 벗어난 것으로 생각할 수 있습니다.

D 가비지 수집
이 필요합니다 . GC없이 D를 실행할 수 있기 때문에 논란의 여지가 있습니다. 그러나 그것이 가능하다고해서 그것이 실용적이라는 것을 의미하지는 않습니다. GC가 없으면 D의 많은 기능을 잃어 버리고 표준 라이브러리를 사용하는 것은 광산에서 걷는 것과 같습니다 (누가 메모리를 할당하는지 알고 있습니까?). 개인적으로, 나는 GC없이 D를 사용하는 것이 완전히 비현실적이라고 생각합니다. 만약 당신이 GC를 좋아하지 않는다면 (이것처럼) 이것은 상당히 과장 될 수 있습니다.

D 메모리의 순진한 배열 정의 메모리 할당
이것은 내 애완 동물입니다.

int[3] a = [1, 2, 3]; // in D, this allocates then copies
int a[3] = {1, 2, 3}; // in C++, this doesn't allocate

분명히 D에서 할당을 피하려면 다음을 수행해야합니다.

static const int[3] staticA = [1, 2, 3]; // in data segment
int[3] a = staticA; // non-allocating copy

이 작은 '뒤에'할당은 이전 두 가지 요점의 좋은 예입니다.

편집 : 이것은 현재 알려진 문제입니다.
편집 : 이제 수정되었습니다. 할당이 발생하지 않습니다.

결론
나는 D vs C ++의 부정적인 점에 중점을 두었습니다. 왜냐하면 그것이 질문 한 것이기 때문에이 게시물을 C ++가 D보다 낫다는 진술로 보지 마십시오 .D가 더 나은 곳을 쉽게 만들 수 있습니다. C ++보다. 어느 것을 사용할지 결정하는 것은 당신에게 달려 있습니다.

내가 D 개발에 합류했을 때 나는 C ++에 대해 알아야 할 것이 가장 많은 사람들 중 하나라는 독특한 위치에 있었다. 이제 저는 D에 대해 가장 많이 알고있는 사람들 중 한 사람이되기 위해 훨씬 더 독특한 입장에 있습니다. 이 질문에 답할 수있는 유리한 입장. Walter도 마찬가지입니다.

C ++ (및 C ++ 2011의 의미)가 D보다 나은지 묻는 것은 대체로 "집을 청소하기 위해 전문가에게 돈을 지불하면 그들이 떠날 곳은 어디인가?" 이전보다 더 더러운가요? " C ++이 D가 할 수 없었던 그 가치가 무엇이든간에 그것은 항상 나와 엄지 손가락에게 상처가되었습니다. 거의 정의에 따르면 C ++이 D에 도달 할 수없는 것은 거의 없습니다.

언어 디자인에서 거의 이해하지 못하는 것 중 하나는 (실제로 일부 사람들이 운이 좋기 때문에) 강제되지 않은 오류가 나타나는 것보다 훨씬 적다는 것입니다. 우리 대부분의 언어 사용자는 어떤 구성이나 다른 구성을보고 "아! 이건 너무 잘못 됐어. 무슨 생각을 했니?" 문제는 언어에서 가장 어색한 사례가 모두 건전하고 바람직하지만 근본적으로 서로 경쟁하거나 모순되는 몇 가지 근본적인 결정의 여파라는 것입니다 (예 : 모듈성 및 효율성, 간결함 및 제어 등).

이 모든 것을 염두에두고, 내가 생각할 수있는 몇 가지를 열거 할 것이고, 각각에 대해 D의 선택이 다른 더 높은 수준의 헌장을 성취하려는 소망에서 어떻게 파생되는지 설명 할 것입니다.

1. D는 모든 객체가 비트 복사로 움직일 수 있다고 가정합니다. 이것은 소수의 디자인을 C ++에, 특히 내부 포인터를 사용하는 디자인, 즉 그 자체에 포인터를 포함하는 클래스로 남겨 둡니다. (이러한 디자인은 효율성이 거의 없거나 무시할 수있는 비용으로 D로 변환 될 수 있지만, 번역 노력이 필요합니다.) 우리는 언어를 크게 단순화하고 사용자 개입이 없거나 최소한으로 객체 복사를보다 효율적으로하도록 피할 수있었습니다. 전체 사본 구성 사기와 rvalue 참조는 모두 기능합니다.

2. D는 모호한 성별 유형을 허용하지 않습니다 (값 유형인지 참조 유형인지 결정할 수 없음). 이러한 디자인은 C ++에서 만장일치로 기절하고 거의 항상 잘못되었지만 일부는 기술적으로 정확합니다. 우리는 대부분 잘못된 코드와 재 설계 할 수있는 작은 분수의 정확한 코드 만 허용하지 않기 때문에이 선택을했습니다. 우리는 이것이 좋은 트레이드 오프라고 생각합니다.

3. D는 다중 루트 계층을 허용하지 않습니다. 여기의 이전 포스터는이 특정 주제에 대해 매우 흥분했지만, 이것은 잘 평가 된 근거이며 모두 공통 루트를 갖는 계층 구조에 비해 루트가없는 계층 구조의 이점이 없습니다.

4. D에서는 예를 들어 int를 던질 수 없습니다. Throwable을 상속받는 객체를 던져야합니다. D에서는 업무 상태가 더 나아지는 경쟁은 없지만 C ++이 D가 할 수없는 일 중 하나입니다.

5. C ++에서 캡슐화 단위는 클래스입니다. D에서는 모듈 (예 : 파일)입니다. Walter는이 두 가지 이유로 캡슐화를 파일 시스템 보호 의미 체계에 자연스럽게 매핑하고 "친구"의 필요성을 없애는 두 가지 이유로이 결정을 내 렸습니다. 이 선택은 D의 전체 모듈화 설계에 매우 잘 통합됩니다. 사물을 C ++와 비슷하게 바꿀 수는 있지만, 사물을 강요 할 수 있습니다. C ++의 캡슐화 범위 선택은 C ++의 실제 디자인에만 적합합니다.

하나 또는 두 개의 작은 것이있을 수 있지만 전반적으로 이것이 그렇습니다.

나는 당신이 D에서 객관적으로 많은 것을 찾는 데 어려움을 겪을 것이라고 생각합니다.C ++보다 나쁩니다. 객관적으로 더 나쁘게 말할 수있는 D와 관련된 대부분의 문제는 구현 품질 문제 (일반적으로 언어와 구현이 어려서 늦은 속도로 늦어짐으로 인해 발생합니다) 또는 문제입니다 제 3 자 라이브러리가 부족합니다 (시간이 지날 것입니다). 언어 자체는 일반적으로 C ++보다 낫고, C ++가 언어 인 것이 더 나은 경우는 일반적으로 C ++가 한 방향으로 가고 D가 다른 방향으로 가고, 누군가가 왜 주관적인 이유가 있는지에 대한 상충 관계가있는 곳입니다. 하나가 다른 것보다 낫다고 생각하십시오. 그러나 언어로서 C ++가 더 나은 이유는 명백하고 객관적인 이유는 많지 않을 것입니다.

사실, 나는 언어로서 C ++가 D보다 나은 이유를 생각해 내기 위해 정말로 두뇌를 깨뜨려야한다. 일반적으로 떠오르는 것은 트레이드 오프 문제이다.

1. D의 const 는 전이적이고 언어가 불변 이기 때문에 C ++보다 훨씬 더 강력한 보증을 가지므로 constD는 가질 수없고 가질 수 없습니다mutable . 논리적 인 const를 가질 수 없습니다 . 따라서 D의 const 시스템으로 큰 이득을 얻지 만 어떤 상황에서는 constC ++에서와 같이 사용할 수 없습니다 .

2. D에는 캐스트 연산자가 하나 뿐이지 만 C ++에는 4가 있습니다 (C 캐스트 연산자를 세면 5). 이렇게하면 일반적인 경우 D에서 캐스트를 다루기가 더 쉬워 지지만 실제로 그 와 그 형제들이 제공 하는 추가 합병증 / 혜택을 원할 때 문제가됩니다 const_cast. 그러나 D는 실제로 템플릿을 사용하여 C ++의 캐스트를 구현할 수있을 정도로 강력하므로 실제로 원하는 경우이를 가질 수 있습니다 (그리고 어느 시점에서 D의 표준 라이브러리로 끝날 수도 있음).

3. D는 C ++보다 묵시적 캐스트가 훨씬 적으며 두 함수가 서로 충돌한다고 선언 할 가능성이 훨씬 높습니다 (캐스트 또는 전체 모듈 경로를 제공하여 의미하는 기능에 대해 더 구체적으로 강요합니다) ). 때로는 성 가실 수 있지만 모든 종류의 기능 하이재킹 문제를 방지합니다 . 당신은 당신이 정말로 원하는 함수를 호출한다는 것을 알고 있습니다.

4. D의 모듈 시스템 (말할 것도없고 C ++의 #include를보다 훨씬 깨끗 방식으로 빠르게 컴파일에서)하지만, 모듈 자체를 넘어의 네임 모든 종류의 부족. 따라서 모듈 내에서 네임 스페이스를 원하면 Java 경로로 이동하여 클래스 또는 구조체에서 정적 함수를 사용해야합니다. 작동하지만 실제로 네임 스페이스를 원한다면 실제 네임 스페이스만큼 깨끗하지 않습니다. 그러나 대부분의 상황에서 모듈 자체가 제공하는 네임 스페이스는 충분합니다 (실제로 충돌과 같은 것에 대해서는 매우 정교합니다).

5. 자바와 C #과 마찬가지로, D는 다중 상속보다는 단일 상속을 가지고 있지만, 자바와 C #과는 달리,이 C ++있는 모든 문제없이 당신에게 동일한 효과를 얻을 수있는 환상적인 방법을 제공의 다중 상속이있다 (그리고 C ++의 다중 상속이 얻을 수있는 매우 지저분한 때때로). D는 있는가뿐만 아니라 인터페이스를 하지만,이 문자열이나 mixin , 템플릿이나 mixin 및 별칭이 . 따라서 궁극적 인 결과는 틀림없이 더 강력하며 C ++의 다중 상속이 수행하는 모든 문제가 없습니다.

6. C #과 유사하게 D는 구조체 와 클래스를 구분 합니다 . 클래스는 상속이 있고에서 파생 된 참조 유형 Object이며 구조체는 상속이없는 값 유형입니다. 이 분리는 좋거나 나쁠 수 있습니다. C ++에서 고전적인 슬라이싱 문제 를 제거 하고 실제로 다형 적 인 것으로 생각되는 유형과 실제로 가치 유형 인 유형을 분리하는 데 도움이되지만 적어도 C ++ 프로그래머에게는 구별이 성 가실 수 있습니다. 궁극적으로 많은 이점이 있지만 유형을 약간 다르게 처리해야합니다.

7. 클래스의 멤버 함수 는 기본적으로 다형성입니다. 비가 상으로 선언 할 수 없습니다 . 가능한지 여부를 결정하는 것은 컴파일러에 달려 있습니다 (실제로 최종 클래스이고 기본 클래스의 함수를 재정의하지 않는 경우에만 해당 ). 따라서 경우에 따라 성능 문제가 될 수 있습니다. 그러나 실제로 다형성이 필요하지 않으면 structs 만 사용 하면되며 문제는 아닙니다.

8. D에는 내장 가비지 수집기가 있습니다. C ++의 많은 사람들은 심각한 단점이라고 생각하고 현재는 구현이 심각한 작업을 수행 할 수 있다는 사실을 알고 있습니다. 개선되었지만 Java의 가비지 수집기와 아직 동등한 것은 아닙니다. 그러나 이것은 두 가지 요소에 의해 완화됩니다. 하나 는 스택에서 구조체 와 다른 데이터 형식을 주로 사용 하는 경우 큰 문제가 아닙니다. 프로그램이 지속적으로 힙에 물건을 할당하고 할당 해제하지 않으면 괜찮습니다. 그리고 두 사람은, 당신은 건너 뛸 수 있습니다 가비지 컬렉터를 원하실 경우는 단지 C의를 사용 malloc하고 free. 일부 언어 기능 (예 : 배열 슬라이싱))를 피하거나주의해야하며 표준 라이브러리 중 일부는 적어도 GC (특히 문자열 처리)를 사용하지 않으면 실제로 사용할 수는 없지만 가비지 수집기를 사용하지 않고 D로 쓸 수 있습니다 당신은 정말로 원합니다. 현명한 방법은 일반적으로 그것을 사용하고 프로파일 링이 성능에 중요한 코드에 문제를 일으키는 것으로 표시되는 곳에서는 피하는 것이지만 원하는 경우 완전히 피할 수 있습니다. 그리고 GC 구현 의 품질은 시간이 지남에 따라 향상되어 GC 사용으로 인해 발생할 수있는 많은 문제를 제거 합니다. 따라서 궁극적으로 GC 는 큰 문제가 아니며 Java와 달리 원하는 경우 피할 수 있습니다.

아마도 다른 것들도있을 것입니다. 그러나 그것은 제가 지금 생각해 낼 수있는 것입니다. 알다시피, 모두 트레이드 오프입니다. D는 C ++과는 달리 C ++과는 다른 확실한 장점을 가지고 있지만 몇 가지 단점도 가지고 있습니다. 어느 쪽이 더 좋은지는 당신이하고있는 일에 달려 있으며, 많은 경우 처음에는 더 나빠 보일 것이므로 익숙해지면 문제가 없을 것입니다. 어쨌든 D의 문제는 일반적으로 다른 언어가 이전에 해보지 않았거나 D와 완전히 다른 방식으로 수행하지 않은 새로운 것들로 인해 새로운 문제가 될 것입니다. 전반적으로 D는 C ++의 실수로부터 매우 잘 배웠습니다.

그리고 D는 언어로서 C ++보다 많은 방식으로 향상되어 일반적으로 D가 객관적으로 더 나은 경우라고 생각합니다.

1. D에는 조건부 컴파일이 있습니다. 이것은 C ++로 프로그래밍 할 때 자주 놓치는 기능 중 하나입니다. 만약 C ++이 그것을 추가한다면, C ++는 템플릿과 같은 것들에있어서 도약과 한계에 의해 향상 될 것입니다.

2. D에는 컴파일 타임 반영이 있습니다.

3. 변수는 기본적으로 스레드 로컬이지만 shared원하는 경우 가능합니다. 이것은 C ++보다 스레드를 훨씬 깨끗하게 처리 합니다. 당신은 완전한 통제에 있습니다. 스레드간에 통신하기 위해 메시지 전달 을 사용 immutable하거나 메시지를 전달 하거나 shared뮤텍스 및 조건 변수를 사용하여 변수를 만들어 C ++ 방식으로 수행 할 수 있습니다 . 심지어 동기화 된 (C # 및 Java와 유사) 도입으로 C ++보다 향상되었습니다 . 따라서 D의 스레딩 상황은 C ++보다 훨씬 낫습니다.

4. D의 템플릿 은 C ++의 템플릿보다 훨씬 강력하여 훨씬 더 쉽고 훨씬 쉽게 할 수 있습니다. 그리고 템플릿 제약의 추가와 함께, 오류 메시지는 방법 들이 C ++로보다 더 나은. D는 템플릿을 매우 강력하고 사용 가능하게 만듭니다. Modern C ++ Design 의 저자 가 D의 주요 공동 작업자 중 하나 라는 것은 우연의 일치가 아닙니다 . C ++ 템플릿은 D 템플릿과 비교할 때 심각하게 부족한 것으로 나타 났으며 C ++로 프로그래밍 할 때 때때로 매우 실망 스러울 수 있습니다.

5. D에는 기본 제공 계약 프로그래밍이 있습니다.

6. D에는 내장 단위 테스트 프레임 워크가 있습니다.

7. D는 string(UTF-8), wstring(UTF-16) 및 dstring(UTF-32)를 사용 하여 유니 코드를 기본적으로 지원합니다 . 유니 코드를 쉽게 처리 할 수 ​​있습니다. 그리고 string유니 코드를 사용 하고 일반적으로 걱정하지 않으 려면 유니 코드의 기본 사항을 이해하면 일부 표준 라이브러리 함수에 도움이 될 수 있습니다.

8. D의 연산자 오버로드 는 C ++보다 훨씬 뛰어나므로 한 함수를 사용하여 여러 연산자를 동시에 오버로드 할 수 있습니다. 기본 산술 연산자를 오버로드해야하는 경우와 그 구현이 연산자에 대해 동일하게 저장되는 경우를 예로들 수 있습니다. 스트링 믹스 인은 산들 바람을 일으켜 하나의 간단한 함수 정의를 가질 수 있습니다.

9. D의 배열 은 C ++의 배열보다 훨씬 낫습니다. 길이가 적절한 유형일뿐만 아니라 추가하거나 크기를 조정할 수 있습니다. 그것들을 연결하는 것은 쉽습니다. 그리고 무엇보다도, 그들은 슬라이스가 있습니다. 그리고 이는 효율적인 배열 처리에 큰 도움이됩니다. 문자열은 D의 문자 배열이며 D의 배열이 너무 강력하므로 문제가 아닙니다 (실제로는 훌륭합니다!).

나는 계속 갈 수 있었다. D가 제공하는 많은 개선 사항 this은 생성자 이름을 사용하거나 세미콜론이 몸 전체 인 경우 문장 또는 루프 본문을 허용하지 않는 것과 같은 작은 것들 이지만, 그중 일부는 상당히 크며 모두 함께 추가하면 A에 대한 수 많은 더 나은 프로그래밍 경험. C ++ 0x는 D에 C ++에서 누락 된 기능 (예 : auto람다)의 일부 기능을 추가 하지만 모든 개선 사항이 있어도 C보다 D ++보다 객관적으로 더 나은 기능은 여전히 ​​많지 않습니다.

의심 할 여지없이 주관적인 이유가 많으며 D 구현의 상대적 미숙함은 때때로 문제가 될 수 있습니다 (특히 리포지토리가 github 으로 이동했기 때문에 매우 늦게 빠르게 개선되었지만 ) (D 쉽게 할 수 있다는 사실 불구하고 제 3의 라이브러리의 부족은 확실히 문제가 될 수 있습니다 C 함수를 호출 - 그리고 정도는 덜이, C ++ 기능 - 확실히 문제를 완화). 그러나 이는 언어 자체의 문제가 아니라 구현의 품질 문제입니다. 구현 품질 문제가 해결됨에 따라 D를 사용하는 것이 훨씬 즐거워 질 것입니다.

따라서이 질문에 대한 짧은 대답은 "매우"라고 가정합니다. 언어로서의 D는 일반적으로 C ++보다 우수합니다.

RAII 및 스택 메모리 사용량

D 2.0에서는 스택에 scope클래스 인스턴스를 할당 할 때 키워드 의 값을 제거했기 때문에 스택에서 RAII를 허용하지 않습니다 .

D에서는 값 형식 상속을 수행 할 수 없으므로 모든 유형의 RAII에 대해 힙 할당을 효과적으로 수행해야합니다.
즉,를 사용하지 않으면 손으로 메모리를 할당해야하기 때문에 사용하기 emplace가 매우 어렵습니다. (나는 아직 emplaceD 에서 사용하는 것이 실용적이지 않다 .)

C ++는 장황하게하는 것이 훨씬 좋습니다. 당신이 추론을 좋아하는지, 자세한 내용을 좋아하는지에 따라 눈에 좋거나 나쁠 수 있습니다.

C ++에서 런타임 메모를 비교하십시오 .

template <typename ReturnType, typename... Args>
function<ReturnType (Args...)> memoize(function<ReturnType (Args...)> func)
{
    map<tuple<Args...>, ReturnType> cache;
    return ([=](Args... args) mutable {
            tuple<Args...> t(args...);
            return cache.find(t) == cache.end()
                ? cache[t] : cache[t] = func(args...);
    });
}

D에서도 똑같이 :

auto memoize(F)(F func)
{
    alias ParameterTypeTuple!F Args;
    ReturnType!F[Tuple!Args] cache;
    return (Args args)
    {
        auto key = tuple(args);
        return key in cache ? cache[key] : (cache[key] = func(args));
    };
}

예를 들어, template <typename ReturnType, typename... Args>vs (F), Args...vs Args, args...vs args등 의 추가 상세도를 주목하십시오 .
더 좋든 나쁘 든 C ++은 더 장황합니다.

물론 D에서도이 작업을 수행 할 수 있습니다.

template memoize(Return, Args...)
{
    Return delegate(Args) memoize(Return delegate(Args) func)
    {
        Return[Tuple!Args] cache;
        return delegate(Args args)
        {
            auto key = tuple(args);
            return key in cache ? cache[key] : (cache[key] = func(args));
        };
    }
}

그들은 거의 동일 보일 것이다, 그러나 이것은을 필요로 delegate원래 허용하는 반면, 어떤 호출 개체를. (C ++ 0x 버전 에는std::function 객체 가 필요 하므로 어느 쪽이든 입력에서 더 장황하고 제한적입니다 ...

나는 D에 대해 많이 알지 못하지만 많은 C ++ 프로그래머가 그것을 싫어한다는 것을 알고 개인적으로 동의해야합니다. 나는 D의 모습을 좋아하지 않으며 더 가까이 가지 않을 것입니다.

D가 더 많은 관심을 끌지 못하는 이유를 이해하려면 먼저 사람들을 C ++로 끌어들이는 요소를 이해해야합니다. 한마디로, 가장 큰 이유는 통제입니다. C ++로 프로그래밍하면 프로그램을 완전히 제어 할 수 있습니다. 표준 라이브러리를 교체 하시겠습니까? 할 수 있습니다. 안전하지 않은 포인터 캐스트를 원하십니까? 할 수 있습니다. const-correctness를 위반하고 싶습니까? 할 수 있습니다. 메모리 할당자를 교체하고 싶습니까? 할 수 있습니다. 형식에 관계없이 원시 메모리를 복사하고 싶습니까? 정말로 원한다면 여러 구현에서 상속을 원하십니까? 장례식이야 심지어 Boehm 수집기와 같은 가비지 수집 라이브러리를 얻을 수도 있습니다. 그런 다음 제어와 밀접한 관련이있는 성능과 같은 문제가 있습니다. 프로그래머가 더 많이 제어할수록 프로그램을 더욱 최적화 할 수 있습니다.

다음은 약간의 연구를하고 그것을 시도한 두 사람에게 이야기 할 때 본 것입니다.

통합 유형 계층. C ++ 사용자는 상속을 거의 사용하지 않으며 대부분의 C ++ 프로그래머는 구성을 선호하며 유형이 상속을 통해 합당한 이유가있는 경우에만 유형을 상속해야합니다. Object의 개념은 모든 유형을 연결하여이 원칙을 강력하게 위반합니다. 또한 C ++의 가장 기본적인 원칙 중 하나를 위반합니다. 원하는 것만 사용하십시오. Object로부터 상속받는 것에 대한 선택권이 주어지지 않고 그와 관련된 비용은 프로그래머가 자신의 프로그램을 제어 할 수있는 측면에서 C ++이 언어로 나타내는 것에 대해 매우 강력합니다.

함수와 델리게이트의 문제에 대해 들었습니다. 분명히 D는 함수 와 델리게이트를 런타임 호출 가능 함수 유형으로 가지고 있으며 동일하지는 않지만 상호 교환 가능하거나 ...일까요? 내 친구는 그들에게 꽤 문제가있었습니다. 이것은 C ++에서 다운 그레이드 된 std::function것입니다.

그런 다음 호환성이 있습니다. D는 특히 C ++과 호환되지 않습니다. 내 말은, 어떤 언어도 C ++과 호환 되지 않습니다. 부정 행위 인 C ++ / CLI를 제외하고는 직면해야합니다. 그러나 진입 장벽으로 언급해야합니다.

그리고 다른 것들이 있습니다. 예를 들어 Wikipedia 항목을 읽으십시오.

import std.metastrings;
pragma(msg, Format!("7! = %s", fact_7));
pragma(msg, Format!("9! = %s", fact_9));

printfgets이전 C 표준 라이브러리 와 같은 큰 문제와 같은 제품군에서 가장 안전하지 않은 기능 중 하나입니다 . 스택 오버플로에서 검색하면 오용과 관련된 많은 질문이 있습니다. 기본적 printf으로 DRY 위반-형식 문자열로 유형을 제공 한 다음 인수를 주면 다시 제공합니다. DRY 위반으로 잘못되면 매우 나쁜 일이 발생합니다. 예를 들어 typedef를 16 비트 정수에서 32 비트 정수로 변경 한 경우입니다. 또한 모든 사람이 자신의 형식 지정자를 발명하면 어떻게 될지 상상할 수 없습니다. C ++의 iostream은 느릴 수 있으며 운영자의 선택이 최대가 아니며 인터페이스가 작업을 사용할 수 있지만 기본적으로 안전하다는 보장이 보장되며 DRY를 위반하지 않으며 쉽게 확장 할 수 있습니다. 이것은 말할 수있는 것이 아닙니다 printf.

다중 상속이 없습니다. 그것은 매우입니다 되지 는 C ++ 방법. C ++ 프로그래머는 자신의 프로그램을 완전히 제어 할 것으로 기대하며 상속 할 수없는 언어를 적용하는 것은 그 원칙을 위반하는 것입니다. 또한 기본 구현이나 무언가를 제공하기 위해 인터페이스에서 클래스로 유형을 변경하면 갑자기 모든 사용자 코드가 손상되기 때문에 상속 (심지어 더) 취약합니다. 좋은 일이 아닙니다.

또 다른 예는 string및 wstring입니다. C ++에서 이들 사이를 변환하는 것은 이미 고통 스럽고이 라이브러리는 유니 코드를 지원 하며이 오래된 C 라이브러리는 만 사용 const char*하며 원하는 문자열 인수 유형에 따라 동일한 함수의 다른 버전을 작성해야합니다. 예를 들어, Windows 헤더에는 종종 자신의 코드를 방해 할 수있는 문제에 대처하기 위해 매우 자극적 인 매크로가 있습니다. dstring두 문자열 유형 대신에 세 가지를 관리해야하므로 믹스에 추가하면 상황이 악화 될뿐입니다. 하나 이상의 문자열 유형을 사용하면 유지 관리의 어려움이 커지고 문자열을 다루는 반복적 인 코드가 도입됩니다.

Scott Meyers의 글을 참고하세요 :

D는 프로그래머가 최신 소프트웨어 개발 문제를 해결하도록 돕기 위해 개발 된 프로그래밍 언어입니다. 정확한 인터페이스, 긴밀하게 통합 된 프로그래밍 패러다임 연합, 언어 강제 스레드 격리, 모듈 식 안전성, 효율적인 메모리 모델 등을 통해 상호 연결된 모듈을 육성함으로써 그렇게합니다.

언어 적용 스레드 격리는 장점이 아닙니다. C ++ 프로그래머는 자신의 프로그램을 완전히 제어하기를 기대하며 무언가를 강요하는 언어는 의사가 지시 한 것이 아닙니다.

컴파일 타임 문자열 조작에 대해서도 언급하겠습니다. D는 컴파일 타임에 D 코드를 해석하는 기능이 있습니다. 이것은 플러스가 아닙니다. 모든 베테랑 C ++ 프로그래머들에게 잘 알려진 C의 상대적으로 제한된 전 처리기 (preprocessor)로 인한 엄청난 두통을 고려한 후이 기능이 얼마나 악용되는지 상상해보십시오. 컴파일 타임에 D 코드를 생성하는 기능은 훌륭하지만 구문이 아닌 의미 론적 이어야합니다 .

또한 특정 반사를 기대할 수 있습니다. D는 가비지 콜렉션을 가지고 있으며, C ++ 프로그래머는 Java 및 C #과 같은 언어에 철학적으로 직접적으로 반대되는 언어를 연관시킬 것이며 구문상의 유사성도 마음에들 것입니다. 이것은 반드시 객관적으로 정당화 될 필요는 없지만, 반드시 주목해야 할 것입니다.

기본적으로 C ++ 프로그래머가 할 수없는만큼 많은 것을 제공하지는 않습니다. 아마도 D로 계승 메타 프로그램을 작성하는 것이 더 쉽지만 C ++로 계승 메타 프로그램을 작성할 수 있습니다 . 어쩌면 D 에서는 컴파일 타임 레이 트레이서를 작성할 수 는 있지만 아무도 그렇게하고 싶지 않습니다. C ++ 철학의 근본적인 위반과 비교할 때 D에서 할 수있는 일은 특히 눈에 띄지 않습니다.

이러한 것들이 표면에 문제 일지라도 표면에 D가 실제로 C ++처럼 보이지 않는다는 사실은 아마도 많은 C ++ 프로그래머가 D로 마이그레이션하지 않는 좋은 이유 일 것입니다. 아마도 D는 더 나은 직업 광고를해야 할 것입니다.

C ++에서 감사하는 한 가지는 함수 인수를 문서화하거나 포인터 대신 C ++ 참조로 값을 반환하는 기능이므로 null값 이 아닌 것을 의미 합니다.

D 버전 :

class A { int i; }

int foo(A a) {
    return a.i; // Will crash if a is null
}

int main() {
    A bar = null;
    // Do something, forgetting to set bar in all
    // branches until finally ending up at:
    return foo(bar);
}

C ++ 버전 :

class A { int i; };

int foo(A& a) {
    return a.i; // Will probably not crash since
                // C++ references are less likely
                // to be null.
}

int main() {
    A* bar = null;
    // Do something, forgetting to set bar in all
    // branches until finally ending up at:
    // Hm.. I have to dereference the bar-pointer
    // here, otherwise it wont compile.  Lets add
    // a check for null before.
    if (bar)
        return foo(*bar);
    return 0;
}

공정하게하려면 AD 를 만들고 -argument를 a로 struct표시하여 C ++에 매우 가까이 갈 수 있습니다 (클래스는 참조 유형이고 구조체는 C #과 유사한 D의 값 유형입니다).foo()ref

NonNullable대신 D 표준 라이브러리 구조로 클래스에 대한 템플릿 을 만들 계획이 있다고 생각 합니다. 그럼에도 불구하고 나는 단지의 간결함을 좋아하는 Type&비교를 NonNullable(Type)하고, 기본 (같은 것을 렌더링과 같은 비 - 널 선호 Type하고 Nullable(Type)). 그러나 D를 변경하기에는 너무 늦었고 지금은 주제를 벗어나고 있습니다.

C ++가 D보다 "우수한"가장 중요한 것은 레거시 라이브러리와 인터페이스하는 것 입니다. 다양한 3D 엔진, OpenCL 등 D는 새로운 것이기 때문에 선택할 수있는 라이브러리 수가 훨씬 적습니다.

C ++과 D의 또 다른 중요한 차이점은 C ++에 재정적으로 독립적 인 여러 공급 업체가 있지만 2014 년 현재 D는이 를 생성 한 2 인 팀만 하나라는 점입니다. 프로젝트가 기술, 구성 요소에 의존해서는 안된다고 말하는 "두 번째 소스 원칙" 은 흥미 롭습니다 . 단일 벤더가있는 단일 구성 요소 만 소프트웨어에도 적용되는 것으로 보입니다.

비교를 위해, 첫 번째 버전의 Ruby 인터프리터는 Ruby의 발명가 인 Matsumoto Yukihiro가 작성했지만 2014 년 주류 Ruby 인터프리터는 실제로 다른 사람들이 처음부터 작성했습니다. 따라서 Ruby는 재정적으로 독립적 인 공급 업체가 둘 이상인 언어로 볼 수 있습니다. 반면 D는 멋진 기술이 될 수 있지만 기술을 개발하는 소수의 개발자에게 달려 있습니다.

Java의 역사는 기술 (이 경우 Java)이 훌륭하지만 단일 한 재정을 가지고 있더라도 거대한 회사 사용자 기반에 관계없이 기술이 본질적으로 덤프 될 위험이 크다는 것을 보여줍니다. EC가 "실행위원회" 를 나타내는 Apache Software Foundation에 대한 인용 :

Oracle은 EC에 자체 모순되는 Java SE 7 사양 요청 및 라이센스를 제공했으며, 사양의 독립적 인 구현 배포를 심각하게 제한하고, 가장 중요한 것은 사양 의 독립적 인 오픈 소스 구현의 배포를 금지합니다.

역사적으로 Java 애플릿은 HTML5 WebGL이 개발되기 몇 년 전에 하드웨어 가속 속도가 3D 캔버스 였다고 말할 수 있습니다. Java가 커뮤니티 프로젝트 인 경우 Java 애플릿 시작 속도 문제를 해결할 수 있었지만 Java의 유일한 금융인 인 Sun Microsystems의 임원은 Java 구현을 수정하기에 충분히 중요하지 않다고 생각했습니다. 최종 결과 : 여러 공급 업체의 HTML5 캔버스가 Java GUI 프레임 워크 (스윙 등)의 "빈약 한 복제본"입니다. 흥미롭게도 서버 측에서 Python 프로그래밍 언어는 Java가 약속 한 것과 동일한 장점을 가지고 있습니다. Python 응용 프로그램이 머신 코드로 컴파일되지 않은 경우 하드웨어에 관계없이 한 번 작성하고 모든 서버에서 실행합니다. 파이썬은 자바만큼이나 오래되었지만 젊지 만 자바와는 달리

요약:

생산 용도의 기술을 평가할 때 기술의 가장 중요한 속성은 기술을 개발하는 사람, 개발 과정, 개발 과정이 진행되는 사회 과정 및 재정적으로 독립적 인 개발 팀의 수입니다.

기술 T2보다 기술 T1을 사용하는 것이 더 유리한지 여부는 기술 공급 업체와 기술 T1이 T2보다 프로젝트 관련 문제를 더 싸게 해결할 수 있는지 여부에 달려 있습니다. 예를 들어 단일 공급 업체 문제를 무시한 경우 정보 시스템의 경우 Java 바이너리는 새 하드웨어에 배포 할 때 재 컴파일 할 필요가없고 메모리 관리 관련 소프트웨어 개발 작업량이 많기 때문에 C ++보다 "더 나은"기술이됩니다. Java의 경우 C ++보다 작습니다. 처음부터 개발 된 프로젝트 (예 : 다른 라이브러리에 의존하지 않는 프로젝트)는 C ++보다 D에서 개발하는 것이 더 저렴할 수 있지만, 반면에 C ++에는 공급 업체가 두 개 이상이므로 장기적으로 덜 위험합니다. . (Sun Microsystems가 거의 괜찮은 Java 예제,

일부 C ++ 제한에 대한 가능한 해결 방법

C ++의 제한 사항 중 일부에 대한 가능한 해결 방법 중 하나는 디자인 패턴을 사용하는 것입니다. 디자인 패턴을 사용하면 초기 작업이 여러 조각으로 분류되고 조각이 "분류"(분류, 클러스터, 분할, 기타 좋은 단어)됩니다. 동일 클래스)에서 2 개의 클래스로 : 메모리 액세스 패턴이 로컬 성을 허용하지 않는 로직 관련 작업 제어 ; 지역이 쉽게 달성되는 신호 처리와 유사한 작업 . 신호 처리 "유사"작업은 비교적 단순한 콘솔 프로그램 세트로 구현할 수 있습니다. 제어 로직 관련 작업은 소프트웨어 개발 편의성이 속도보다 우선 순위가 높은 루비 또는 Python으로 작성된 단일 스크립트에 모두 배치됩니다.

운영 체제 프로세스 간의 비싼 운영 체제 프로세스 초기화 및 데이터 복사를 피하기 위해 소규모 C ++ 콘솔 애플리케이션 세트는 Ruby / Python 등에서 "서블릿"으로 부팅되는 단일 C ++ 프로그램으로 구현 될 수 있습니다. 스크립트. 루비 / 파이썬 등 스크립트는 종료 전에 서블릿을 종료합니다. "서블릿"과 Ruby / Python / etc 간의 통신 스크립트는 Linux 명명 된 파이프 또는 이와 유사한 메커니즘을 통해 수행됩니다.

초기 작업이 앞서 언급 한 2 개의 클래스로 분류 될 수있는 조각으로 쉽게 나눌 수없는 경우, 초기 작업이 변경되도록 문제를 다시 문구 화하는 것이 좋습니다.