나는 항상 *.h클래스 정의에 파일을 사용 했지만 부스트 라이브러리 코드를 읽은 후에는 모두 사용한다는 것을 깨달았습니다 *.hpp. 나는 항상 그 파일 확장자에 대한 혐오감을 가지고 있었고, 주로 익숙하지 않기 때문에 주로 생각합니다.

*.hppover 를 사용할 때의 장단점은 무엇입니까 *.h?

C와 C ++ 헤더의 이름이 다른 몇 가지 이유는 다음과 같습니다.

• 자동 코드 형식화 : C 및 C ++ 코드 형식화에 대한 다른 지침이있을 수 있습니다. 헤더가 확장자로 분리 된 경우 적절한 형식을 자동으로 적용하도록 편집기를 설정할 수 있습니다
• 명명, 나는 C로 작성된 라이브러리가있는 프로젝트에 있었고 래퍼는 C ++로 구현되었습니다. 헤더의 이름은 대개 Feature.h와 Feature.hpp와 비슷하기 때문에 구분하기 쉽습니다.
• 포함, 프로젝트에 C ++로 작성된 더 적절한 버전이 있지만 C 버전을 사용하고 있습니다 (위 참조). 헤더가 구현 된 언어의 이름을 따서 명명 된 경우 모든 C 헤더를 쉽게 발견하고 C ++ 버전을 확인할 수 있습니다.

C는 C ++ 이 아니며 수행중인 작업을 모르는 경우 혼합하여 일치시키는 것이 매우 위험 할 수 있습니다. 소스 이름을 적절하게 지정하면 언어를 구별하는 데 도움이됩니다.

나는 사용자가 어떤 헤더가 C ++ 헤더인지, 어떤 헤더가 C 헤더인지 구별하기를 원하기 때문에 .hpp를 사용합니다.

이것은 프로젝트가 C 및 C ++ 모듈을 모두 사용하는 경우 중요 할 수 있습니다. 앞에서 설명한 다른 사람처럼 매우 신중하게 수행해야하며 확장을 통해 제공하는 "계약"으로 시작해야합니다.

.hpp : C ++ 헤더

(또는 .hxx 또는 .hh 등)

이 헤더는 C ++ 전용입니다.

C 모듈에 있다면 포함시키지 마십시오. C 친화적으로 만들기 위해 노력하지 않기 때문에 마음에 들지 않습니다 (함수 오버로드, 네임 스페이스 등 너무 많이 잃어 버릴 것입니다).

.h : C / C ++ 호환 또는 순수한 C 헤더

이 헤더는 C 소스와 C ++ 소스에 의해 직접 또는 간접적으로 포함될 수 있습니다.

__cplusplus매크로에 의해 보호되어 직접 포함될 수 있습니다 .

• 즉, C ++ 관점에서 C 호환 코드는로 정의됩니다 extern "C".
• C 관점에서는 모든 C 코드가 명확하게 보이지만 C ++ 코드는 숨겨집니다 (C 컴파일러에서 컴파일되지 않기 때문에).

예를 들면 다음과 같습니다.

#ifndef MY_HEADER_H
#define MY_HEADER_H

   #ifdef __cplusplus
      extern "C"
      {
   #endif

   void myCFunction() ;

   #ifdef __cplusplus
      } // extern "C"
   #endif

#endif // MY_HEADER_H

또는 extern "C"선언으로 묶는 해당 .hpp 헤더에 의해 간접적으로 포함될 수 있습니다 .

예를 들면 다음과 같습니다.

#ifndef MY_HEADER_HPP
#define MY_HEADER_HPP

extern "C"
{
#include "my_header.h"
}

#endif // MY_HEADER_HPP

과:

#ifndef MY_HEADER_H
#define MY_HEADER_H

void myCFunction() ;

#endif // MY_HEADER_H

나는 항상 .hpp헤더를 일종의 portmanteau .h및 .cpp파일로 간주했습니다 ... 구현 세부 사항을 포함하는 헤더.

일반적으로 .hpp확장명 으로 보거나 사용했을 때 해당 .cpp파일 이 없습니다 . 다른 사람들이 말했듯이 이것은 어렵고 빠른 규칙이 아니며 .hpp파일 을 사용하는 경향이 있습니다 .

사용하는 확장명은 중요하지 않습니다. 어느 쪽이든 괜찮습니다.

내가 사용하는 *.hC과 *.hppC ++에 대한.

[Dan Nissenbaum의 추가 제안] 편집 :

한 가지 규칙에 따라 .hpp 파일은 프로토 타입이 헤더 자체에 정의 될 때 사용됩니다. 컴파일러는 템플릿 인스턴스화에서만 각 유형에 대한 코드를 생성하므로 헤더의 이러한 정의는 템플릿의 경우에 유용합니다. 따라서 헤더 파일에 정의되어 있지 않으면 다른 컴파일 단위에서 링크 타임에 해당 정의가 해석되지 않습니다. 프로젝트가 템플릿을 많이 사용하는 C ++ 전용 프로젝트 인 경우이 규칙이 유용합니다.

이 규칙을 준수하는 특정 템플릿 라이브러리는 해당 .cpp 파일이 없음을 나타 내기 위해 확장명이 .hpp 인 헤더를 제공합니다.

또 다른 규칙은 C 헤더에는 .h를, C ++에는 .hpp를 사용하는 것입니다. 좋은 예는 부스트 라이브러리입니다.

Boost FAQ에서 인용,

파일 확장자는 파일의 "유형"을 사람과 컴퓨터 프로그램 모두와 통신합니다. '.h'확장자는 C 헤더 파일에 사용되므로 C ++ 헤더 파일에 대해 잘못된 내용을 전달합니다. 확장자를 사용하지 않으면 아무 것도 통신하지 않고 파일 내용을 검사하여 유형을 결정합니다. '.hpp'를 사용하면 C ++ 헤더 파일로 명확하게 식별되며 실제로 실제로 작동합니다. (레이너 데이크)

최근 *.hpp에 C ++ 헤더를 사용 하기 시작했습니다 .

그 이유는 emacs를 기본 편집기로 사용하고 *.h파일 을로드하면 자동으로 c 모드로 들어가고 파일 을로드하면 c ++ 모드로 들어가기 때문 *.hpp입니다.

그 사실 외에도 나는 그 *.h이상 을 선택 *.hpp하거나 그 반대의 이유를 알 수 없습니다 .

이 동일한 OP에 대한 "user1949346"에 대한 내 의견을 지적하기 위해이 질문에 대한 답변입니다.

많은 사람들이 이미 대답했듯이 어느 쪽이든 괜찮습니다. 자신의 인상을 강조합니다.

서론, 앞서 언급 한 언급 된 의견에서 언급했듯이, 실제로는 그 이유가 없다면 C++헤더 확장이 제안됩니다 .h.

ISO / IEC 문서는 헤더 파일의이 표기법을 사용하므로 .hpp에 대한 언어 문서에서도 문자열 일치가 발생 하지 않습니다 C++.

그러나 나는 이제 어느 쪽의 방법이 괜찮은지, 특히 그것이 왜 언어 자체의 주제가 아닌지에 대한 승인 가능한 이유를 목표로하고 있습니다.

그래서 우리는 간다.

C++설명서는 (실제로 버전 N3690에서 참조를 데려 갈거야) 헤더는 다음 구문을 준수한다는 것을 정의한다 :

2.9 헤더 이름

header-name:
    < h-char-sequence >
    " q-char-sequence "
h-char-sequence:
    h-char
    h-char-sequence h-char
h-char:
    any member of the source character set except new-line and >
q-char-sequence:
    q-char
    q-char-sequence q-char
q-char:
    any member of the source character set except new-line and "

따라서이 부분에서 추출 할 수 있으므로 헤더 파일 이름은 소스 코드에서도 유효한 것일 수 있습니다. '\n'문자 <>를 포함하지 않고 포함 여부에 따라을 포함 할 수 없습니다 >. 또는 ""-include에 포함되어 있으면를 포함 할 수 없습니다 ".

즉 prettyStupidIdea.>, 파일 이름을 지원하는 환경이 있으면 다음과 같이 포함하십시오.

#include "prettyStupidIdea.>"

유효하지만,

#include <prettyStupidIdea.>>

유효하지 않습니다. 다른 방법으로 동일합니다.

그리고 심지어

#include <<.<>

유효한 포함 가능한 헤더 파일 이름입니다.

이것조차도 C++꽤나 어리석은 생각 일 것입니다.

그리고 그것이 또한 .hpp유효한 이유 입니다.

그러나 언어에 대한 의사 결정을 디자인하는위원회의 결과는 아닙니다!

사용에 대해 논의하는 것은 그래서 .hpp약을하고와 동일 .cc, .mm또는 이제까지 그 밖의 무엇을 나는이 주제에 대한 다른 게시물에서 읽어 보시기 바랍니다.

나는 ¹ 에서 .hpp온 단서가 없다는 것을 인정해야 하지만, 일부 구문 분석 도구, IDE 또는 관련된 다른 것을 발명 한 사람 은 내부 프로세스를 최적화하거나 일부를 발명하기 위해이 아이디어를 얻었을 것입니다. ) 새로운 명명 규칙.C++

그러나 그것은 언어의 일부가 아닙니다.

그리고 이런 식으로 사용하기로 결정할 때마다. 그가 가장 좋아하기 때문에 또는 워크 플로의 일부 응용 프로그램 에서 요구하기 때문에 언어의 요구 사항은 결코 ² 가 아닙니다 . "pp는 C ++과 함께 사용되기 때문에"라고 말하는 사람은 언어 정의와 관련하여 잘못되었습니다.

C ++는 이전 단락과 관련된 모든 것을 허용합니다. 위원회가 사용하도록 제안한 것이 있으면 .hISO 문서의 모든 예에서 제기 된 확장 이므로 사용 하고 있습니다.

결론:

.h이상 을 사용 .hpp하거나 그 반대의 필요성을 보거나 느끼지 않는 한 귀찮게해서는 안됩니다. 둘 다 표준과 관련하여 동일한 품질의 유효한 헤더 이름을 형성하기 때문입니다. 그러므로 어떤 REQUIRES 당신이 사용 .h하거나 .hpp심지어는 다른 추가적인 제한과 모순 될 수있는 표준의 추가 제한입니다하지 서로 준수합니다. 그러나 OP에 추가 언어 제한이 언급되어 있지 않으므로 이것이 질문에 대한 정확하고 승인 가능한 답변입니다.

" 클래스 정의에 대한 * * * h 또는 * .hpp "는 다음과 같습니다.

외부 제한이없는 한 두 가지 모두 똑같이 정확하고 적용 가능합니다.

¹ _{내가 아는 것으로부터, 분명히 그 .hpp확장 과 함께 올라온 부스트 프레임 워크입니다 .}

² _{물론 미래의 일부 버전에 어떤 내용이 포함 될지 말할 수 없습니다!}

나는 C ++에 대해 .hpp를 선호하여 편집자와 다른 프로그래머 모두에게 C 헤더 파일이 아닌 C ++ 헤더임을 분명히합니다.

C ++ ( "C Plus Plus")는 .cpp로 의미가 있습니다.

확장자가 .hpp 인 헤더 파일은 논리 흐름이 동일하지 않습니다.

당신이 원하는대로 당신의 포함을 호출 할 수 있습니다.

에 전체 이름을 지정하면 #include됩니다.

C를 사용 .h하여 작업 하고 C ++을 사용하는 경우 사용하는 것이 좋습니다 .hpp.

그것은 결국 단지 협약입니다.

Codegear C ++ Builder는 델파이 소스 파일에서 자동 생성 된 헤더 파일에는 .hpp를 사용하고 "자신의"헤더 파일에는 .h 파일을 사용합니다.

따라서 C ++ 헤더 파일을 작성할 때 항상 .h를 사용합니다.

90 년대 초반의 작업 중 하나에서 소스 및 헤더 파일에 각각 .cc 및 .hh를 사용했습니다. 입력하는 것이 가장 쉬운 방법이기 때문에 모든 대안을 선호합니다.

Bjarne Stroustrup 및 Herb Sutter는 C ++ 핵심 지침 ( https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#S-source) 에서이 질문에 대한 설명 을 제공하며 최신 변경 사항도 참조합니다. 표준 확장 (C ++ 11, C ++ 14 등)

SF.1 : Y 프로젝트가 아직 다른 규칙을 따르지 않는 경우 코드 파일에 .cpp 접미사를 사용하고 인터페이스 파일에 .h를 사용하십시오.

오랜 전통입니다. 그러나 일관성이 더 중요하므로 프로젝트에서 다른 것을 사용하는 경우 따르십시오. 노트

이 규칙은 일반적인 사용 패턴을 반영합니다. 헤더는 일반적으로 .h를 사용하는 C ++ 및 C로 컴파일하기 위해 C와 더 자주 공유되며, 의도 된 헤더에 대해서만 다른 확장자를 사용하는 대신 모든 헤더의 이름을 .h로 지정하는 것이 더 쉽습니다. 반면에 구현 파일은 C와 거의 공유되지 않으므로 일반적으로 .c 파일과 구별해야하므로 일반적으로 모든 C ++ 구현 파일의 이름을 다른 이름 (예 : .cpp)으로 지정하는 것이 가장 좋습니다.

특정 이름 .h 및 .cpp는 필요하지 않으며 (기본값으로 권장 됨) 다른 이름이 널리 사용됩니다. 예는 .hh, .C 및 .cxx입니다. 그러한 이름을 동등하게 사용하십시오. 이 문서에서는 실제 확장자가 다를 수 있지만 .h 및 .cpp>를 헤더 및 구현 파일의 줄임말이라고합니다.

IDE (사용하는 경우)가 충분하다고 생각할 수 있습니다.

부스트와 같은 인기있는 라이브러리를 사용하는 경우 일관성이 이미 손상되어 .hpp를 더 잘 사용해야하기 때문에 나는이 규칙을 좋아하지 않습니다.

여기에서 이미 언급했듯이 템플릿 클래스 / 함수를 사용하는 헤더 전용 라이브러리에 .hpp를 사용하는 것이 좋습니다. .cpp 소스 파일 또는 공유 또는 정적 라이브러리와 함께 헤더 파일에 .h를 사용하는 것을 선호합니다.

내가 개발하는 대부분의 라이브러리는 템플릿 기반이므로 헤더 만 필요하지만 응용 프로그램을 작성할 때 선언을 구현과 분리하고 .h 및 .cpp 파일로 끝나는 경향이 있습니다.

다행히도 간단합니다.

C ++로 작업하는 경우 .hpp 확장자를 사용해야하며 C에 .h를 사용하거나 C와 C ++를 혼합해야합니다.

저는 .h를 사용합니다. 그것이 Microsoft가 사용하는 것과 코드 생성기가 생성하는 것입니다. 곡물을 거칠 필요가 없습니다.

nº1 반드시 읽어야하는 C ++ 서적 인 "Bjarne Stroustrup의 C ++ 프로그래밍 언어, 제 3 판"에서 * .h를 사용합니다. 따라서 모범 사례는 * .h를 사용하는 것입니다.

그러나 * .hpp도 좋습니다!

도구와 인간은 무언가 를 쉽게 구별 할 수 있습니다. 그게 다야.

일반적인 사용 (부스트 등) .hpp에는 특히 C ++ 헤더가 있습니다. 반면 .h에 비 C ++ 전용 헤더 (주로 C) 용입니다. 사소한 경우가 많기 때문에 컨텐츠의 언어를 정확하게 감지하는 것은 일반적으로 어렵 기 때문에 이러한 차이로 인해 즉시 사용 가능한 도구를 쉽게 작성할 수 있습니다. 인간에게는 한 번 협약을 얻은 후에도 기억하기 쉽고 사용하기 쉽습니다.

그러나 예상대로 컨벤션 자체가 항상 작동하는 것은 아닙니다.

• C 나 C ++가 아닌 언어 사양에 의해 강제되지는 않습니다 . 이 협약을 따르지 않는 많은 프로젝트가 있습니다. 일단 병합 (혼합)해야한다면 번거로울 수 있습니다.
• .hpp그 자체가 유일한 선택은 아닙니다. 왜 .hh나 .hxx? (어쨌든 파일 이름 및 경로에 대한 일반적인 규칙은 하나 이상 필요합니다.)

나는 개인적으로 .h그리고 .hpp내 C ++ 프로젝트에서 모두 사용합니다 . 위의 규칙을 따르지 않습니다.

• 프로젝트의 각 부분에서 사용되는 언어가 명시 적으로 문서화되어 있습니다. 동일한 모듈 (디렉토리)에서 C와 C ++를 혼합 할 기회가 없습니다. 모든 타사 라이브러리는이 규칙을 준수해야합니다.
• 프로젝트에 사용 된 언어 사양 및 허용 언어도 문서화되어 있습니다. (실제로, 사용 중인 표준 기능 및 버그 수정 (언어 표준)의 소스 도 문서화 합니다 .) 이는 오류가 발생하기 쉽고 테스트 비용이 많이 들기 때문에 사용 된 언어를 구별하는 것보다 다소 중요합니다 (예 : 컴파일러 호환성)은 특히 이미 거의 순수한 C ++ 에있는 프로젝트에서 상당히 복잡하고 시간 소모적 일 수 있습니다 . 이를 처리하기에는 파일 이름이 너무 약합니다.
• 동일한 C ++ 방언의 경우에도 차이에 적합한 더 중요한 속성이있을 수 있습니다. 예를 들어, 아래 규칙을 참조하십시오.
• 파일 이름은 본질적으로 취약한 메타 데이터입니다. 컨벤션 위반은 감지하기 쉽지 않습니다. 내용을 안정적으로 처리하려면 도구는 결국 이름에만 의존해서는 안됩니다. 확장의 차이점은 힌트 일뿐입니다. .hgithub.com 에서 파일의 언어 감지와 같이이를 사용하는 도구도 항상 동일하게 작동하지 않아야합니다. ( 이 소스 파일이 더 나은 메타 데이터가되기 위해 shebang 과 같은 주석에 무언가가있을 수 있지만, 파일 이름과 같이 일반적인 것은 아니므로 일반적으로 신뢰할 수 없습니다.)

나는 일반적으로 사용하는 .hppC ++ 헤더와 헤더는에 사용 (유지)해야 헤더 전용 템플릿 라이브러리로 예를 들면, 방법. 의 다른 헤더의 .h경우 해당 .cpp파일이 구현이거나 C ++이 아닌 헤더입니다. 후자는 사람에 의해 (또는 필요한 경우 명시적인 임베디드 메타 데이터가있는 도구로) 헤더의 내용을 구별하는 것이 쉽지 않습니다.

소스 파일의 확장자는 빌드 시스템에 의미가있을 수 있습니다. 예를 들어, makefile .cpp또는 .c파일에 규칙이 있거나 컴파일러 (예 : Microsoft cl.exe)가 확장자에 따라 파일을 C 또는 C ++로 컴파일 할 수 있습니다.

#include지시문에 전체 파일 이름을 제공해야 하므로 헤더 파일 확장자는 관련이 없습니다. .c텍스트가 포함되어 있기 때문에 원하는 경우 다른 소스 파일에 파일을 포함 할 수 있습니다 . 컴파일러에는 사전 처리 된 출력을 덤프하여이를 명확하게하는 옵션이있을 수 있습니다 (Microsoft : /P파일 /E로 사전 처리 stdout, 사전 처리 대상 , 지시문 /EP생략 #line, /C주석 유지)

.hppC ++ 환경에만 관련된 파일, 즉 C로 컴파일되지 않는 기능 을 사용하도록 선택할 수 있습니다 .

컴파일러, 도구 및 / 또는 도구에 다른 의미를 가질 수있는 것 외에는 특정 확장에 대한 이점이 없습니다. header.h유효한 헤더입니다. header.hpp유효한 헤더입니다. header.hh유효한 헤더입니다. header.hx유효한 헤더입니다. h.header유효한 헤더입니다. this.is.not.a.valid.header거부 된 유효한 헤더입니다. ihjkflajfajfklaf유효한 헤더입니다. 컴파일러가 이름을 올바르게 구문 분석 할 수 있고 파일 시스템이이를 지원하는 한, 유효한 헤더이며 확장의 유일한 장점은 그 이름을 읽는 것입니다.

즉, 확장명을 기반으로 정확하게 가정 할 수 있으면 매우 유용하므로 헤더 파일에 대해 이해하기 쉬운 규칙 세트를 사용하는 것이 좋습니다. 개인적으로 나는 다음과 같은 것을 선호합니다.

1. 이미 확립 된 지침이 있다면 혼동을 피하기 위해 지침을 따르십시오.
2. 프로젝트의 모든 소스 파일이 동일한 언어 용인 경우을 사용하십시오 .h. 모호함이 없습니다.
3. 일부 헤더는 여러 언어와 호환되고 다른 헤더는 단일 언어와 만 호환되는 경우 확장은 헤더와 호환되는 가장 제한적인 언어를 기반으로합니다. C와 호환되는 헤더, C와 C ++ 모두와 .h호환되는 헤더 는을 얻는 반면 C ++과 호환되지만 C는 얻지 못 .hpp하거나 .hh일종의 헤더는 얻습니다 .

물론 이것은 확장 기능을 처리 하는 많은 방법 중 하나 일 뿐이 므로 상황이 단순 해 보일지라도 첫 인상을 반드시 신뢰할 수있는 것은 아닙니다. 예를 들어, 내가 사용하는 언급 본 적이 .h정상 헤더에 대한, 그리고 .tpp만 템플릿 클래스 멤버 함수에 대한 정의를 포함하는 헤더에 대한 .h포함 템플릿 클래스를 정의하는 파일 .tpp대신의 (자신의 멤버 함수를 정의하는 파일 .h을 직접 모두를 포함하는 헤더를 함수 선언 및 정의). 또 다른 예를 들어, 많은 사람들이 모호 할 가능성이없는 경우에도 항상 확장에 헤더의 언어를 반영합니다. 그들에게 .h항상 C 헤더이고 .hpp(또는 .hh, 또는.hxx등)은 항상 C ++ 헤더입니다. 그리고 다시, 일부 사람들 .h은 "소스 파일과 관련된 헤더"와 .hpp"인라인으로 정의 된 모든 기능을 가진 헤더"에 사용합니다.

이를 고려할 때 주요 이점은 동일한 스타일로 헤더의 이름을 일관되게 지정하고 코드를 검사하는 모든 사람에게 해당 스타일을 쉽게 알 수있게하는 것입니다. 이런 식으로, 일반적인 코딩 스타일에 익숙한 사람이라면 누구나 한 번의 확장으로 원하는 것을 한 눈에 파악할 수 있습니다.