CおよびC ++プログラミング言語では、山括弧を使用することと引用符を使用することの違いは何ですか。include次のように文、？
#include <filename>
#include "filename"
実際には、違いはプリプロセッサがインクルードファイルを検索する場所です。
にとって#include <filename>プリプロセッサは、通常はコンパイラ/ IDEによってあらかじめ指定された検索ディレクトリで、実装に依存する方法で検索します。このメソッドは通常、標準のライブラリヘッダファイルをインクルードするために使用されます。
にとって#include "filename"プリプロセッサは、最初にディレクティブを含むファイルと同じディレクトリを検索し、次に、そのパスに使用された検索パスをたどります。#include <filename>形。このメソッドは通常、プログラマ定義のヘッダファイルをインクルードするために使用されます。
より完全な説明はGCCにあります。検索パスに関する文書。
#include <...>システムにインストールされているパッケージを使用し、#include "..."近くのリポジトリのバージョンを使用しました。私はそれらを逆にするかもしれません。どちらの方法でも、パッケージ化されたヘッダーのインクルードガードにはアンダースコアが付きます。 （これはパッケージの慣習であるかもしれませんし、2つを混同しないようにするための意図的な方法かもしれませんが、バージョン修飾子は私にとっては意味があります）。 - John P
知る唯一の方法は、実装のドキュメントを読むことです。
にC標準、セクション6.10.2、段落2から4まで：
次の形式の前処理指令
#include <h-char-sequence> new-line実装定義の一連の場所を検索し、指定された順序で一意に識別されるヘッダーを検索します。
<そして>そして、そのディレクティブをヘッダーの内容全体で置き換えます。場所の指定方法や識別されたヘッダーの実装方法は実装によって異なります。次の形式の前処理指令
#include "q-char-sequence" new-line指定されたシーケンスによって識別されるソースファイルの内容全体でそのディレクティブを置き換えます。
"区切り文字指定されたソースファイルは、実装定義の方法で検索されます。この検索がサポートされていない場合、または検索が失敗した場合、ディレクティブは読み取りのように再処理されます。#include <h-char-sequence> new-line同一の含まれているシーケンス（を含む）
>元の文字（ある場合） 指令。次の形式の前処理指令
#include pp-tokens new-line（これは、前の2つの形式のいずれとも一致しません）許可されています。後処理トークン
includeディレクティブの中のは通常のテキストと同じように処理されます。 （現在マクロ名として定義されている各識別子は、前処理トークンの置換リストに置き換えられます。）すべての置換の後に生成される指令は、前の2つの形式のいずれかに一致します。一連の前処理トークンを<そして>前処理トークンペアまたはペアのペア"文字は単一のヘッダ名にまとめられ、前処理トークンは実装定義です。定義：
h-char：改行文字を除くソース文字セットの任意のメンバー
>q-char：改行文字を除くソース文字セットの任意のメンバー
"
<の間の文字シーケンス>ヘッダーを一意に参照します。ヘッダーは必ずしもファイルではありません。実装では、必要に応じて文字シーケンスを自由に使用できます。 （しかし、たいていは単にそれをファイル名として扱い、そしてパスを含める他の記事のように、）
あれば#include "file"formが使用されている場合、サポートされていれば、実装はまず指定された名前のファイルを探します。そうでない（サポートされている）場合、または検索が失敗した場合、実装は他のもののように動作します（#include <file>）形式が使用されました。
また、3番目の形式が存在し、#include指令が上記のいずれの形式とも一致しません。この形式では、いくつかの基本的な前処理（マクロ展開など）が、の "オペランド"に対して行われます。#includeその結果は他の2つの形式のうちの1つと一致すると予想されます。
<そして>ライブラリにインデックスを付けるためのキーとして。 - Adrian McCarthy
ここでいくつかの良い答えはC標準を参照していますが、特にPOSIX標準を忘れていました。c99（Cコンパイラなど）コマンド。
によるオープングループ基本仕様第7号、
-私 ディレクトリ
絶対パス名ではないヘッダーを検索するためのアルゴリズムを、で指定されたディレクトリを検索するように変更します。ディレクトリ通常の場所を見る前のパス名。したがって、名前が二重引用符（ ""）で囲まれているヘッダーは、最初にファイルのディレクトリで検索されます。#含める次に、inという名前のディレクトリに-私オプション、そしていつもの場所で最後に。名前が山括弧（ "<>"）で囲まれているヘッダーの場合、ヘッダーは次の名前のディレクトリ内でのみ検索されます。-私その後、通常の場所でオプションを選択します。で指定されたディレクトリ-私オプションは指定された順序で検索されます。実装は単一のこのオプションの少なくとも10のインスタンスをサポートしなければならないc99コマンド呼び出し
したがって、POSIX準拠のCコンパイラを使用したPOSIX準拠の環境では、#include "file.h"検索する可能性があります./file.hまず、どこで.ファイルがあるディレクトリです。#includeステートメント#include <file.h>、検索する可能性があります/usr/include/file.hまず、どこで/usr/includeあなたのシステムは定義されていますかいつもの場所ヘッダ用（POSIXでは定義されていないようです）。
c99 - CコンパイラのPOSIX名です。 （POSIX 2008標準はC11を参照することはほとんどできませんでした。POSIX2008を2013年に更新しても、参照されていたC標準は変更されませんでした。） - Jonathan Leffler
します：
"mypath/myfile" is short for ./mypath/myfile
と.ファイルのディレクトリである#includeおよび/またはコンパイラの現在の作業ディレクトリに含まれている。default_include_paths
そして
<mypath/myfile> is short for <defaultincludepaths>/mypath/myfile
もし./中です<default_include_paths>それからそれは違いを生じません。
もしmypath/myfile別のインクルードディレクトリにある場合、動作は未定義です。
#include "mypath/myfile"と等価ではありません#include "./mypath/myfile"。 piCookieの答えが言うように、二重引用符はコンパイラに実装定義の方法で検索するように伝えます - これは指定された場所での検索も含みます#include <...>。 （実際には、おそらくそれは同等ですが、例えば、/usr/include/mypath/myfileと呼ぶことができる/usr/include/./mypath/myfile - 少なくともUnixライクなシステムでは） - Keith Thompsondefaultincludepathsに別の意味を与えるのではなく、.（上記参照）これには、#include "..."そして#include <...>で検索ディルパス - Protongun
GCCのドキュメントによると両者の違いについては次のとおりです。
ユーザーヘッダファイルとシステムヘッダファイルの両方が前処理指令を使用してインクルードされます
‘#include’。これには2つの亜種があります。
#include <file>この変種はシステムヘッダファイルに使用されます。システムディレクトリの標準リストでfileという名前のファイルを検索します。このリストの前にディレクトリを追加することができます。
-Iオプション（呼び出し）
#include "file"この変種はあなた自身のプログラムのヘッダファイルに使われます。それは最初に現在のファイルを含んでいるディレクトリの中でfileと名付けられたファイルを検索し、それからquoteディレクトリを検索し、そして次に同じディレクトリを検索します。
<file>。あなたは引用符のディレクトリのリストの前にディレクトリを追加することができます。-iquoteオプション。 の議論‘#include’引用符または山括弧で区切られているかどうかにかかわらず、コメントは認識されず、マクロ名は展開されないという点で、文字列定数のように動作します。したがって、#include <x/*y>という名前のシステムヘッダファイルを含めることを指定します。x/*y。ただし、ファイル内に円記号がある場合、それらは通常のテキスト文字と見なされ、エスケープ文字とは見なされません。 Cの文字列定数に適した文字エスケープシーケンスは処理されません。したがって、
#include "x\n\\y"3つのバックスラッシュを含むファイル名を指定します。 （一部のシステムでは、「\」がパス名の区切り文字として解釈されます。これらもすべて解釈されます‘/’同じ方法。使用するのが最もポータブルです‘/’。）ファイル名の後の行に（コメント以外の）何かがある場合、それはエラーです。
の<file>includeは、プリプロセッサに検索を指示します。-Iディレクトリと定義済みディレクトリ最初次に、.cファイルのディレクトリにあります。の"file"includeは、ソースファイルのディレクトリを検索するようにプリプロセッサに指示します。最初その後に戻る-Iそして定義済み。とにかくすべての目的地が検索され、検索の順序だけが異なります。
2011規格では、ほとんどの場合、「16.2ソースファイルのインクルード」でインクルードファイルについて説明しています。
2形式の前処理指令
# include <h-char-sequence> new-line実装によって定義された一連の場所を検索して、によって一意に識別されるヘッダーを探します <の間の指定されたシーケンスそして>区切り文字 そのディレクティブをヘッダーの内容全体で置き換えます。 場所の指定方法またはヘッダーの識別方法は次のとおりです。 実装定義。
3形式の前処理指令
# include "q-char-sequence" new-lineそのディレクティブを、で指定されたソースファイルの内容全体で置き換えます。 指定されたソースファイルは、 実装定義の方法で検索します。この検索が サポートされていないか、検索が失敗した場合、ディレクティブは次のように再処理されます。 読んだら
# include <h-char-sequence> new-line元のディレクティブからの同一の含まれたシーケンス（もしあれば>文字を含む）。
ご了承ください"xxx"フォームはに劣化する<xxx>ファイルが見つからない場合はform残りは実装定義です。
-Iビジネスは指定されていますか？ - juanchopanza-I。 - juanchopanza
標準では - はい、違います。
次の形式の前処理指令
#include <h-char-sequence> new-line実装定義の一連の場所を検索し、指定された順序で一意に識別されるヘッダーを検索します。
<そして>そして、そのディレクティブをヘッダーの内容全体で置き換えます。場所の指定方法や識別されたヘッダーの実装方法は実装によって異なります。次の形式の前処理指令
#include "q-char-sequence" new-line指定されたシーケンスによって識別されるソースファイルの内容全体でそのディレクティブを置き換えます。
"区切り文字指定されたソースファイルは、実装定義の方法で検索されます。この検索がサポートされていない場合、または検索が失敗した場合、ディレクティブは読み取りのように再処理されます。#include <h-char-sequence> new-line同一の含まれているシーケンス（を含む）
>元の文字（ある場合） 指令。次の形式の前処理指令
#include pp-tokens new-line（これは、前の2つの形式のいずれとも一致しません）許可されています。後処理トークン
includeディレクティブの中のは通常のテキストと同じように処理されます。 （現在マクロ名として定義されている各識別子は、前処理トークンの置換リストに置き換えられます。）すべての置換の後に生成される指令は、前の2つの形式のいずれかに一致します。一連の前処理トークンを<そして>前処理トークンペアまたはペアのペア"文字は単一のヘッダ名にまとめられ、前処理トークンは実装定義です。定義：
h-char：改行文字を除くソース文字セットの任意のメンバー
>q-char：改行文字を除くソース文字セットの任意のメンバー
"
規格は実装定義の方法の間のいかなる関係も伝えないことに注意してください。最初の形式は、ある実装定義の方法で検索し、他の（おそらく他の）実装定義の方法で検索します。この規格では、特定のインクルードファイルが存在することも規定されています（たとえば、<stdio.h>）
正式にはコンパイラのマニュアルを読む必要がありますが、通常は（伝統的に）#include "..."formはファイルが置かれているディレクトリを検索します#include最初に見つかったディレクトリ、そしてそのディレクトリ#include <...>フォーム検索（インクルードパス、システムヘッダーなど）
素晴らしい答えをありがとう、特に。 Adam StelmaszczykとpiCookie、そしてaib。
多くのプログラマーのように、私は非公式の慣習を使っています。"myApp.hpp"アプリケーション固有のファイル用のフォーム<libHeader.hpp>ライブラリとコンパイラのシステムファイルの形式。/IそしてそのINCLUDE環境変数、それが標準であると考えて何年もの間。
ただし、C規格では、検索順序は実装固有であると規定されているため、移植性が複雑になる可能性があります。さらに悪いことに、jamを使います。これは、インクルードファイルがどこにあるかを自動的に判断します。インクルードファイルには相対パスまたは絶対パスを使用できます。すなわち
#include "../../MyProgDir/SourceDir1/someFile.hpp"
MSVSの古いバージョンでは二重のバックスラッシュ（\\）が必要でしたが、現在はそれは必須ではありません。いつ変わったのかわかりません。 'nixとの互換性のためにスラッシュを使うだけです（Windowsはそれを受け入れます）。
あなたがいる場合本当に気になる、使用"./myHeader.h"ソースコードと同じディレクトリにあるインクルードファイルの場合（私の現在の非常に大きなプロジェクトには、インクルードファイルの名前が重複しています - 実際には構成管理の問題です）。
これがMSDNの説明あなたの便宜のためここにコピーしてください）。
引用形式
プリプロセッサは次の順序でインクルードファイルを検索します。
- #includeステートメントを含むファイルと同じディレクトリにあります。
- 現在開いているインクルードファイルのディレクトリでは、逆の順序で
彼らは開かれました。検索は、親インクルードファイルのディレクトリから開始されます。
任意の祖父母のインクルードファイルのディレクトリを通って上方向に続きます。- それぞれで指定されたパスに沿って
/Iコンパイラオプション- で指定されたパスに沿って
INCLUDE環境変数山かっこ形式
プリプロセッサは次の順序でインクルードファイルを検索します。
- それぞれで指定されたパスに沿って
/Iコンパイラオプション- コマンドラインで、コンパイルで指定されたパスに沿ってコンパイルが行われる場合
INCLUDE環境変数
少なくともGCCバージョン< = 3.0では、山括弧形式はインクルードファイルとインクルードファイルの間に依存関係を生成しません。
したがって、（GCCの-Mオプションを使用して）依存関係規則を生成したい場合は、依存関係ツリーに含める必要があるファイルに引用符付きの形式を使用する必要があります。
にとって#include ""コンパイラは通常、そのインクルードを含むファイルのフォルダを検索し、次に他のフォルダを検索します。にとって#include <>コンパイラは現在のファイルのフォルダを検索しません。
<filename>そして"filename"実装定義の場所を検索します。 - Maxim Egorushkin
#include <file.h>「includes」ディレクトリでヘッダを検索するようにコンパイラに指示します。 MinGWの場合、コンパイラは以下を検索します。file.hC：\ MinGW \ include \またはコンパイラがインストールされている場所にあります。
#include "file"現在のディレクトリ（つまり、ソースファイルが存在するディレクトリ）を検索するようにコンパイラに指示します。file。
あなたが使用することができます-IGCCが山括弧付きのインクルードに遭遇したときには、ディレクトリのヘッダーも検索する必要があることを伝えるためのフラグです。-I。 GCCはフラグの後のディレクトリをまるでそれがincludesディレクトリ。
たとえば、というファイルがあるとします。myheader.hあなた自身のディレクトリでは、あなたは言うことができる#include <myheader.h>フラグを付けてGCCを呼び出した場合-I .（現在のディレクトリでインクルードを検索する必要があることを示します。）
なしで-Iフラグは、あなたが使用する必要があります#include "myheader.h"ファイルを含める、または移動するmyheader.hにincludeあなたのコンパイルのディレクトリ。
#include <>定義済みヘッダファイル用ヘッダファイルが事前定義されているならば、あなたは単に角括弧でヘッダファイル名を書くでしょう、そしてそれは（我々が事前定義されたヘッダファイル名iostreamを持っていると仮定すると）このようになります：
#include <iostream>
#include " "プログラマが定義するヘッダファイル用です。あなた（プログラマー）があなた自身のヘッダファイルを書いたなら、あなたは引用符でヘッダファイル名を書くでしょう。それで、あなたがと呼ばれるヘッダファイルを書いたとしましょう。myfile.hそれでは、includeディレクティブを使ってそのファイルをインクルードする方法の例です。
#include "myfile.h"
山括弧を含む#includeは、インクルードされるファイルについて「実装依存の場所のリスト」（これは「システムヘッダー」と言うのは非常に複雑な方法です）を検索します。
引用符を含む#includeはファイルを検索するだけです（そして、「実装依存の方法で」、bleh）。これは、通常の英語では、あなたがそれに投げかけたパス/ファイル名を適用しようとし、そうでなければシステムパスを追加したり改ざんしたりしないことを意味します。
また、#include ""が失敗した場合、標準では#include<>として再読み込みされます。
のgccのドキュメントこれはgccに固有のもので標準ではありませんが、ISO標準の弁護士形式の話よりもはるかに理解しやすいものです。
zlib.h私の'ユーザー'で検索パスで、システム検索パスに異なるバージョンが存在する#include <zlib.h>システムのバージョンを含める#include "zlib.h"私自身を含めますか？ - the_mandrill
#include< filename>を使用すると、プリプロセッサはC \ C ++ヘッダーファイルのディレクトリ（stdio.h \ cstdio、string、vectorなど）でファイルを探します。しかし、あなたが#include "filename"を使用するとき：最初に、プリプロセッサは現在のディレクトリでファイルを探します、そしてそれがここにないなら - 彼はそれをC \ C ++ヘッダファイルのディレクトリで探します。
#includeディレクティブはファイルと完全には関連していません。 - IInspectable
ここでの回答の多くは、ファイルを見つけるためにコンパイラが検索するパスに焦点を当てています。これはほとんどのコンパイラが行うことですが、規格準拠のコンパイラは標準ヘッダの効果で事前にプログラムすることができ、そして次のように扱うことができます。#include <list>スイッチとして、そしてそれはまったくファイルとして存在する必要はありません。
これは純粋に仮説ではありません。そのように動作するコンパイラが少なくとも1つあります。を使う#include <xxx>標準ヘッダーのみを使用することをお勧めします。
#include "filename" // User defined header
#include <filename> // Standard library header.
例：
ここでのファイル名はSeller.h：
#ifndef SELLER_H // Header guard
#define SELLER_H // Header guard
#include <string>
#include <iostream>
#include <iomanip>
class Seller
{
private:
char name[31];
double sales_total;
public:
Seller();
Seller(char[], double);
char*getName();
#endif
クラス実装では（例えば、Seller.cpp、およびそのファイルを使用する他のファイル内Seller.h次のように、ユーザーが定義したヘッダーを含める必要があります。
#include "Seller.h"
#include <abc.h>
標準ライブラリファイルをインクルードするために使用されます。そのため、コンパイラは標準ライブラリヘッダが存在する場所をチェックします。
#include "xyz.h"
ユーザー定義のヘッダーファイルをインクルードするようコンパイラーに指示します。そのため、コンパイラは現在のフォルダでこれらのヘッダファイルをチェックします。-I定義済みフォルダ
C ++では、2つの方法でファイルをインクルードします。
最初のものは#includeで、事前に定義されたデフォルトの場所でファイルを探すようにプリプロセッサに指示します。 この場所は、多くの場合、ファイルを含めるパスを示すINCLUDE環境変数です。
そして2番目のタイプは#include "filename"です。これは最初に現在のディレクトリでファイルを探すようにプリプロセッサに指示し、次にユーザーが設定した事前定義された場所でそれを探すように指示します。
"< filename>"は標準Cライブラリの場所を検索します
一方、 "filename"は現在のディレクトリも検索します。
理想的には、標準のCライブラリには< ...>を使用し、作成して現在のディレクトリに存在するライブラリには "..."を使用します。
の#include <filename>システムファイルが参照されているときに使用されます。これは、次のようなシステムのデフォルトの場所にあるヘッダーファイルです。/usr/includeまたは/usr/local/include。あなた自身のファイルを他のプログラムに含める必要がある場合は、#include "filename"構文。
単純な一般規則は、コンパイラーに付属のヘッダーファイルを含めるために山括弧を使用することです。他のヘッダーファイルを含めるには二重引用符を使用します。ほとんどのコンパイラはこのようにしています。
1.9 - ヘッダファイルプリプロセッサディレクティブについてより詳細に説明します。あなたが初心者のプログラマーであれば、そのページはあなたがそれらすべてを理解するのを助けるべきです。私はここからそれを学びました、そして私は仕事でそれに従っていました。
#include <filename>
C / C ++システムまたはコンパイラライブラリのヘッダファイルを使用したい場合に使用します。これらのライブラリはstdio.h、string.h、math.hなどです。
#include "path-to-file/filename"
プロジェクトフォルダまたは他の場所にある独自のカスタムヘッダファイルを使用する場合に使用されます。
プリプロセッサとヘッダの詳細については。読むC - プリプロセッサ。
まず、ディレクティブが呼び出された場所から、現在のディレクトリ内のヘッダーファイルの存在を探します。見つからない場合は、事前設定されている標準システムディレクトリのリストを検索します。
これは、ディレクティブが呼び出された場所から現在のディレクトリ内のヘッダファイルの存在を探します。
正確な検索ディレクトリリストは、ターゲットシステム、GCCの設定方法、およびインストール場所によって異なります。 GCCコンパイラの検索ディレクトリリストは、-vオプションを付けて実行すると見つけることができます。
- Iを使用すると、検索パスにディレクトリを追加できます。君これにより、dirは現在のディレクトリ（ディレクティブの引用形式）の後で、標準のシステムディレクトリの前に検索されます。
基本的に、 "xxx"という形式は現在のディレクトリを検索することに他なりません。フォームからのフォールバックが見つからない場合
現在の設定に基づいてgccを使用してシステムの検索順序を確認するには、次のコマンドを実行します。このコマンドの詳細を見つけることができますここに
cpp -v /dev/null -o /dev/null
Apple LLVMバージョン10.0.0（clang-1000.10.44.2）
ターゲット：x86_64-apple-darwin18.0.0
スレッドモデル：posixインストールディレクトリ：Library / Developer / CommandLineTools / usr / bin
"/ライブラリ/ Developer / CommandLineTools / usr / bin / clang" -cc1 -triple x86_64-apple-macosx10.14.0 -Wdeprecated-objc-isa-usage -Werror = deprecated-objc-isa-usage -E -disable-free -disable-llvm-verifier -discard値名-mainファイル名null -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable -fp-elim -fno-strict-return -masm-verbose -munwind-tables -target-cpu penryn -dwarf-column-info -debugger-tuning = lldb -target-linker-version 409.12 -v -resource-dir /Library/Developer/CommandLineTools/usr/lib/clang/10.0.0 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -I / usr / local / include -fdebug-compilation-dir / Users / hogstrom -ferror-limit 19 -fメッセージ長80 -stack-protector 1 -fブロック-fencode-extended-block-signature -fobjc-runtime = macosx- 10.14.0 -fmax-type-align = 16 -f診断診断表示オプション-fcolor診断-traditional-cpp -o - -xc / dev / null
clang -cc1バージョン10.0.0（clang-1000.10.44.2）デフォルトターゲットx86_64-apple-darwin18.0.0無視 存在しないディレクトリ "/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/local/include" 存在しないディレクトリ "/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/Library/Frameworks"を無視する
#include "..."検索はここから始まります。
#include< ...>検索はここから始まります。
/ usr / local / include
/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0/include
/ Library / Developer / CommandLineTools / usr / include
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks（フレームワークディレクトリ）
検索リストの終わり
#include <filename> (1)
#include "filename" (2)
#includefilenameで識別されるソースファイルを、ディレクティブの直後の行にある現在のソースファイルに含めます。
ディレクティブの最初のバージョンでは、標準インクルードのみが検索されます。 ディレクトリ標準C ++ライブラリと標準Cライブラリ 暗黙的に標準インクルードディレクトリに含まれます。標準 インクルードディレクトリは、コンパイラを介してユーザーが制御できます。 オプション
2番目のバージョンは最初に現在のファイルがあるディレクトリを検索します ファイルが見つからない場合に限り、標準ファイルを検索します。 ディレクトリを含めます。
ファイルが見つからない場合、プログラムは不正な形式です。
#include文を書くには2つの方法があります。
#include"filename"
#include<filename>
各形式の意味は
#include"mylib.h"
このコマンドはファイルを探しますmylib.h現在のディレクトリと、指定されたディレクトリのリストに含まれています。
#include<mylib.h>
このコマンドはファイルを探しますmylib.h指定されたディレクトリのリスト内のみ。
インクルード検索パスは、インクルードされているファイルを検索するディレクトリのリストに他なりません。異なるCコンパイラでは、検索パスをさまざまな方法で設定できます。
二重引用符で囲まれたヘッダーは、現在のディレクトリで見つからない場合、山括弧付きのインクルードと同じシステムパスで検索されます。
#include <filename>
C ++ライブラリから対応するファイルを見つけます。
C ++ライブラリフォルダにhello.hというファイルがある場合は、#include <hello.h>それをロードします。
しかし、
#include "filename"
ソースファイルと同じディレクトリにファイルが見つかります。
加えて、
#include "path_to_file/filename"
あなたがタイプしたディレクトリでファイルを見つけるでしょうpath_to_file。
検索ヘッダーファイルの順序は異なります。 < XXX.h>は最初に標準ヘッダを検索し、 "XXX.h"は最初にワークスペースのヘッダファイルを検索します。
-Lgccのヘッダ - Ezio-Lヘッダ"独特です。の-Loptionは、ライブラリではなくヘッダの場所を指定します。 - Jonathan Leffler