본문 바로가기

awesome-c Beginner 번역/Building C Projects

<비공식 번역>awesome-c Beginner 번역 : 5. Header precompileation

현재위치


1. Configuration

2. Standard directory dectection

3. Source file dependency calculation

4. Header file location

5. Header precompileation

6. Preprocessing

7. Compliation and assembly

8. Object file dependency calculation

9. Linking

10. Installation

11. Resource linking

12. Package generation

13. Dynamic linking

<주의!!>

nethack4.org의 'Building C Projects'의 공식적인 번역이 아니며 수를 받은 것 역시 아닙니다!!




5 : Header precompileation(헤더 사전 컴파일)


C프로그래밍 초기에, 전처리기는 매우 낮은 수준에서 작동했습니다. 거의 그냥 텍스트로 소스를 조작했었죠. 비록 전처리기는 여전히 - 경우에따라 누군가는 C보다 다른 어떤 것들을 위해 전처리기를 사용하기도합니다. - 실제로도 문제를 조율하는데에 빠르게 동작할 수 있습니다. 문제는 표준 헤더들을 포함할 수 있는 모든 가능한 프로그램을 처리하도록 설계되어야 한든 점입니다; 우리 Hello World 프로그램은 오직 fputs와 stdout를 사용합니다. 그러나 stdio.h는 임의의 누군가 또는 모두가 사용할 수 있는 프로그램의 많은 것들을 가지고 있습니다. 그 결과 우리의 Hello World 프로그램은 1192줄의 길이를 가집니다; 그들의 대부분은 비어있고, 그들의 대부분은 사용되지 않는습니다, 그러나 컴파일러는 전처리가 끝날때까지 이를 알 방법이 없습니다.


전통적인 빌드 프로세스는 각 소스파일을 개별적으로 전처리기를 거쳤습니다. 각 헤더파일은 각 소스 파일마다 한 번씩 전처리기에 의해 읽혀야 한다는 뜻입니다. 여기에는 두가지 문제점이 존재합니다. 하나는 시간이 매우 오래 걸립니다.(특히 C++을 사용할 경우 빌드 프로세스는 C와 매우 유사합니다.) 현대 컴퓨터들은 일(日)단위 보다는 수십초가 걸릴정도로 충분히 빠릅니다. 그러나 빌드에서 몇분을 기다리는 것은 여러분의 개발 과정(process)을 상당히 느리게 만들 수 있습니다. (컴파일러를 통해 에러를 찾아내는 속도를 줄이고 여러분이 IDE로부터 유용한 피드백을 받을 수 없기 때문입니다.) 나머지 하나는 헤더파일에서의 선언 실수입니다. 이것은 선언이 되든지 아니든지 그 헤더를 포함하는 모든 파일의 컴파일 에러의 원인이 될 것입니다.


현대 컴파일러는 전처리기의 작업과 밀접하게 작동하는 것을 감안 할 때, 위 문제에 대한 해결책이 됩니다: 전처리기와 컴파일러는 결국 사용될 소스파일을 알 필요 없이 사전에 가능한 한 많은 헤더파일의 컴파일 작업을 서로도울 수 있습니다. 헤더파일이 아닌 모든 부분을 미리 컴파일 할 수는 없지만 (예를 들어 #define 텍스트 대체의 효과는 코드가 끝난 후에도 넣을 수 있기 때문에 미리 계산하는 것은 불가능합니다.) 헤더파일이 가능한 많은 부분은 선언입니다. 헤더파일은 한번만 파싱이 필요하단 의미이고(파일 당 한번 사용하기 보단), 에러는 이것이 사용되기 전에 잡아낼 수도 있을 것입니다. (또한 임의의 헤더를 변경하지 않고 변경되는 일반적인 경우에서 도움이 됩니다; 미리 컴파일된 동일한 헤더는 마지막으로 사용될 수 있습니다.)


상대적으로 오래되긴 했지만(1990년대에 사용된 것으로 기억합니다.), 미리 컴파일된 헤더는 여전히 C toolchain의 다른 어떤 부분 보다도 새로운 혁신이며 따라서 비표준입니다. gccclang은 미리 컴파일된 헤더 .h.gch 확장을 사용합니다. Visual Studio는 .ipch를 사용하는 것 같습니다.


현재 aimake는 항상 미리 컴파일된 헤더를 사용합니다. 저는 실제 절약한 시간을 100% 확신하진 못하지만 ㅡ 대부분의 경우에서 컴파일러의 속도가 증가하더라도 aimake는 그것들을 추적하기 때문에 느려집니다. ㅡ 개선된 에러 메시지는 가치가 있습니다.



출처1 : https://github.com/aleksandar-todorovic/awesome-c

출처2 : http://nethack4.org/blog/building-c.html