항목 24 : 내부 #include 가드를 사용하라. 외부 #include 가드를 써서는 안 된다. ( Always write internal #include guards. Never write external #include guards. )

{

이번 항목은 그냥 예만 보여줘도 손 쉽게 이해 할 수 있을 것이라고 생각 한다.
// 내부 #include 가드 예 #ifndef FOO_H_INCLUDE_ #define FOO_H_INCLUDE_ // 파일에 대한 내용 #endif // FOO_H_INCLUDE_ // 외부 #include 가드 웨 #ifndef FOO_H_INCLUDE_ #define FOO_H_INCLUDE_ #include "foo.h" #endif // FOO_H_INCLUDE_

가드의 목적은 무엇인가?

가드의 목적은 중복 #include 를 막음으로써, 단일 정의 규칙을 지키기 위해서이다. C 컴파일러든 C++ 컴파일러든 단일 정의 규칙을 따른다. 만약 지키지 않을 경우 재정의 에러, 즉 컴파일 에러를 벹어 내며 컴파일이 되지 않는다. 다른 가드로는 #pragma once 란 지시자가 바로 이런 가드 기능을 대신 할 수 있는데, 되는 컴파일러가 있고, 되지 않는 컴파일러가 있기 때문에, 두개 다 사용하는게 바람직 하다.(2009년 2월 22일 현재까지도, boost 라이브러리가 이 룰을 지키고 있다. 예로 모든 라이브러리를 보면 그렇게 되어 있다.)

왜 외부 가드가 내부 가드보다 좋지 않은가?

1. 수 많은 사람들은 내부 가드만 사용한다. 그렇기 때문에 내가 #include "헤더"를 했을 경우, 당연히 내부 가드가 되어 있다고 판단 하고 사용 하는 것이다. 그런데 만약 이게 외부 가드를 하는 형태라면 어떻겠는가? .. 당연히 컴파일 에러가 쫘좌락 나게 되어서, 다시 바꾸는 수고를 해야 할 것이다.

그렇다면 외부 가드는 전혀 안쓰는가?

지금까지 한번도 본적이 없다. 쓴 코드를 본다면 댓글 부탁합니다. 어떨때 쓰는지 저도 알고 싶습니다.

가드를 할 경우 주의 해야 할 것이 있는가?

경험이 말해 주듯이 네트워크 관련 헤더를 만드는 중 나는 내부 가드를 사용 했었다. 그런데 내부 가드에 쓰는 #define 지시자가 중복이 되어, 2시간 동안 "도대체!!!!!!!!!! 왜 이 타입을 못보는거야!" 라고 마음속으로만 소리를 지르며, 두 눈을 부릅뜨며 해면 적이 있었다. 즉, #define 지시자가 중복되는 것이 없게 해야 한다.

요령은 앞에 "_" 를 붙이지 않는 것이다. 왜냐하면 컴파일러 또는 라이브러리 제작자의 특권이 바로 앞에 "_"를 쓰는 것이기 때문이다. boost 의 경우 .. 앞에 _ 를 볼 수 있으니 확인 하기 바란다.(예 boost::bind 의 arg 위치 정하는 변수명에..)

이제부터는 "자신 센스의 몫, 다른 사람이 납득하기 쉬운 요령을 터득하시길!"

}