[C++] #include < >vs #include " "

목차

1. include <> vs ""

2. 응용/심화

3. 요약

 

---

1. include <> vs "" 

include < > :

컴파일러 설정에 등록된 표준 시스템 / 외부 SDK 헤더 경로 우선 탐색

 

include " " :

현재 프로젝트 또는 현재 파일 우선 탐색, 프로젝트 내부 소스라는 것을 묵시적 의미

 

- 전처리기는 #include 지시문을 만나면 어떤 경로를 어떤 순서로 탐색할지를 결정.

- 일반적으로 " "(현재 디렉토리)를 먼저 보고 그 다음에 < >를 통해 시스템 / 표준 경로를 우선. (컴파일러 옵션에 따라 변형)

 

 

---

2. 응용/심화

#pragma once

#include 표기는 중복 include를 막을 수 없음. 헤더의 중복 방지는 헤더 가드(#ifdef, #define, #endif) 또는 #pragma once로 해결. 다만 include 경로가 흔들리면 같은 파일을 두 번 include 하는 문제 발생 가능.

 

C++

// MyWidget.h
#ifndef MYWIDGET_H
#define MYWIDGET_H

struct MyWidget
{
    int id;
};

#endif // MYWIDGET_H

 

 

빌드 안정성

빌드 안정성 : 같은 소스가 다른 결과물을 도출

- 빌드의 안정성은 검색 경로가 결정적인지가 핵심.

ex) 개발 PC에서는 SDK 경로가 잡히나 타 PC에서는 없거나 잡히지 않아서 깨짐.

- < >, " "를 의도에 맞게 사용하면 위와 같은 비 결정성을 감소시킬 수 있음.

 

- 빌드 안정성을 위한 습관

1. 프로젝트 내부 헤더는 " "로 통일하고 외부 SDK/표준 라이브러리는 <>로 통일.

2. 동명 헤더를 만들지 않음.

3. 외부 헤더 경로는 스크립트로 명시하고, 개발자 개인의 환경 변수에 의존하지 않음.

4. -isystem을 사용하여 외부 헤더 경고를 격리하고 내부 경고를 깨끗하게 유지.

 

- 실무에서 가장 안정적인 방식은 프로젝트 include 루트를 하나로 정하고 모든 내부 헤더를 그 루트를 기준으로 include 하는것.

// 외부/표준은 <>
#include <vector>
#include <windows.h>

// 프로젝트 내부는 "" + 루트 기준 경로
#include "proj/core/Log.h"
#include "proj/ui/Button.h"

 

 

ex) 잘못된 헤더 삽입 예시

#include "vector"      // 표준 라이브러리인데 따옴표 사용 (탐색 낭비)
#include <MyProject.h> // 내부 헤더인데 각괄호 사용 (설정에 따라 빌드 실패 가능성)

 

 

ex) 실무 실수 예시

 

- 빌드 속도 최적화 체크리스트

1, 헤더 계층을 정의하고 하향 의존만 허용

2. 공용 헤더 변경은 코드리뷰 + 리빌드 시간 측정을 포함

3. 빌드 시간 KPI를 기록하고 추세 확인

4. 전방 선언 가능/불가오 인라인/템플릿 노축 규칙을 문서화

5. Release 빌드는 개발 빌드와 동일한 옵션/경로로 재현 가능해야 함

 

 

컴파일 시간 최적화

컴파일 시간 최적화 : 같은 소스가 다른 컴파일 시간 소모

- 컴파일 시간은 헤더 검색보다 텍스트 양(경로의)에 따라 결정, 만약 잘못된 include 경로나 표기로 무거운 헤더를 가져오는 경우 순환 참조 등의 오류가 발생하여 전처리 결과와 시간이 폭발적으로 증가.

ex) 모든 헤더를 " "로 선언하면 표준 라이브러리 등을 탐색하는 과정에서 모든 폴더를 뒤져야함.

ex) 파일 개수가 많아지면 탐색 지연이 누적되어 전체 빌드 시간이 증가.

 

- 컴파일 시간 최적화를 위한 습관

1. 공용 헤더는 최대한 가볍게 유지.

2, 소스에서만 필요한 헤더는 헤더에 올리지 않기.

3, 전방 선언으로 포인터 의존도 낮춤.

4. PCH(Precompiled Header)는 '안정적이고 바뀌지 않는' 헤더만 삽입.

 

ex) 컴파일 시간이 늘어나는 예시

 

 

 

include 카드의 유효범위와 ODR

헤더가드는 같은 번역 단위 안에서의 중복 include만 제한할 수 있음, 여러 번역 단위에 걸친 중복 종의는 ODR(One Definition Rule)의 영역.

- ODR : include 방식이 아닌 헤더에 정의를 넣는 습관

 

ODR 관점에서 헤더에 두면 위험한 것

 

 

 

---

3. 요약

#include < > : 표준 라이브러리 / SDK 경로를 우선 탐색

#include " " : 현재 파일 및 프로젝트를 우선 탐색

-> 헤더 검색 경로의 우선순위를 표현하는 수단이자 개발자의 의도를 드러내는 수단.

-> 컴파일 시간 최적화 빌드 안정성을 위해서는 include 표기 규칙을 명확히 설정하여 지켜야 하고, 중복 방지는 헤더 가드, pragma once, ODR 규칙이 핵심