#pragma是否曾经是C ++ 11标准的一部分？

传统上，避免C ++中包含多个标头的标准且可移植的方法是使用#ifndef - #define - #endif预编译器指令方案，该方案也称为宏保护方案（请参见下面的代码段）。

#ifndef MY_HEADER_HPP
#define MY_HEADER_HPP
...
#endif

但是，在大多数实现/编译器中（请参见下图），还有一个更“优雅”的替代方案，其作用与称为的宏保护方案相同#pragma once。#pragma once与宏保护方案相比，它具有多个优点，包括更少的代码，避免名称冲突以及有时提高了编译速度。

经过研究，我意识到尽管#pragma once几乎所有已知的编译器都支持伪指令，但是伪#pragma once指令是否属于C ++ 11标准还是有一定的困惑。

问题：

• 有人可以澄清#pragma once指令是否属于C ++ 11标准吗？
• 如果它不是C ++ 11标准的一部分，是否有任何计划将其包含在更高版本中（例如C ++ 14或更高版本）？
• 如果有人可以进一步详细说明使用这两种技术中的任何一种（例如，宏观卫士与#pragma once）的优势/劣势，那也很好。

#pragma once是不是标准。这是一个广泛的（但不是通用的）扩展，可以使用

• 如果您的便携性问题有限，并且
• 您可以确保所有包含文件始终位于本地磁盘上。

考虑将其标准化，但由于无法可靠实施而被拒绝。（当您具有可通过几个不同的远程安装访问的文件时，就会出现问题。）

确保在单个开发中不存在包含卫队冲突是相当容易的。对于可能由许多不同的开发人员使用的库，显而易见的解决方案是在创建库时为include保护生成许多随机字符。（可以设置一个好的编辑器来为您执行此操作，只要您打开新的标头即可。）但是即使没有此操作，我仍然没有遇到库之间冲突的任何问题。

该标准的第16.6节（N3936草案）将#pragma指令描述为：

形式的预处理指令

# pragma pp-tokensopt new-line

使实现以实现定义的方式运行。该行为可能导致翻译失败或导致翻译器或生成的程序以不符合标准的方式运行。该实现无法识别的任何杂注将被忽略。

基本上，它#pragma once是#pragma指令的特定于实现的实例，不，它不是标准的。然而。

它通常受到包括GCC和Clang在内的大多数“主要编译器”的广泛支持，因此有时建议避免使用包含保护的样板。