C ++ 모듈-왜 C ++ 0x에서 제거 되었습니까? 나중에 다시 올까요?


110

방금 C ++ 0x의 모듈에 대한 이 오래된 C ++ 0x 초안을 발견했습니다 .

아이디어는 컴파일 중에 모듈 파일을 생성 한 다음 다른 .cpp 파일에서 사용되는 .cpp 파일 만 작성하여 현재 .h / .cpp 시스템에서 벗어나는 것이 었습니다.

이것은 정말 훌륭한 기능처럼 보입니다.

하지만 내 질문은 : 왜 C ++ 0x에서 제거 했습니까? 기술적 인 문제가 너무 많았나요? 시간 부족? 그리고 그들이 C ++의 ulterior 버전을 위해 작업하는 것을 고려할 것이라고 생각합니까?

답변:


70

로부터 C ++ 진화 (2008 년 이후 샌프란시스코)의 주 , 모듈 제안은 다음과 같이 분류했다 "별도의 TR에 대한 제목"

이 주제는 게시되기 전에 C ++ 0x 이후 다른 표준을 기다리기에는 너무 중요한 것으로 간주되지만 다음 표준에 맞춰 마무리 되기에는 너무 실험적입니다. 따라서 이러한 기능은 가능한 한 빨리 기술 보고서를 통해 제공됩니다.

모듈 제안은 준비가되지 않았고 기다리는 것이 C ++ 0x 표준 완료를 지연 시켰을 것입니다. 실제로 제거되지 않았고 작업 문서에 통합되지 않았습니다.


89

C ++ 모듈 초안 (C ++ 17 이후의 기술 사양)

WG21 은 open-std.org에 C / C ++ 모듈 사양에 대한 초안과 몇 가지 업데이트 된 개정판을 게시했습니다 . 여기에서는 최신 문서에만 연결하겠습니다.

  • Working Draft, Extensions to C ++ for Modules N4610 (2016 년 10 월).
  • 네 번째 개정판은 P0142R0 (2016 년 3 월) 으로 게시되었습니다 .
  • P0143R2 (2016 년 3 월) 로 게시 된 모듈에 대한 문구 .
  • clang 팀은 변경 사항의 두 번째 개정판 인 P0273R1 (2016 년 10 월) 을 게시했습니다 .

다음 블로그 게시물에는 표준 회의 요약과 특히 모듈 초안의 현재 상태에 대한 요약이 포함되어 있습니다.

업데이트 : 위에서 링크 한 Kona 여행 보고서에 설명 된대로 현재 두 개의 경쟁 제안이 있습니다. 하나는 Microsoft에서 제공하고 하나는 Clang에서 제공합니다. Microsoft에서 제안한 솔루션은 매크로 내보내기를 허용하지 않지만 Clang 팀의 솔루션은 매크로 내보내기를 지원합니다. 지금까지 Microsoft만이 모듈 사양에 대한 초안을 공식적으로 제출했습니다.

Microsoft에서 제안한 모듈 사양

다음은이 제안에 포함 된 가장 중요한 개념에 대한 간략한 개요입니다. 초안이므로 여전히 변경 될 수 있습니다. 새로운 모듈 표준은 무엇보다도 다음으로 구성됩니다.

module키워드가 모듈을 선언하고, 여러 파일을 하나 개의 모듈을 구축하려면이 옵션을 선언 할 수 있습니다 (그러나 각 모듈에 대해 하나의 컴파일 단위는 포함 할 수있는 export {}섹션) :

module M;

import수입 모듈 키워드 대신 import그것은 또한 사용하기로 결정 수 있습니다 using module새로운 수입 키워드를 피할 수 있도록, 대신.

import std.io;
import module.submodule;

이 모듈의 일부인 export공용 선언 을 정의 하는 구문, 모듈의 일부로 내보내서는 안되는 비 인터페이스 선언 은 내보내기 블록 외부에서 정의됩니다. 선언 은 C / C ++에서 모든 종류의 선언이 될 수 있습니다. 즉, 함수뿐만 아니라 변수, 구조체, 템플릿, 네임 스페이스 및 클래스도 가능합니다.

export {
    int f(int);
    double g(double, int);

    int foo;

    namespace Calc {
         int add(int a, int b);
    }        
}

void not_exported_function(char* foo);

모듈의 중요한 변경 사항은 매크로 및 전 처리기 정의가 모듈에 국한되어 내보내지지 않는다는 것입니다. 따라서 매크로는 가져온 모듈에 영향을주지 않습니다.

#define FILE "my/file"
import std.io;   //will not be impacted by the above definition

현재의 전 처리기 시스템과 모듈이 공존 할 수 있으며 예를 들어 매크로를 포함하기 위해 헤더를 계속 사용할 수 있습니다.

자세한 내용은 초안을 읽는 것이 좋습니다.

Clang 모듈

Clang은 clang 모듈 페이지 에서 찾을 수있는 모듈 구현을 작업하고 있습니다 . 그러나 clang은 현재 모듈에 대한 구체적인 구문을 구현하지 않습니다. 즉, 위에서 언급 한 구문 중 어느 것도 Clang에 의해 구현되지 않았습니다. 이를 설명하기 위해 페이지에는 다음 내용이 포함되어 있습니다.

현재 임포트 선언을위한 C 또는 C ++ 구문이 없습니다. Clang은 C ++위원회에서 모듈 제안을 추적합니다. 오늘 모듈을 가져 오는 방법을 보려면 가져 오기로 포함 섹션을 참조하십시오.

현재 Clang에 의해 구현 된 주요 부분은 여전히 ​​헤더 파일을 사용하는 기존 코드에 대한 모듈 맵을 작성할 수있는 "모듈 맵 언어"입니다.

모듈에서 매크로 내보내기

위에서 언급했듯이 매크로 내보내기가 최종 모듈 TS의 일부가 될지 여부는 여전히 불분명합니다 . 에서 P0273R1 다음 구문 매크로의 수출을 위해 제안되었다 :

#export define MAX(A,B) ((A) > (B)) ? (A) : (B);

2
2018 년 Rapperswil 업데이트, Gabriel dos Reis와 Richard Smith, p1103r0의 병합 된 제안이 있습니다. botondballo.wordpress.com/2018/06/20/…
Dwayne Robinson

32

Clang은 표준화가 완료되기 전에 모듈 작업을 시작하는 최초의 컴파일러입니다. 아직 문서는 많지 않지만 예제 코드는 http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/ 에서 찾을 수 있습니다.

Douglas Gregor (개발자)의 의견 :
http://clang-developers.42468.n3.nabble.com/C-modules-td3619936.html

이론적으로는 begin_module, end_module, import_module과 같은 많은 도우미 매크로를 정의하여 향후 구문에 대한 변경 가능성을 방지 할 수 있습니다.

편집 1 :
Douglas Gregor는 자신의 구현에 대한 프레젠테이션을 발표했습니다.
http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf?=submit

편집 2 :
clang의 모듈 지원은 http://clang.llvm.org/docs/Modules.html 에 문서화되었습니다.

편집 3 :
모듈은 이제 Microsoft의 C ++ 컴파일러에서도 지원됩니다 : http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1. aspx


-39
  1. 매우 큰 개념적 변화이기 때문입니다.
  2. 소스를 h / cpp로 분리하면 실제로 필요하지 않습니다.
  3. C ++는 실제 "모듈"라이브러리가 빌드되는 방식을 정의하지 않기 때문입니다. 컴파일러 개발자와 링커에게 맡깁니다.
  4. "모듈"은 때때로 상당히 플랫폼에 의존적입니다. 예를 들어 DLL은 공유 객체와 매우 다릅니다. 따라서 이러한 개념을 병합하는 것은 그리 간단하지 않습니다.

78
확실히 필요합니다. .h / .cpp는 엄청나게 나쁘고 오래된 해결 방법입니다. 모듈 시스템은 큰 변화가 될 것이지만 표준위원회가 분명히 중요하다고 생각하는 시스템입니다.
jalf 2010-08-29

13
헤더 빌드 모델은 솔루션이 아니라 모듈이 해결하려는 문제 입니다. 또한 모듈은 DLL / SO를 대체하지 않습니다.
bames53

5
이것은 잘못된 것입니다. 1. 모듈 제안은 기존 헤더 시스템과의 하위 호환성을 보장하기 위해 세심한주의를 기울여서 향후 모듈이 도입 될 때 중단되지 않습니다. 2. 헤더 모듈의 컴파일 시간 복잡도를 O (M * N) 복잡도에서 O (M + N) 으로 줄여야 할 필요성 은 매우 잘 설명되어 있습니다. 3. 모듈 표준은 모듈이 컴파일되고 링크되는 방법을 지시하지 않지만 모듈의 비공개 API와 공개 API를 구분하기 위해 명확한 의미를 추가합니다. 4. DLL 또는 공유 객체의 이진 형식은 표준의 영향을받지 않습니다.
lanoxx

3
"h / cpp에 대한 소스 분리가 작업을 수행하므로 실제로 필요하지 않습니다."주입 된 손가락에서 체인 톱질도 수행되지만 문제가되지 않는다는 의미는 아닙니다! .NET 또는 다른 최신 lang을 살펴보면 실제로 표시되거나 올바르게 빌드 될 수 있도록 특정 방식으로 주문해야하는 것은 없어야하는 엄청난 부담입니다.
paulm
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.