[c++] 왜 cpp 파일을 포함시키지 말고 대신 헤더를 사용해야합니까?

그래서 첫 C ++ 프로그래밍 과제를 마치고 성적을 받았습니다. 그러나 등급에 따르면,에 대한 점수를 잃었습니다 including cpp files instead of compiling and linking them. 그 의미가 너무 명확하지 않습니다.

내 코드를 다시 살펴보면 클래스의 헤더 파일을 만들지 않고 cpp 파일의 모든 것을 수행했습니다 (헤더 파일이 없으면 정상적으로 작동하는 것 같습니다 …). 나는 채점자가 ‘#include “mycppfile.cpp”; 내 파일 중 일부에서.

#includecpp 파일에 대한 내 추론 은 다음과 같습니다.-헤더 파일에 들어가야 할 모든 것이 내 cpp 파일에 있었으므로 헤더 파일과 같은 척했습니다-monkey-see-monkey do fashion에서 다른 헤더 파일은 파일에 있었 #include으므로 cpp 파일에 대해서도 동일하게 수행했습니다.

정확히 내가 뭘 잘못했는지, 왜 나쁜가요?



답변

내가 아는 한, C ++ 표준은 헤더 파일과 소스 파일의 차이를 모른다. 언어와 관련하여 법률 코드가있는 텍스트 파일은 다른 텍스트 파일과 동일합니다. 그러나 불법은 아니지만 소스 파일을 프로그램에 포함 시키면 소스 파일을 처음부터 분리 할 때 얻을 수있는 이점이 거의 사라집니다.

기본적으로, 어떤 #include않는 것은 말할이다 처리기를 사용하면 지정한 전체 파일을 위해, 그리고 전에 활성 파일에 복사 컴파일러는 거기에 자신의 손을 가져옵니다. 따라서 프로젝트에 모든 소스 파일을 함께 포함 시키면 기본적으로 수행 한 작업과 아무런 차이없이 하나의 거대한 소스 파일을 만드는 것 사이에는 차이가 없습니다.

“아, 그건 별거 아니.이 실행되면, 그것의 벌금,” 나는 당신이 우는 소리. 그리고 어떤 의미에서는 당신이 맞을 것입니다. 그러나 지금 당신은 작고 작은 프로그램, 그리고 당신을 위해 그것을 컴파일하는 훌륭하고 상대적으로 방해가되지 않는 CPU를 다루고 있습니다. 항상 운이 좋은 것은 아닙니다.

만약 당신이 심각한 컴퓨터 프로그래밍의 영역을 탐구한다면, 수십 개가 아닌 수백만 개에 달하는 라인 수를 가진 프로젝트를 보게 될 것이다. 그것은 많은 줄입니다. 최신 데스크톱 컴퓨터에서이 중 하나를 컴파일하려고하면 몇 초가 아닌 몇 시간이 걸릴 수 있습니다.

“아뇨! 끔찍하게 들리지만이 무서운 운명을 막을 수 있을까요?” 불행히도, 당신이 그것에 대해 할 수있는 일은 많지 않습니다. 컴파일하는 데 몇 시간이 걸리면 컴파일하는 데 몇 시간이 걸립니다. 그러나 처음에는 문제가되지 않습니다. 일단 컴파일 한 후에는 다시 컴파일 할 이유가 없습니다.

당신이 뭔가를 변경하지 않는 한.

이제 2 백만 줄의 코드가 하나의 거대한 거 대형으로 합쳐져서 간단한 버그 수정 (예 :)을해야한다면 x = y + 1,이를 테스트하기 위해 2 백만 줄을 다시 컴파일해야합니다. 그리고 x = y - 1대신 당신이 대신 할 것을 알게되면 다시 2 백만 줄의 컴파일이 당신을 기다리고 있습니다. 다른 일을하는 데 더 많은 시간을 할애하는 데 많은 시간이 낭비되었습니다.

“그러나 나는 비생산적인 것을 싫어한다. 만약 내 코드베이스의 다른 부분을 개별적 으로 컴파일 할 수 있는 방법 만 있다면 나중에 어떻게 든 서로 연결 시킬 수있다.” 이론적으로는 훌륭한 아이디어입니다. 그러나 프로그램이 다른 파일에서 무슨 일이 일어나고 있는지 알고 싶다면 어떻게해야합니까? 여러 개의 작은 .exe 파일을 대신 실행하지 않으면 코드베이스를 완전히 분리 할 수 ​​없습니다.

“그러나 반드시 가능해야한다! 그렇지 않으면 프로그래밍은 순수한 고문처럼 들린다! 그렇지 않으면 인터페이스와 구현 을 분리하는 방법을 찾았다면 어떻게해야 할까?이 고유 한 코드 세그먼트에서 충분한 정보를 취해 나머지 프로그램을 식별하여 말하십시오. 그들에게 일종의 헤더 대신 파일? 그리고 그런 식으로, 내가 사용할 수있는 #include 처리기 지시문을 컴파일하는 데 필요한 정보 만 가져올에! “

흠. 거기에 뭔가있을 수 있습니다. 그것이 당신에게 어떻게 효과가 있는지 알려주세요.


답변

이것은 아마도 당신이 원했던 것보다 더 자세한 대답 일 것입니다.하지만 괜찮은 설명이 정당하다고 생각합니다.

C 및 C ++에서 하나의 소스 파일은 하나의 변환 단위 로 정의됩니다. . 규칙에 따라 헤더 파일에는 함수 선언, 유형 정의 및 클래스 정의가 있습니다. 실제 함수 구현은 변환 단위 (예 : .cpp 파일)에 있습니다.

이것의 배후에는 함수와 클래스 / 구조체 멤버 함수가 한 번 컴파일되고 조립 된 다음 다른 함수가 복제하지 않고 한 곳에서 해당 코드를 호출 할 수 있다는 것입니다. 함수는 암시 적으로 “extern”으로 선언됩니다.

/* Function declaration, usually found in headers. */
/* Implicitly 'extern', i.e the symbol is visible everywhere, not just locally.*/
int add(int, int);

/* function body, or function definition. */
int add(int a, int b)
{
   return a + b;
}

번역 단위에 대해 함수가 로컬이되도록하려면 해당 함수를 ‘정적’으로 정의하십시오. 이것은 무엇을 의미 하는가? extern 함수가있는 소스 파일을 포함하면 컴파일러에서 동일한 구현을 두 번 이상 수행하므로 재정의 오류가 발생합니다. 따라서 모든 변환 단위가 함수 선언 을 볼 수 있지만 함수 본문 은 볼 수 없습니다 .

그러면 결국 모든 것이 어떻게 뭉개 집니까? 그것이 링커의 직업입니다. 링커는 어셈블러 단계에서 생성 된 모든 객체 파일을 읽고 심볼을 확인합니다. 앞에서 말했듯이 기호는 이름 일뿐입니다. 예를 들어 변수 또는 함수의 이름입니다. 함수를 호출하거나 형식을 선언하는 변환 단위가 해당 함수 또는 형식에 대한 구현을 알지 못하는 경우 해당 기호를 확인할 수 없습니다. 링커는 정의되지 않은 기호를 보유하는 변환 단위와 구현이 포함 된 변환 단위를 연결하여 해결되지 않은 기호를 해결합니다. 휴 이것은 코드에서 구현되거나 추가 라이브러리에서 제공되는지 여부에 관계없이 외부에서 볼 수있는 모든 심볼에 적용됩니다. 라이브러리는 실제로 재사용 가능한 코드가있는 아카이브입니다.

두 가지 주목할만한 예외가 있습니다. 먼저 작은 기능이 있으면 인라인으로 만들 수 있습니다. 이는 생성 된 기계 코드가 extern 함수 호출을 생성하지 않지만 문자 그대로 그 자리에 연결되어 있음을 의미합니다. 일반적으로 크기가 작기 때문에 크기 오버 헤드는 중요하지 않습니다. 그들이 작동하는 방식에 정적 인 것으로 상상할 수 있습니다. 따라서 헤더에 인라인 함수를 구현하는 것이 안전합니다. 클래스 또는 구조체 정의 내부의 함수 구현은 종종 컴파일러에 의해 자동으로 인라인됩니다.

다른 예외는 템플릿입니다. 컴파일러는 인스턴스화 할 때 전체 템플릿 유형 정의를 볼 필요가 있으므로 독립형 함수 또는 일반 클래스와 같이 정의에서 구현을 분리 할 수 ​​없습니다. 아마도 이것이 가능할 수도 있지만 “export”키워드에 대한 광범위한 컴파일러 지원을 얻는 데 오랜 시간이 걸렸습니다. 따라서 ‘내보내기’를 지원하지 않으면 번역 단위는 인라인 함수 작동 방식과 유사한 인스턴스화 된 템플릿 유형 및 함수의 로컬 사본을 가져옵니다. ‘내보내기’를 지원하는 경우에는 그렇지 않습니다.

두 예외를 제외하고 일부 사람들은 인라인 함수, 템플릿 함수 및 템플릿 형식의 구현을 .cpp 파일에 넣은 다음 “.cpp 파일을 #include”하는 것이 “더 낫습니다”. 이것이 헤더인지 소스 파일인지는 중요하지 않습니다. 전처리 기는 상관하지 않으며 단지 규칙 일뿐입니다.

C ++ 코드 (여러 파일)에서 최종 실행 파일까지 전체 프로세스를 간략히 요약합니다.

  • 전처리 는 ‘#’로 시작하는 모든 지시를 구문 분석하는 실행됩니다. 예를 들어 #include 지시문은 포함 된 파일을 열등하게 연결합니다. 또한 매크로 대체 및 토큰 붙여 넣기도 수행합니다.
  • 실제 컴파일러 는 전 처리기 단계 후에 중간 텍스트 파일에서 실행되며 어셈블러 코드를 생성합니다.
  • 어셈블러 어셈블리 파일 및 방출한다 기계 코드에서 실행, 이것은 보통이라고 오브젝트 파일 문제의 수술 시스템의 바이너리 실행 형식을 따릅니다. 예를 들어 Windows는 PE (portable executable format)를 사용하는 반면 Linux는 GNU 확장명을 가진 Unix System V ELF 형식을 사용합니다. 이 단계에서 기호는 여전히 정의되지 않은 것으로 표시됩니다.
  • 마지막으로 링커 가 실행됩니다. 모든 이전 단계는 각 번역 단위에서 순서대로 실행되었습니다. 그러나 링커 스테이지는 어셈블러에서 생성 된 모든 생성 된 오브젝트 파일에서 작동합니다. 링커는 심볼을 확인하고 대상 플랫폼과 이진 형식에 따라 섹션과 세그먼트를 만드는 것과 같은 많은 마술을 수행합니다. 프로그래머는 이것을 일반적으로 알 필요는 없지만 어떤 경우에는 반드시 도움이됩니다.

다시 말하지만, 이것은 당신이 요구 한 것보다 훨씬 많았지 만, 딱딱한 세부 사항이 더 큰 그림을 보는 데 도움이되기를 바랍니다.


답변

일반적인 해결책은 .h선언 .cpp용 파일과 구현 용 파일을 사용하는 것입니다. 구현을 재사용해야하는 경우 필요한 클래스 / 함수 / 무엇이 사용되는지 .h파일에 해당 파일을 포함하고 .cpp이미 컴파일 된 .cpp파일 ( .obj일반적으로 하나의 프로젝트 내에서 사용되는 파일 또는 일반적으로 사용되는 파일) 과 링크 여러 프로젝트에서 재사용하기 위해). 이렇게하면 구현 만 변경되는 경우 모든 것을 다시 컴파일 할 필요가 없습니다.


답변

cpp 파일을 블랙 박스로, .h 파일을 블랙 박스 사용법에 대한 안내서로 생각하십시오.

cpp 파일은 미리 컴파일 할 수 있습니다. 컴파일 할 때마다 코드를 프로그램에 실제로 “포함”해야하므로 #include에서 작동하지 않습니다. 헤더 만 포함하면 헤더 파일을 사용하여 사전 컴파일 된 cpp 파일 사용 방법을 결정할 수 있습니다.

비록 이것이 첫 번째 프로젝트에서 큰 차이를 만들지는 않지만 큰 cpp 프로그램을 작성하기 시작하면 컴파일 시간이 폭발하기 때문에 사람들이 당신을 미워할 것입니다.

이 내용도 읽어보십시오 : 헤더 파일 포함 패턴


답변

헤더 파일은 일반적으로 함수 / 클래스 선언을 포함하고 .cpp 파일은 실제 구현을 포함합니다. 컴파일시 각 .cpp 파일은 개체 파일 (일반적으로 확장자 .o)로 컴파일되고 링커는 다양한 개체 파일을 최종 실행 파일로 결합합니다. 연결 프로세스는 일반적으로 컴파일보다 훨씬 빠릅니다.

이 분리의 이점 : 프로젝트에서 .cpp 파일 중 하나를 다시 컴파일하는 경우 다른 모든 파일을 다시 컴파일 할 필요가 없습니다. 해당 특정 .cpp 파일에 대한 새 개체 파일 만 만들면됩니다. 컴파일러는 다른 .cpp 파일을 볼 필요가 없습니다. 그러나 다른 .cpp 파일에서 구현 된 현재 .cpp 파일에서 함수를 호출하려면 컴파일러에게 어떤 인수를 취해야하는지 알려야합니다. 그것이 헤더 파일을 포함시키는 목적입니다.

단점 : 주어진 .cpp 파일을 컴파일 할 때 컴파일러는 다른 .cpp 파일 안에있는 내용을 ‘볼’수 없습니다. 따라서 기능이 어떻게 구현되는지 알 수 없으므로 결과적으로 적극적으로 최적화 할 수 없습니다. 그러나 나는 당신이 아직 그것에 대해 걱정할 필요가 없다고 생각합니다 (:


답변

헤더 만 포함되고 cpp 파일 만 컴파일된다는 기본 아이디어. 이것은 많은 cpp 파일이 있으면 더 유용하며, 하나만 수정하면 전체 응용 프로그램을 다시 컴파일하는 것이 너무 느려집니다. 또는 파일의 기능이 서로에 따라 시작될 때. 따라서 클래스 선언을 헤더 파일로 분리하고, cpp 파일로 구현을 유지하고, cpp 파일을 컴파일하고 결과 오브젝트 파일을 프로그램에 링크하기 위해 Makefile (또는 사용중인 도구에 따라 다른 것)을 작성해야합니다.


답변

프로그램의 다른 여러 파일에 cpp 파일을 #include하면 컴파일러가 cpp 파일을 여러 번 컴파일하려고 시도하고 동일한 메소드가 여러 번 구현되므로 오류가 발생합니다.

#include cpp 파일을 편집하면 컴파일 시간이 길어지고 (대규모 프로젝트에서 문제가 됨) 파일을 포함한 모든 파일을 다시 컴파일해야합니다.

선언을 헤더 파일에 넣고 실제로 코드 자체를 생성하지 않기 때문에 선언하면 해당 링커가 해당 cpp 코드와 선언을 연결합니다 (한 번만 컴파일 됨).