#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ではない標準で。これは広く使われている（ただし普遍的ではない）拡張であり、使用できます。

• 移植性の懸念が限られている場合
• すべてのインクルードファイルが常にローカルディスク上にあることを確認できます。

標準化のために検討されましたが、確実に実装できないため拒否されました。（この問題は、複数の異なるリモートマウントを介してファイルにアクセスできる場合に発生します。）

単一の開発内でインクルードガードの競合が発生しないようにするのはかなり簡単です。多くの異なる開発で使用される可能性があるライブラリの場合、明白な解決策は、作成時にインクルードガード用に多数のランダムな文字を生成することです。（新しいヘッダーを開くたびに、これを行うように優れたエディターを設定できます。）しかし、これがなくても、ライブラリ間の競合に関する問題はまだ発生していません。

規格のセクション16.6（N3936ドラフト）は、#pragma指令を次のように説明しています。

次の形式の前処理指令

# pragma pp-tokensopt new-line

実装が実装定義の方法で動作するようにします。この動作により、変換が失敗したり、変換プログラムまたは結果のプログラムが非準拠で動作したりする場合があります。実装で認識されないプラグマは無視されます。

基本的に #pragma onceは、実装固有のインスタンスです。#pragmaディレクティブの標準ではありません。まだ。

多くの場合、GCCやClangを含むほとんどの「主要コンパイラ」で広くサポートされているため、インクルードガードのボイラープレートを回避することが推奨される場合があります。