#pragmaが一度自動的に想定されないのはなぜですか？

ファイルを1回だけ含めるようにコンパイラーに指示する意味は何ですか？デフォルトでは意味がありませんか？1つのファイルを複数回含める理由はありますか？なぜそれを仮定しないのですか？それは特定のハードウェアと関係がありますか？

ここには複数の関連する質問があります：

• なぜ#pragma once自動的に強制されないのですか？
  ファイルを複数回含めたい場合があるからです。

• ファイルを複数回インクルードしたいのはなぜですか？
  他の回答にはいくつかの理由があります（Boost.Preprocessor、X-Macros、データファイルを含む）。「コードの重複を避ける」という特定の例を追加したいと思います。OpenFOAM#includeは、関数内の断片を一般的な概念にするスタイルを推奨しています。たとえば、この説明を参照してください。

• わかりました、しかしなぜそれがオプトアウトのデフォルトではないのですか？
  それは実際には規格で指定されていないからです。#pragmaは、定義上、実装固有の拡張機能です。

• なぜ#pragma onceまだ標準化された機能になっていないのですか（広くサポートされているため）？
  プラットフォームにとらわれない方法で「同じファイル」を特定することは、実際には驚くほど難しいためです。詳細については、この回答を参照してください。

関数内のように、グローバルスコープだけでなく、ファイル内の#include どこでも使用できます（必要に応じて複数回）。確かに、醜く、良いスタイルではありませんが、可能であり、時には賢明です（含めるファイルによって異なります）。#include一度だけだったら、それはうまくいきません。#include結局のところ、ダムテキストの置換（カットアンドペースト）を行うだけであり、インクルードするすべてがヘッダーファイルである必要はありません。たとえば#include、を初期化するための生データを含む自動生成データを含むファイルがありますstd::vector。お気に入り

std::vector<int> data = {
#include "my_generated_data.txt"
}

また、「my_generated_data.txt」は、コンパイル中にビルドシステムによって生成されるものにします。

または多分私は怠惰/愚か/愚かでこれをファイルに入れます（非常に不自然な例）：

const noexcept;

そして私はします

class foo {
    void f1()
    #include "stupid.file"
    int f2(int)
    #include "stupid.file"
};

もう1つの少し不自然な例は、多くの関数が名前空間で大量の型を使用する必要があるソースファイルですがusing namespace foo;、グローバルな名前空間を他の多くのもので汚してしまうため、グローバルに言いたくないでしょう。あなたはしたくない。したがって、以下を含むファイル「foo」を作成します

using std::vector;
using std::array;
using std::rotate;
... You get the idea ...

そして、あなたはあなたのソースファイルでこれを行います

void f1() {
#include "foo" // needs "stuff"
}

void f2() {
    // Doesn't need "stuff"
}

void f3() {
#include "foo" // also needs "stuff"
}

注：私はこのようなことをすることを推奨していません。しかし、それは可能であり、いくつかのコードベースで行われており、なぜそれが許可されるべきではないのかわかりません。それには用途があります。

また、含めるファイルが特定のマクロ（#defines）の値に応じて異なる動作をする可能性もあります。したがって、最初に値を変更した後、ファイルを複数の場所に含めて、ソースファイルのさまざまな部分でさまざまな動作を取得することができます。

複数回含めることは、たとえばXマクロ手法で使用できます。

data.inc：

X(ONE)
X(TWO)
X(THREE)

use_data_inc_twice.c

enum data_e { 
#define X(V) V,
   #include "data.inc"
#undef X
};
char const* data_e__strings[]={
#define X(V) [V]=#V,
   #include "data.inc"
#undef X
};

他の用途については知りません。

あなたは、言語に存在する「#include」機能の目的が、プログラムを複数のコンパイル単位に分解するためのサポートを提供することであるという仮定の下で操作しているようです。それは正しくありません。

それはその役割を果たすことができますが、それは意図された目的ではありませんでした。Cは元々、PDP- 11Macro-11よりもわずかに高水準の言語として開発されました。、Unixを再実装するためにアセンブリ。Macro-11の機能であるため、マクロプリプロセッサが搭載されていました。新しいCコンパイラに移植していた既存のUnixが利用していたMacro-11の機能であったため、別のファイルのマクロをテキストで含めることができました。

ここで、「＃include」は、（おそらく）ちょっとしたハックとして、コードをコンパイル単位に分割するのに役立つことがわかりました。ただし、このハッキングが存在したという事実は、それがCで行われる方法になったということを意味しました。方法が存在したという事実は、この機能を提供するために新しいメソッドを作成する必要がないことを意味しました。-包含）が作成されました。すでにCに含まれていたため、Cの残りの構文とイディオムのほとんどとともにC ++にコピーされました。

この45年前のプリプロセッサハックをようやく省くことができるように、 C ++に適切なモジュールシステムを提供するという提案があります。しかし、これがどれほど差し迫っているのかはわかりません。私はそれが10年以上の間作業中であると聞いています。

いいえ、これは、たとえば図書館の執筆者が利用できるオプションを大幅に妨げることになります。たとえば、Boost.Preprocessorを使用すると、プリプロセッサループを使用できます。これらを実現する唯一の方法は、同じファイルを複数インクルードすることです。

そして、Boost.Preprocessorは、多くの非常に便利なライブラリの構成要素です。

私が主に取り組んでいる製品のファームウェアでは、関数とグローバル/静的変数をメモリ内のどこに割り当てるかを指定できる必要があります。リアルタイム処理は、プロセッサが直接高速にアクセスできるように、チップ上のL1メモリに常駐する必要があります。重要度の低い処理は、チップ上のL2メモリに入れることができます。また、特に迅速に処理する必要のないものはすべて、外部DDRに存在し、キャッシュを通過できます。これは、少し遅いかどうかは問題ではないためです。

物事が進む場所を割り当てる#pragmaは、長くて重要な行です。間違えるのは簡単でしょう。それを間違えると、コード/データがサイレントにデフォルト（DDR）メモリに入れられ、その影響は、見やすい理由もなく閉ループ制御が機能しなくなる可能性があります。

そのため、そのプラグマだけを含むインクルードファイルを使用します。私のコードは次のようになりました。

ヘッダーファイル...

#ifndef HEADERFILE_H
#define HEADERFILE_H

#include "set_fast_storage.h"

/* Declare variables */

#include "set_slow_storage.h"

/* Declare functions for initialisation on startup */

#include "set_fast_storage.h"

/* Declare functions for real-time processing */

#include "set_storage_default.h"

#endif

そしてソース...

#include "headerfile.h"

#include "set_fast_storage.h"

/* Define variables */

#include "set_slow_storage.h"

/* Define functions for initialisation on startup */

#include "set_fast_storage.h"

/* Define functions for real-time processing */

ヘッダーだけでも、同じファイルが複数含まれていることに気付くでしょう。ここで何かを間違って入力すると、コンパイラはインクルードファイル「set_fat_storage.h」が見つからないことを通知し、簡単に修正できます。

したがって、あなたの質問に答えると、これは複数の包含が必要な場合の実際の実際的な例です。