#pragma는 한 번 C ++ 11 표준의 일부입니까?

전통적으로 C ++에 여러 헤더가 포함되는 것을 피하는 표준 및 이식 가능한 방법은 매크로 가드 체계#ifndef - #define - #endif 라고도 하는 프리 컴파일러 지시문 체계 를 사용하는 것입니다 (아래 코드 조각 참조).

#ifndef MY_HEADER_HPP
#define MY_HEADER_HPP
...
#endif

그러나 대부분의 구현 / 컴파일러 (아래 그림 참조)에는라는 매크로 보호 체계와 동일한 목적을 수행하는보다 "우아한"대안이 있습니다 #pragma once. #pragma once코드 보호, 이름 충돌 방지, 때로는 컴파일 속도 향상을 포함하여 매크로 가드 체계와 비교하여 몇 가지 장점이 있습니다.

몇 가지 연구를 통해 #pragma once지시문이 거의 모든 알려진 컴파일러에서 지원 되지만 지시문이 #pragma onceC ++ 11 표준의 일부 인지 여부에 대한 혼돈이 있음을 깨달았습니다 .

질문 :

• #pragma once지시문이 C ++ 11 표준의 일부 인지 여부를 누군가가 명확히 할 수 있습니까?
• C ++ 11 표준의 일부가 아닌 경우 이후 릴리스 (예 : C ++ 14 이상)에 포함시킬 계획이 있습니까?
• 누군가가 기술 중 하나를 사용할 때의 장점 / 단점에 대해 더 자세히 설명 할 수 있다면 좋을 것입니다 (예 : 매크로 가드 대 #pragma once).

#pragma once표준 이 아닙니다 . 널리 사용되는 것은 아니지만 널리 사용되는 확장입니다.

• 휴대 성 문제가 제한적인 경우
• 모든 포함 파일이 항상 로컬 디스크에 있는지 확인할 수 있습니다.

표준화를 위해 고려되었지만 신뢰성있게 구현할 수 없기 때문에 거부되었습니다. 여러 다른 원격 마운트를 통해 파일에 액세스 할 수있는 경우 문제가 발생합니다.

단일 개발 내에서 포함 가드 충돌이 없는지 확인하는 것은 매우 쉽습니다. 많은 다른 개발에서 사용될 수있는 라이브러리의 경우 확실한 해결책은 포함 가드를 작성할 때 무작위 문자를 많이 생성하는 것입니다. (새 헤더를 열 때마다이 작업을 수행 할 수있는 좋은 편집기를 설정할 수 있습니다.) 그러나이 기능이 없어도 라이브러리 간 충돌 문제는 아직 발생하지 않았습니다.

표준의 §16.6 ( N3936 초안)은 #pragma지침을 다음과 같이 설명 합니다.

양식의 전처리 지시문

# pragma pp-tokensopt new-line

구현이 구현 정의 방식으로 작동하도록합니다. 이 동작으로 인해 번역이 실패하거나 번역기 또는 결과 프로그램이 부적합한 방식으로 작동 할 수 있습니다. 구현에서 인식되지 않는 pragma는 무시됩니다.

기본적으로 지시문 #pragma once의 구현 별 인스턴스이며 #pragma표준이 아닙니다. 아직.

GCC 및 Clang을 포함한 대부분의 "주요 컴파일러"에서 널리 지원 되므로 include-guards 상용구를 피하는 것이 좋습니다.