#pragma는 단순히 define나 include와 같이 #으로 시작되는 전처리문의 하나입니다.
대단한 용법은 아닙니다.
다만 편의성과 기능성을 제공해 주죠.
현재 자신이 사용하고 있는 컴파일러가 이녀석을 지원해 준다면
이전글에서 헤더파일 중복문제 해결을 위한 방법보다 좋은 성과를 보여줄 겁니다.
이전글의 내용이 생각나지 않는 분을 위해 이곳에 이전글의 핵심 내용을 간단히 보여 드리죠.
// 헤더 파일의 제일 첫 부분
01: #ifndef HDR_H // 헤더 파일명을 대문자한 매크로가 정의되어 있지 않으면
02: #define HDR_H // 헤더 파일명 매크로를 정의한다
...... // 헤더 파일 본 내용이 여기 들어갑니다
03: #endif // ifndef HDR_H 에 매치됩니다
위와 같이 헤더 파일을 작성하게 되면 다음과 같은 과정이 일어나게 됩니다.
컴파일러와 역지사지해서 생각해 보겠습니다.
1. 처음으로 헤더 파일이 포함될 때, 컴파일러(좀 더 정확히 말하면 프리프로세서)가
01 라인을 만나게 되면 HDR_H 매크로가 정의되어 있지 않으므로 02 라인을 해석하게 됩니다.
2. 02 라인을 만나면 이제 HDR_H 매크로를 정의하게 됩니다.
3. 다음에 다시 같은 헤더 파일이 포함될 때는 HDR_H이 정의되어 있기 때문에
모든 헤더 파일의 내용을 스킵하게 됩니다. 즉, 포함되지 않는 효과가 생기게 됩니다.
이러한 방법을 include guard (포함 보호)라고 합니다.
이 방법도 무척 훌륭한 방법입니다.
다만 사용자 입장에서 실수할 여지가 많다는 겁니다.
매크로 이름의 충돌가능성등 말이죠.
물론 어지간한 프로젝트에서는 이런 일은 발생하기 어려울 겁니다 ^^a...
그리고 include guard는 한번 읽은 헤더파일도 일단 헤더파일의 내용을 다 읽어야 합니다.
시간낭비고 컴파일러 컴력 낭비(ㅡㅡ;) 이고 효율낭비이죠.
pragma는 이러한 면에서 확실히 뛰어납니다.
이녀석의 경우는 각 파일별로 프리프로세서가 include한 상태를 기억하고 있어서
한번만 include한다면 이후로 다시 읽어야하는 지루한 일은 안한다는 겁니다.
오~ pragma녀석... 무척좋군~
하시는 분도 있을겁니다.
하지만 안타깝게도 이녀석은 표준이 아닙니다.
즉, 이녀석을 사용하여 프로그램을 짠다면 다른 어떠한 환경에서는
이녀석을 지원해주지않는일을 보게 될 겁니다.
그 외에도 문제가 있지만 가장 큰 문제는 표준이 아니라는 점이죠.
그럼 이제 슬슬 고민이 되겠죠?
도대체 어떤놈을 써란말이야~~!!
결론은 이겁니다. 내부 포함보호와 외부 포함보호를 적절히 활용하라.
이전에 헤더파일 중복 문제해결방법은 내부 포함보호방법이었죠.
#ifndef HDR_H
#include "hdr1.h"
#endif
요런방법이 외부 포함 보호방법입니다.
이 방법을 사용하면 include guard의 문제점인 컴파일 속도측면에서의
비효율성 문제를 극복할 수 있습니다.
기억하세요.
손쉽고 편한 pragma 를 사용하여 이식성을 한껏 낮추는 것 보다는
내부 - 외부 포함 보호 방법을 적절히 활용하여 헤더파일 중복을 막는것이
더 올바른 자세란 것을요.
출처 - http://blog.naver.com/khercules
