#include <bits/stdc++.h> 사용을 중단하세요. 컴파일러가 감사할 겁니다!

Source: Dev.to

옛 방식: 4단계 컴파일 과정

소스 코드 (.cpp)

작성하는 코드.

전처리 (.i)

전처리기가 #include 지시자를 찾습니다. #include <bits/stdc++.h> 를 만나면 해당 헤더 파일을 열어 모든 줄을 복사한 뒤 번역 단위에 바로 붙여넣습니다.

컴파일 (.obj / .o)

컴파일러가 그 거대한 텍스트 블록을 어셈블리로, 그리고 기계어로 변환합니다.

링크 (.exe / .out)

링커가 객체 파일들을 연결하고 표준 라이브러리에 저장된 실제 로직에 대한 참조를 해결합니다.

Note: .exe는 Windows에서 일반적인 실행 파일이며, .out(또는 확장자 없이 바이너리)은 macOS/Linux에서 흔히 사용됩니다.

#include <bits/stdc++.h>가 문제인 이유

• bits/stdc++.h는 수백 개의 헤더를 한 번에 포함합니다.
• 예를 들어 50개의 소스 파일이 있는 프로젝트라면, 전처리기가 동일한 수만큼(수만 줄) 복사합니다.
• 단순히 #include <bits/stdc++.h>만 사용해도 <iostream>, <vector>, <algorithm> 같은 하위 헤더들을 모두 끌어와서 컴파일러가 파싱해야 할 텍스트 양이 크게 늘어납니다.

실행, 바이너리 크기 및 컴파일 시간에 미치는 영향

현대적인 방법: C++20/23 모듈

전통적인 #include 체인 대신 다음과 같이 쓸 수 있습니다:

import std;   // <iostream>, <vector>, <algorithm> 등 기존 헤더들을 모두 대체합니다.

예시

import std;

int main() {
    std::vector<int> prices = {4500, 1200, 8900, 2300};

    std::ranges::sort(prices);

    std::cout << "Sorted prices\n";
}

• 모듈(메모리 매핑): 첫 번째 import는 바이너리 모듈을 mmap을 통해 RAM에 로드합니다. 이후의 import는 같은 메모리 영역을 매핑하므로 디스크 접근이 반복되지 않습니다.

결론

• #include <bits/stdc++.h>는 런타임 성능이나 바이너리 크기에 영향을 주지 않으며, 작은 프로그램에서는 추가 컴파일 시간이 몇 초 정도에 불과합니다.
• 대규모 프로젝트에서는 그 비용이 눈에 띄게 됩니다. 선택적인 명시적 헤더를 사용하거나, 더 나아가 C++20/23 모듈을 도입해 빌드 속도를 빠르게 유지하고 코드베이스를 깔끔하게 관리하는 것이 좋습니다.