사용하지 않는 포함은 C / C ++에서 유해합니까?

사용하지 않는 포함은 C / C ++에서 유해합니까?

---

사용하지 않은 포함의 부정적인 결과는 무엇입니까?

바이너리 크기가 증가한다는 것을 알고 있습니다 (또는 수행합니까?).

---

• 컴파일 시간 증가 (잠재적으로 심각한 문제)
• 글로벌 네임 스페이스를 오염시킵니다.
• 전 처리기 이름의 잠재적 충돌.
• 사용하지 않는 헤더가 타사 라이브러리에서 포함 된 경우 이러한 라이브러리가 불필요하게 종속성으로 유지 될 수 있습니다.

---

바이너리 크기가 반드시 증가하지는 않지만 컴파일 시간이 늘어납니다.

---

주요 문제는 어수선하다 . 다음은 혼란이 나타나는 세 가지 주요 측면입니다.

1. 시각 오염; 필요한 다른 포함 사항을 파악하는 동안.

2. 논리적 오염; 함수가 충돌 할 가능성이 더 높고 컴파일 시간이 더 길어집니다 (두 개의 포함에 대해 정말 작을 수 있지만 불필요한 포함을 정리하지 않는 "정책"이된다면 중요한 장애물이 될 수 있습니다).

3. 종속성 불투명도; 분석 할 헤더가 더 많기 때문에 코드에서 종속성주기를 결정하기가 더 어렵습니다. 코드베이스가 취미 수준을 넘어서는 중요한 수준으로 성장할 때 코드의 종속성이 무엇인지 아는 것이 중요합니다.

---

일반적으로 말하자면, 몇 가지 문제가 발생합니다. 논리적으로 말하면 필요하지 않으면 포함하지 마십시오.

• 헤더에서 외부로 선언되고 소스 파일에 정의 된 모든 싱글 톤이 프로그램에 포함됩니다. 이것은 분명히 메모리 사용량을 증가시키고 페이지 파일에 더 자주 액세스하도록하여 성능 오버 헤드에 기여할 수 있습니다 (싱글 톤은 일반적으로 크기가 중소형이고 제가 아는 대부분의 사람들이 6+를 가지고 있기 때문에 지금은 별 문제가되지 않습니다. GB RAM).

• 컴파일 시간이 길어지고 자주 컴파일되는 대규모 상업 프로젝트의 경우 비용 손실이 발생할 수 있습니다. 총 시간에 몇 초 밖에 걸리지 않을 수 있지만 수백 개의 컴파일을 곱하면 테스트 및 디버그가 필요할 수 있으며 막대한 시간 낭비가 발생하여 이익 손실로 이어집니다.

• 헤더가 많을수록 프로그램이나 다른 헤더에서 정의한 매크로와 충돌 할 가능성이 높아집니다. 이것은 네임 스페이스의 올바른 사용을 통해 피할 수 있지만 여전히 찾기가 번거 롭습니다. 다시, 이익을 잃었습니다.

• 코드 부풀림에 기여하고 (파일 길이가 길어 읽기가 더 많음) IDE의 자동 완성 도구에서 찾을 수있는 결과의 수를 크게 늘릴 수 있습니다 (일부 사람들은 이러한 도구에 대해 종교적으로 반대하지만 어느 정도 생산성을 높입니다).

• 다른 외부 라이브러리를 모르는 사이에 실수로 프로그램에 연결할 수 있습니다.

• 이렇게하면 부주의로 세상의 종말을 초래할 수 있습니다.

---

헤더는 모두 "진실한"것으로 간주 될 수 있다고 가정합니다. 즉, 코드를 방해 할 목적으로 정확하게 작성되지 않았습니다.

• 일반적으로 컴파일 속도가 느려집니다 (미리 컴파일 된 헤더가이 지점을 완화 함).

• 실제로 존재하지 않는 종속성을 의미합니다 (실제 오류가 아니라 의미 오류).

• 매크로는 코드를 오염시킵니다 ( FOREACH 대신 BOOST_FOREACH 에서와 같이 네임 스페이스와 같은 이름의 매크로 접두사로 완화됨 ).

• 헤더는 다른 라이브러리에 대한 링크를 의미 할 수 있습니다. 경우에 따라 사용하지 않는 헤더가 링커에게 코드를 외부 라이브러리와 연결하도록 요청할 수 있습니다 (MSCV의 #pragma comment (lib, "") 참조 ). 좋은 링커가 사용되지 않으면 라이브러리의 참조를 유지하지 않을 것이라고 생각합니다 (IIRC, MSVC의 링커는 사용되지 않는 라이브러리의 참조를 유지하지 않습니다).

• 제거 된 헤더는 예기치 않은 버그의 원인이 하나 적습니다. 헤더를 신뢰하지 않는 경우 (일부 코더가 다른 코더보다 낫다 ...), 헤더를 제거하면 위험이 제거 됩니다 ( 그 뒤에있는 모든 것의 구조체 정렬을 변경하는 헤더를 포함하는 것을 좋아하지 않을 것입니다. 생성 된 버그는 .. . 조명 ... ).

• 헤더의 static변수 선언은 코드를 오염시킵니다. 각 정적 변수 선언은 컴파일 된 소스에 선언 된 전역 변수가됩니다.

• C 기호 이름은 코드를 오염시킵니다. 헤더의 선언은 전역 또는 구조체 네임 스페이스를 오염시킬 것입니다 (구조체는 일반적으로 유형을 전역 네임 스페이스로 가져 오기 위해 typedef-ed이므로 둘 다). 이것은 SDL_CreateMutexSDL 과 같이 일종의 "네임 스페이스 이름"을 기호에 접두사로 붙인 라이브러리에 의해 완화됩니다 .

• 네임 스페이스가 지정되지 않은 C ++ 기호 이름은 코드를 오염시킵니다. 위와 같은 이유로. using namespace명령문을 잘못 사용하는 헤더도 마찬가지입니다. 이제 올바른 C ++ 코드가 해당 심볼의 네임 스페이스를 지정합니다. 예, 이것은 일반적으로 전역 네임 스페이스에서 심볼을 선언하는 C ++ 헤더를 신뢰해서는 안된다는 것을 의미합니다.

---

바이너리 크기를 늘리는 지 여부는 실제로 무엇이 들어 있는지에 달려 있습니다.

주요 부작용은 아마도 컴파일 속도에 대한 부정적인 영향 일 것입니다. 다시 말하지만, 얼마나 큰 영향을 미치는지는 그 안에 무엇이 있는지, 얼마나 많은지, 다른 헤더를 포함하는지 여부에 달려 있습니다.

---

그것들을 남겨두면 컴파일 시간이 연장 되고 불필요한 컴파일 종속성이 추가 됩니다.

---

서투른 디자인을 나타냅니다.

무엇을 포함해야하는지, 무엇을 포함하지 말아야할지 잘 모르겠다면 개발자가 자신이 무엇을하고 있는지 전혀 몰랐 음을 보여줍니다.

포함 파일은 필요한 경우에만 포함됩니다. 요즘 컴퓨터 메모리와 속도가 비약적으로 증가하고 있기 때문에 그다지 문제가되지는 않을지 모르지만 아마도 한때 그랬을 것입니다.

포함이 필요하지 않지만 어쨌든 포함 된 경우 포함 이유를 설명하는 주석을 옆에 넣는 것이 좋습니다. 새로운 개발자가 여러분의 코드에 익숙해지면, 여러분이 올바른 방법으로 작업했다면 그는 여러분에게 많은 감사를 표할 것입니다.

---

include는 더 많은 선언을 추가한다는 것을 의미합니다. 따라서 고유 한 전역 함수를 작성할 때 포함 된 헤더에 함수가 이미 declaerd되어 있다는 점에주의해야합니다.

전의. "메모리"를 포함하지 않고 자신의 클래스 auto_ptr {}를 작성하면 제대로 작동합니다. 그러나 메모리를 포함 할 때마다 컴파일러는 이미 메모리 헤더 파일에 선언되었으므로 오류를 발생시킵니다.

---

예, 사용하지 않는 extern 변수로 인해 이진 크기를 늘릴 수 있습니다.

//---- in unused includes ----
extern int /* or a big class */ unused_var;

//---- in third party library ----
int unused_var = 13;

참고 URL : https://stackoverflow.com/questions/7919258/are-unused-includes-harmful-in-cc