{

이번 항목은 그냥 예만 보여줘도 손 쉽게 이해 할 수 있을 것이라고 생각 한다.


가드의 목적은 무엇인가?

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

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

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


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

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


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

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

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

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

}

'책 정리 > C++ Coding Standards : C++ 코딩의 정석' 카테고리의 다른 글

항목 29 : 간접적인 타입 변환을 피하기 위해 오버로딩을 활용하라. ( Consider overloading to avoid implicit type conversions. )  (0) 2009.02.25
항목 28 : ++와 --의 표준적인 형식과 접두 형식을 사용하라. ( Prefer the canonical form of ++ and --. Prefer calling the prefix forms. )  (0) 2009.02.25
항목 27 : 표준적인 형식의 산술 및 할당 연산자를 사용하라. ( Prefer the canonical forms of arithmetic and assignment operators. )  (0) 2009.02.25
항목 26 : 오버로딩된 연산자의 본래 의미를 유지하라. ( Preserve natural semantics for overloaded operators. )  (0) 2009.02.24
항목 25 : 값, (스마트) 포인터, 참조 중 적절한 방식으로 인자를 얻어라.(Take parameters appropriately by value, (smart) pointer, or reference. )  (0) 2009.02.24
항목 24 : 내부 #include 가드를 사용하라. 외부 #include 가드를 써서는 안 된다. ( Always write internal #include guards. Never write external #include guards. )  (0) 2009.02.24
항목 23 : 헤더 파일은 충분히 완성된 형태로 만들어라. ( Make header files self-sufficient. )  (0) 2009.02.24
항목 22 : 정의의 의존성과 순환 의존성을 최소화 하라. ( Minimize definitional dependencies. Avoid cyclic dependencies. )  (0) 2009.02.24
항목 21 : 컴파일 단위 사이의 초기화 의존성을 없애라. ( Avoid initialization dependencies across compilation units. )  (0) 2009.02.23
항목 20 : 너무 긴 함수와 많은 중첩구조는 피하라. ( Avoid long functions. Avoid deep nesting. )  (0) 2009.02.23
항목 19 : 변수는 항상 초기화하여 사용하라. ( Always initialize variables. )  (0) 2009.02.23
posted by 농사를 짓는 게임 프로그래머 최익필

댓글을 달아 주세요