C++에 대한 모듈 개념

Question

C++은 계속 발전하는 언어이며 수년 동안 새로운 기능이 추가되고 있습니다.

C++에서 잘못 놓친 한 가지 특징은 적절한 모듈 개념입니다. 헤더 파일을 사용하는 현재 접근법 (헤더가 두 번 포함되지 않았 음을 확인하기 위해 조건문 #define을 사용하는 경우)은 확실히 불만족스러워 보입니다.

예를 들어, 우리 프로젝트에 많은 소스 파일에 "#include"가 너무 많아서 컴파일 시간이 불필요하게 길어지는 문제가 있습니다. Incredibuild를 사용하여 제품을 빌드하는 데 45 분이 걸립니다. 즉 적어도 10 개의 코어를 병렬로 사용합니다. 따라서 수동으로 파일을 정리하는 데 많은 시간을 소비해야합니다. 즉, 파일을 실제로 제거했는지 확인하기 위해 제거하는 것입니다.

가 나는

1. 것이 가능에
   명확 모듈의 구현과 인터페이스를 분리하게하는 모듈 개념이 매우 유용 할 것이라고 생각;
2. 모듈의 인터페이스와 본문을 따로 따로 컴파일합니다 (현재 .h 파일은 다른 파일에 포함될 때마다 반복해서 컴파일됩니다). 도구는 컴파일 된 인터페이스를 읽고 어떤 유형, 기능, 클래스인지 알려줍니다 수출;
3. 가져 오기를 자동으로 다시 정렬하기위한 쓰기 도구 (예 : Java/Eclipse를 사용하면 파일의 모든 가져 오기를 자동으로 다시 정렬 할 수 있음).

이러한 모듈 개념을 정의하고이를 C++에 통합하거나 너무 복잡하다고 생각할 수 있습니까? 이 방향으로 어떤 노력을했는지 알고 있습니까? 미리 컴파일 된 헤더에 관한 제안을

편집

감사합니다. 가능한 경우 시도해 보겠습니다 (Visual Studio 2008 사용). 아마도 우리는 잘못된 방식으로 헤더 파일을 사용하고있을 것입니다 (?) 우리는 각 클래스마다 하나의 헤더 파일을 사용합니다. 그런 다음 클래스 구현과 함께 cpp 파일을 만듭니다. 종종 우리는 30, 40 헤더 파일을 포함하는 cpp 파일로 끝납니다. cpp 파일을 변경하면 더 이상 필요하지 않은 일부 포함은 있지만 더 이상 필요하지 않습니다. 이것은 헤더 파일에 다른 헤더 파일이 포함되어 있다는 사실과 부분적으로 관련이 있습니다.

우리는 수입품을 재 배열하는데 너무 많은 시간을 할애하고 자동으로 이것을 할 수있는 도구가없는 것 같습니다. 그것은 우리에게 많은 시간을 절약 할 수 있습니다.

Answer 1

C++은 계속 진화하는 언어이며 새로운 기능이 C++ 0x 개발의 일부로 에 추가되었습니다.

C++ 11 표준 has already been approved 및 published이므로 더 이상 기능이 추가되지 않습니다. 적어도 몇 년 동안은 그렇지 않습니다. 확실히 불만족 (머리글 두 번 포함되지 않았는지 확인하기 위해 조건부 #define 사용) 현재 접근하여 헤더 파일 보인다 : 나는 C++로 몹시 그리워

기능 중 하나는 적절한 모듈 개념이다 나에게.

일부 컴파일러는 포함 가드를 쓰지 않아도되도록 #pragma once을 지원하지만, 알고있는 한 비표준입니다. 당신이 경비를 포함하지 할 경우가 있습니다; Boost.Preprocessor은 고의적으로 가드가없는 일부 헤더가있는 라이브러리의 예입니다.

예를 들어, 내 프로젝트에서 우리는 불필요하게 긴 컴파일 시간 을, 우리는 많은 소스 파일에 너무 많은 "의 #include"의이 문제를 가지고 우리의 제품을 구축하는 데 45 분 소요, Incredibuild를 사용합니다. 즉 최소 10 개의 코어를 병렬로 사용합니다. 따라서, 우리는 즉 그들이 정말 필요한 경우 확인이 포함 제거, 수동으로 파일을 청소 많은 시간을 낭비 할 필요가 .

Stroustrup has an FAQ entry on compile-time slowness. 헤더 파일을 포함하는 것에 관해서는 GotW article #7에서 읽으십시오. 필요한 파일보다 더 많은 파일을 포함 할 가능성이 큽니다. 예를 들어, 전달 선언을 사용하지 못하게 될 수 있습니다. 거대한 헤더 파일을 가지고 있다면 소스 파일이 실제로 필요한 선언 만 포함하도록 파일을 분할 해보십시오. 파일 구조가 빠른 컴파일에 도움이되지 않는 문제 일 수도 있습니다.

1. 명확하게 모듈 구현으로부터의 인터페이스.

여기에는 the PIMPL idiom (컴파일 방화벽이라고도 함)이 있습니다. 그리고도없이, 나는 .cpp 파일의 구현과 .h 파일의 인터페이스를 (그것이 "순수한"인터페이스 아니더라도) 퍼팅 어떤 문제가 없습니다. (다시 현재 .H 파일을 다시 컴파일하고 다른 파일에 포함 때마다) 인터페이스와 별도로 는 모듈의 몸 2.compile

: 도구는 컴파일 된 인터페이스를 읽을 수 그것이 수출하는 유형, 기능, 종류를 말해주십시오;

일부 컴파일러는 활용할 수있는 precompiled header files을 지원합니다. 자동으로 더 쉽게 수입을 재배 열하

3.write 도구.

나는이 뜻을 이해하지 못합니다.

이러한 모듈 개념을 정의 할 수 있으며 을 C++에 통합하거나 너무 복잡하다고 생각하십니까? 이 방향에서 어떤 노력을 알고 있습니까?

그들이 일하고를 rvalue 같은 다른 제안을 검토했다 (믿거 나 말거나,이 C++에 모듈 개념의 어떤 종류를 추가하는 a proposal이지만,이 시간 제약으로 인해 C++ (11)에 수용되지 않은 내 견해로는 훨씬 더 중요하다). 다음 버전 또는 C++ 표준 업데이트에 포함될 수 있습니다.

Answer 2

C++이 작동하도록 설계된 방법이 아닙니다. 헤더를 다시 파싱하는 대신 인덱스 파일을 읽을 정도로 링커를 찌르거나 찌르면 아마 그렇게 할 수 있습니다. 그러나 컴파일러는 변경되었거나 종속성이있는 파일 만 컴파일해야합니다. 게다가, 헤더는 의미있는 코드로 실제로 컴파일되지 않습니다 (일부 경우에는 맞습니다). 그것들은 링크 할 때 그 토큰이 나중에 발견 될 것이라는 컴파일러에 대한 메모 일뿐입니다.

짧은 대답 : 아니요, 가정에서 추출한 '모듈'시스템을 구현해서는 안됩니다. 헤더 파일이 잘못 사용되는 경우가 아니라면 어쨌든 헤더 파일이 영원히 사라지는 것은 아닙니다.

편집 : 누군가가 지적했듯이, 실제로는 커다란 라이브러리 나 많은 템플릿을 사용하는 경우에 실제로 컴파일 할 수있는 헤더 파일을 무시하고있었습니다. 따라서, 나는 "정말로 의심스러운 헤더 파일은 영원히 받아들이고있다"진술에 틀렸다.