#pragmaは安全なインクルードガードですか？

使用時にコンパイラの最適化があることを読みました #pragma onceが行われ、コンパイルが高速を確認しました。これは非標準であり、クロスプラットフォームの互換性の問題を引き起こす可能性があることを認識しています。

これは、非Windowsプラットフォーム（gcc）上の最新のコンパイラーでサポートされているものですか？

プラットフォームのコンパイルの問題を避けたいだけでなく、フォールバックガードの余分な作業も避けたいです。

#pragma once
#ifndef HEADER_H
#define HEADER_H

...

#endif // HEADER_H

心配する必要がありますか？これにさらに精神的なエネルギーを費やす必要がありますか？

を使用#pragma onceしてすべての最新のコンパイラで動作するはずですが、標準の#ifndefインクルードガードを使用しない理由はありません。正常に動作します。1つの注意点は、GCCがバージョン3.4#pragma once以前ではサポートしていなかったことです。

また、少なくともGCCでは、標準の#ifndefインクルードガードを認識して最適化するので、それよりも遅くなることはありません#pragma once。

#pragma once には1つの欠点があります（非標準以外）。つまり、同じファイルが別の場所にある場合（ビルドシステムがファイルをコピーするためにこのファイルが存在する場合）、コンパイラはこれらのファイルが異なると見なします。

私は望む #pragma once（またはそのようなもの）が標準にあっます。インクルードガードはそれほど大きな問題ではありません（ただし、言語を学習している人に説明するのは少し難しいようです）が、回避できた可能性のある軽度の煩わしさのようです。

実際、99.98％の時から、#pragma once動作は望ましい動作です。ヘッダーの複数インクルードの防止がコンパイラによって自動的に処理された場合、それは良かったでしょう。#pragmaダブルを許可場合に適しています。

しかし、私たちは私たちが持っているものを持っています（あなたが持っていないかもしれないことを除いて#pragma once）。

パフォーマンスの利点についてはわかりませんが、確かに機能します。私はすべてのC ++プロジェクトで使用しています（MSコンパイラーを使用していることを確認しています）。使用するよりも効果的だと思う

#ifndef HEADERNAME_H
#define HEADERNAME_H
...
#endif

同じ処理を行い、プリプロセッサに追加のマクロを設定しません。

GCC はバージョン3.4から#pragma once正式にサポートしています。

GCCは#pragma once3.4以降でサポートされています。コンパイラのサポートについては、http：//en.wikipedia.org/wiki/Pragma_onceを参照してください。

#pragma onceガードを含めるのではなく使用することで私が目にする大きな利点は、コピー/貼り付けエラーを回避することです。

それに直面しましょう：私たちのほとんどは、新しいヘッダーファイルを最初から作成することはほとんどありませんが、既存のヘッダーファイルをコピーして必要に応じて変更するだけです。#pragma onceガードを使用する代わりに、使用するテンプレートを作成する方がはるかに簡単です。テンプレートを変更する必要が少ないほど、エラーが発生する可能性は低くなります。異なるファイルで同じインクルードガードを使用すると、奇妙なコンパイラエラーが発生し、何が問題だったかを理解するのに時間がかかります。

TL; DR：#pragma once使いやすい。

私はそれを使用しており、新しいヘッダーを作成するために入力する必要がほとんどないので、満足しています。Windows、Mac、Linuxの3つのプラットフォームで、私には問題なく動作しました。

パフォーマンスに関する情報はありませんが、＃pragmaとインクルードガードの違いは、C ++文法の解析の遅さに比べれば何も変わらないと思います。それが本当の問題です。たとえば、C＃コンパイラーで同じ数のファイルと行をコンパイルして、違いを確認してください。

結局のところ、ガードやプラグマを使用することはまったく問題ではありません。

' #pragma once' を使用しても効果がない可能性があります（どこでもサポートされているわけではありませんが、ますます広くサポートされています）。そのため、とにかく条件付きコンパイルコードを使用する必要があり#pragma onceます。コンパイラはおそらくとにかくそれを最適化します。ただし、ターゲットプラットフォームによって異なります。すべてのターゲットがそれをサポートしている場合は、先に進んでそれを使用してください。ただし、プラグマのみを使用し、それをサポートしていないコンパイラーに移植した場合、すべての問題が解消されるため、意識的に決定する必要があります。

パフォーマンス上の利点は、＃pragmaが一度読み込まれると、ファイルを再度開く必要がないことです。ガードを使用すると、コンパイラーはファイルを開いて（時間がかかる可能性があります）、コンテンツを再び含めてはならないという情報を取得する必要があります。

一部のコンパイラは、コンパイル単位ごとに、読み込まれたコードが含まれていないファイルを自動的に開かないため、これは理論にすぎません。

とにかく、それはすべてのコンパイラーに当てはまるわけではないので、理想的には#pragmaをクロスプラットフォームコードで回避する必要があります。ただし、実際には、ガードよりも優れています。

最後に、この場合、各コンパイラーの動作を確認する必要なしにコンパイラーから最高の速度を確実に得ることができるより良い提案は、プラグマとガードの両方を使用することです。

#ifndef NR_TEST_H
#define NR_TEST_H
#pragma once

#include "Thing.h"

namespace MyApp
{
 // ...
}

#endif

そうすることで、両方の利点を最大限に活用できます（クロスプラットフォームであり、コンパイル速度が向上します）。

タイプするのが長いので、私は個人的にツールを使用して、すべてを非常に素晴らしい方法で生成します（Visual Assist X）。

常にではない。

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52566には、両方のファイルを含めることを意図した2つのファイルの良い例がありますが、タイムスタンプとコンテンツが同一であるため（ファイル名は同一ではない）、誤って同一と見なされます。

非常に大きなツリーでgcc 3.4と4.1を使用する（時にはdistccを利用する））、標準プラグインの代わりに、または標準のインクルードガードと組み合わせて#pragmaを使用すると、速度が向上することはまだありません。

実際の節約はないので、gccの古いバージョンや他のコンパイラさえも混乱させる可能性があるのか​​、実際にはわかりません。私はさまざまなde-linterのすべてを試したことはありませんが、それらの多くを混乱させると確信しています。

私もそれが早い段階で採用されたことを望みますが、「ifndefが完全に正常に機能するのに、なぜそれが必要なのか」という議論を見ることができます。Cの多くの暗いコーナーと複雑さを考えると、インクルードガードは最も簡単で自己説明的なものの1つです。プリプロセッサーがどのように機能するかについて少しでも知識があれば、それは自明です。

ただし、大幅なスピードアップが見られる場合は、質問を更新してください。

今日のオールドスクールインクルードガードは、＃pragmaと同じくらい高速です。コンパイラがそれらを特別に処理しなくても、＃ifndef WHATEVERが検出され、WHATEVERが定義されていると、コンパイラは停止します。ファイルを開くことは、今日は安い汚れです。たとえ改善があったとしても、それはミリ秒のオーダーになるでしょう。

#pragmaは一度も使用しないでください。効果がないためです。他のインクルードガードとの衝突を避けるために、CI_APP_MODULE_FILE_H-> CI = Company Initials;のようなものを使用します。APP =アプリケーション名。残りは自明です。

主な違いは、コンパイラがインクルードガードを読み取るためにヘッダーファイルを開かなければならないことです。対照的に、プラグマは一度、コンパイラーがファイルを追跡し、同じファイルの別のインクルードに遭遇したときにファイルIOを実行しません。それは無視できるように聞こえるかもしれませんが、それは巨大なプロジェクトで簡単にスケールアップできます。

とは言っても、最近のコンパイラー（GCCを含む）は、プラグマのようなインクルードガードを一度だけ扱うのに十分スマートです。つまり、ファイルを開かず、ファイルのIOペナルティを回避します。

プラグマをサポートしないコンパイラーでは、少し面倒な手動の実装を見てきました。

#ifdef FOO_H
#include "foo.h"
#endif

#pragmaは、名前の衝突や潜在的な入力ミスの煩わしさを回避できるので、個人的には一度アプローチするのが好きです。比較すると、よりエレガントなコードでもあります。とは言っても、移植可能なコードの場合、コンパイラーがそれについて文句を言わない限り、両方を持つことは害になりません。

msvcまたはQt（最大Qt 4.5）を使用する場合、GCC（最大3.4）、msvcの両方がサポートされているため#pragma once、を使用しない理由はわかりません#pragma once。

ソースファイル名は通常、同じクラス名と同じですが、クラス名を変更するためにリファクタリングが必要になることもあります。その場合は、クラス名も変更する必要があったため、#include XXXX手動での保守は#include xxxxxスマートな作業ではないと思います。Visual Assist X拡張を使用しても、「xxxx」を維持する必要はありません。

ヘッダーファイルの自動1回のみのインクルードが常に望ましいと考える人々への追加の注意：数十年以来、ヘッダーファイルの二重または複数のインクルードを使用してコードジェネレーターをビルドしています。特にプロトコルライブラリスタブの生成については、ツールや言語を追加することなく、非常にポータブルで強力なコードジェネレーターを使用するのが非常に快適です。このブログのX-Macrosが示すように、このスキームを使用しているのは私だけではありません。これは、自動ガードが欠落していなければ不可能です。