15. 소스 파일과 프로그램

15.1 분할 컴파일

• 파일은 전통적인 저장 단위이자, 컴파일 단위이다.

• 컴파일 단위가 하나의 파일인 경우, 해당 파일이나 해당 파일이 의존하는 무언가(아무리 조그맣더라도)에 하나라도 변경이 가해지면 파일 전체가 재컴파일돼야 한다. -> 프로그램 규모가 커진다면, 이러한 연관성을 판단하기가 어려워진다.

• 사용자는 소스 파일 (source file) 을 컴파일러에 제출한다. 그러면 해당 파일 전체가 전처리기에 의해 전처리된다. -> 매크로 처리가 진행되고, #include 지시자는 헤더를 가져온다. -> 전처기의 결과는 translation unit 으로 불리며, 해당 단위가 컴파일러의 작업 대상이자 C++ 언어 규칙에 의해서 기술되는 것이다.

• 링커는 별도로 컴파일 된 부분들을 함께 묶어주는 프로그램이다. -> 링커 작업은 프로그램이 시작되기 전에 완전히 끝날 수도 있고, 나중에 새로운 코드가 실행 중인 프로그램에 추가될 수 있다. (동적 링크)

15.2 링크 관계

• file2.cpp g() 에 의해 사용되는 x 와 f() 는 file1.cpp 에서 정의된 것이다. 키워드 extern 은 file2.cpp 에 있는 x 의 선언이 선언일 뿐 정의가 아니라는 점을 나타낸다. -> x가 초기화 됐다면, 초기화 식을 가진 선언은 항상 정의의기 때문에, extern 은 무시되고 말 것이다. -> 개체는 프로그램에서 정확히 한 번 정의되어야 한다.

// file1.cpp
int x = 1;
int f() {};

// file2.cpp
extern int x;
int f();
void g() {x = f();}

• 아래 코드는 다음과 같이 3개의 오류가 있다.

  • x는 두번 정의 되었다.

  • b는 다른 타입으로 두번 선언되었다.

  • c는 두번 선언되었지만 정의되지 않았다.

• 위와 같은 오류들은 단 하나의 파일만 살펴보는 컴파일러에 의해 탐지될 수 없다.

• 하지만 링커는 위 3가지 오류를 탐지할 수 있다.

// file1.cpp 
int x = 1;
int b = 1;
extern int c;

// file2.cpp
int x;
extern double b;
extern int c; 

• 네임스페이스 유효 범위에서 사용될 때 static 은 "다른 소스 파일에서 접근할 수 없다" 는 뜻이다. -> 링킹하지 않겠다는 의미

• 아래 코드에서 외부 링크 관계를 만들고 싶다면 다음과 같이 하면 된다.

  • 다른 소스 파일에서 x1 에 접근하고 싶다면 stiatic 을 제거해야 한다.

  • x2 는 정의 앞에 extern 키워드를 붙여 주어야 한다.

// before
static int x1 = 1;
const char x2 = 'a';

// after
int x1 = 1;
extern const char x2 = 'a';

• inline 함수는 사용되는 모든 해석 단위에서 동일하게 정의되어야 한다. -> inline 함수는 컴파일 시간에 각각의 함수를 소스파일에 함수 내용을 삽입한다. (여기 까지는 문제가 안된다) -> 링커가 동작할 때 이름이 동일한 함수가 있기에 오류가 발생한다.

// file1.cpp
inline int f(int i) {return i;}

// file2.cpp
inline int f(int i) {return i+1;}

• 때문에, inline 함수는 헤더 파일에 정의해서 코드를 일관성 있게 유지해야만 한다.

• 기본적으로 const 개체, constexpr 개체, namespace 에서 static 으로 정의된 모든 것은 내부 링크 관계를 갖는다.

// h.h
inline int next(int i) {return i+1;}

// file1.cpp
#include "h.h"
int h(int i) {return next(i);}

// file2.cpp
#include "h.h"
 ... 

15.2.1 파일 로컬 이름

• 전역 변수는 유지 보수 문제를 일으킬 수 있기 때문에, 일반적으로는 피하는 편이 좋다. -> 특히 프로그램 내 어디에서 사용되는지 파악하기가 어렵고, -> 멀티스레드 프로그램에서는 엄청나게 찾기 어려운 버그를 낳는 데이터 경합의 원인이 될 수 있다.

15.2.2 헤더 파일

• 다른 해석의 단위에서 선언의 일관성을 달성하는 방법은 실행 코드나 데이터 정의가 포함된 소스 파일에 인터페이스 정보를 가진 헤더 파일을 #include 하는 것이다.

• #include 매커니즘은 소스 프로그램 단편들을 하나의 컴파일 단위로 취합하기 위한 텍스트 조작 기능이다. -> 전처리기에 의해 동작한다.

• 아래 코드는 #include 가 등장하는 행을 to_be_include 파일의 내용으로 대체한다. -> to_be_include 의 내용은 컴파일러가 해독할 수 있는 C++ 소스 텍스트여야만 한다.

#include "to_be_include"

• 표준 라이브러리의 #include 는 <> 형태로 사용 가능하다.

#include <iostream>

...