이것은 아마도 당신이 원했던 것보다 더 자세한 대답 일 것입니다.하지만 괜찮은 설명이 정당하다고 생각합니다.
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 형식을 사용합니다. 이 단계에서 기호는 여전히 정의되지 않은 것으로 표시됩니다.
- 마지막으로 링커 가 실행됩니다. 모든 이전 단계는 각 번역 단위에서 순서대로 실행되었습니다. 그러나 링커 스테이지는 어셈블러에서 생성 된 모든 생성 된 오브젝트 파일에서 작동합니다. 링커는 심볼을 확인하고 대상 플랫폼과 이진 형식에 따라 섹션과 세그먼트를 만드는 것과 같은 많은 마술을 수행합니다. 프로그래머는 이것을 일반적으로 알 필요는 없지만 어떤 경우에는 반드시 도움이됩니다.
다시 말하지만, 이것은 당신이 요구 한 것보다 훨씬 많았지 만, 딱딱한 세부 사항이 더 큰 그림을 보는 데 도움이되기를 바랍니다.