.h 파일에는 무엇을 넣어야합니까?

.h 파일에는 무엇을 넣어야합니까?

---

코드를 여러 파일로 나눌 때 정확히 .h 파일에 들어가야하는 것과 .cpp 파일에 들어가야하는 것은 무엇입니까?

---

헤더 파일 ( .h)은 여러 파일에 필요한 정보를 제공하도록 설계되었습니다. 클래스 선언, 함수 프로토 타입 및 열거와 같은 것은 일반적으로 헤더 파일에 들어갑니다. 한마디로 "정의".

코드 파일 ( .cpp)은 하나의 파일에서만 알아야하는 구현 정보를 제공하도록 설계되었습니다. 일반적으로 다른 모듈에서 액세스해야하거나 절대로 액세스하지 않을 함수 본문 및 내부 변수는 .cpp파일에 속합니다 . 한마디로 "구현".

자신에게 무엇이 속하는지 스스로에게 물어 보는 가장 간단한 질문은 "이것을 변경하면 다시 컴파일되도록 다른 파일의 코드를 변경해야합니까?"입니다. 대답이 "예"이면 헤더 파일에있을 수 있습니다. 대답이 "아니오"이면 아마도 코드 파일에있을 것입니다.

---

사실, C ++에서 이것은 C 헤더 / 소스 조직보다 다소 복잡합니다.

컴파일러는 무엇을 봅니까?

컴파일러는 헤더가 제대로 포함 된 하나의 큰 소스 (.cpp) 파일을 봅니다. 소스 파일은 개체 파일로 컴파일되는 컴파일 단위입니다.

그렇다면 헤더가 필요한 이유는 무엇입니까?

한 컴파일 단위에 다른 컴파일 단위의 구현에 대한 정보가 필요할 수 있기 때문입니다. 예를 들어 한 소스에서 함수의 구현을 작성하고이를 사용해야하는 다른 소스에서이 함수의 선언을 작성할 수 있습니다.

이 경우 동일한 정보의 사본이 두 개 있습니다. 어느 것이 악 ...

해결책은 몇 가지 세부 사항을 공유하는 것입니다. 구현은 소스에 남아 있어야하지만 함수와 같은 공유 기호의 선언이나 구조, 클래스, 열거 형 등의 정의는 공유해야 할 수 있습니다.

헤더는 공유 된 세부 정보를 입력하는 데 사용됩니다.

여러 소스간에 공유해야하는 항목의 선언을 헤더로 이동

더 이상은 없나요?

C ++에는 공유가 필요하기 때문에 헤더에 넣을 수있는 다른 것들이 있습니다.

• 인라인 코드
• 템플릿
• 상수 (일반적으로 스위치 내부에서 사용하려는 것 ...)

공유 구현을 포함하여 공유해야 할 모든 것을 헤더로 이동

그러면 헤더 내부에 소스가있을 수 있다는 의미입니까?

예. 사실, "헤더"안에있을 수있는 많은 다른 것들이 있습니다 (즉, 소스간에 공유 됨).

• 앞으로 선언
• 함수 / 구조체 / 클래스 / 템플릿의 선언 / 정의
• 인라인 및 템플릿 코드 구현

복잡해지고 어떤 경우에는 (심볼 간의 순환 종속성) 하나의 헤더에 보관할 수 없습니다.

헤더는 세 부분으로 나눌 수 있습니다.

즉, 극단적 인 경우 다음을 수행 할 수 있습니다.

• 전방 선언 헤더
• 선언 / 정의 헤더
• 구현 헤더
• 구현 소스

템플릿 MyObject가 있다고 가정 해 봅시다. 우리는 다음을 가질 수 있습니다.

// - - - - MyObject_forward.hpp - - - - 
// This header is included by the code which need to know MyObject
// does exist, but nothing more.
template<typename T>
class MyObject ;

.

// - - - - MyObject_declaration.hpp - - - - 
// This header is included by the code which need to know how
// MyObject is defined, but nothing more.
#include <MyObject_forward.hpp>

template<typename T>
class MyObject
{
   public :
      MyObject() ;
   // Etc.
} ;

void doSomething() ;

.

// - - - - MyObject_implementation.hpp - - - - 
// This header is included by the code which need to see
// the implementation of the methods/functions of MyObject,
// but nothing more.
#include <MyObject_declaration.hpp>

template<typename T>
MyObject<T>::MyObject()
{
   doSomething() ;
}

// etc.

.

// - - - - MyObject_source.cpp - - - - 
// This source will have implementation that does not need to
// be shared, which, for templated code, usually means nothing...
#include <MyObject_implementation.hpp>

void doSomething()
{
   // etc.
} ;

// etc.

와!

In the "real life", it is usually less complicated. Most code will have only a simple header/source organisation, with some inlined code in the source.

But in other cases (templated objects knowing each others), I had to have for each object separate declaration and implementation headers, with an empty source including those headers just to help me see some compilation errors.

Another reason to break down headers into separate headers could be to speed up the compilation, limiting the quantity of symbols parsed to the strict necessary, and avoiding unecessary recompilation of a source who cares only for the forward declaration when an inline method implementation changed.

Conclusion

You should make your code organization both as simple as possible, and as modular as possible. Put as much as possible in the source file. Only expose in headers what needs to be shared.

But the day you'll have circular dependancies between templated objects, don't be surprised if your code organization becomes somewhat more "interesting" that the plain header/source organization...

^_^

---

in addition to all other answers, i will tell you what you DON'T place in a header file:
using declaration (the most common being using namespace std;) should not appear in a header file because they pollute the namespace of the source file in which it is included.

---

What compiles into nothing (zero binary footprint) goes into header file.

Variables do not compile into nothing, but type declarations do (coz they only describe how variables behave).

functions do not, but inline functions do (or macros), because they produce code only where called.

templates are not code, they are only a recipe for creating code. so they also go in h files.

---

In general, you put declarations in the header file and definitions in the implementation (.cpp) file. The exception to this is templates, where the definition must also go in the header.

This question and ones similar to it has been asked frequently on SO - see Why have header files and .cpp files in C++? and C++ Header Files, Code Separation for example.

---

Your class and function declarations plus the documentation, and the definitions for inline functions/methods (although some prefer to put them in separate .inl files).

---

Mainly header file contain class skeleton or declaration (does not change frequently)

and cpp file contains class implementation (changes frequently).

---

the header file (.h) should be for declarations of classes, structs and its methods, prototypes, etc. The implementation of those objects are made in cpp.

in .h

    class Foo {
    int j;

    Foo();
    Foo(int)
    void DoSomething();
}

---

I'd expect to see:

• declarations
• comments
• definitions marked inline
• templates

the really answer though is what not to put in:

• definitons (can lead to things being multiply defined)
• using declarations/directives (forces them on anyone including your header, can cause nameclashes)

---

The header Defines something but doesn't tell anything about the implementation. ( Excluding Templates in this "metafore".

With that said, you need to divide "definitions" into sub-groups, there are, in this case, two types of definitions.

• You define the "layout" of your strucutre, telling only as much as is needed by the surrounding usage groups.
• The definitions of a variable, function and a class.

Now, I am of course talking about the first subgroup.

The header is there to define the layout of your structure in order to help the rest of the software use the implementation. You might want to see it as an "abstraction" of your implementation, which is vaughly said but, I think it suits quite well in this case.

As previous posters have said and shown you declare private and public usage areas and their headers, this also includes private and public variables. Now, I don't want to go into design of the code here but, you might want to consider what you put in your headers, since that is the Layer between the end user and the implementation.

---

• Header files - shouldn't change during development too often -> you should think, and write them at once (in ideal case)
• Source files - changes during implementation

---

Header (.h)

• Macros and includes needed for the interfaces (as few as possible)
• The declaration of the functions and classes
• Documentation of the interface
• Declaration of inline functions/methods, if any
• extern to global variables (if any)

Body (.cpp)

• Rest of macros and includes
• Include the header of the module
• Definition of functions and methods
• Global variables (if any)

As a rule of thumb, you put the "shared" part of the module on the .h (the part that other modules needs to be able to see) and the "not shared" part on the .cpp

PD: Yes, I've included global variables. I've used them some times and it's important not to define them on the headers, or you'll get a lot of modules, each defining its own variable.

EDIT: Modified after the comment of David

참고URL : https://stackoverflow.com/questions/1945846/what-should-go-into-an-h-file