#include의 차이점은 무엇입니까?<filename> 및 #include "파일 이름"?

질문자 :quest49

C 및 C++ 프로그래밍 언어에서 다음과 같이 include 문에서 따옴표를 사용하는 것의 차이점은 무엇입니까?

1. #include <filename>
2. #include "filename"

실제로 차이는 전처리기가 포함된 파일을 검색하는 위치에 있습니다.

#include <filename> 경우 전처리기는 일반적으로 컴파일러/IDE에서 미리 지정한 검색 디렉토리에서 구현 종속적인 방식으로 검색합니다. 이 방법은 일반적으로 표준 라이브러리 헤더 파일을 포함하는 데 사용됩니다.

#include "filename" 경우 전처리기는 지시문이 포함된 파일과 동일한 디렉토리에서 먼저 검색한 다음 #include <filename> 형식에 사용된 검색 경로를 따릅니다. 이 방법은 일반적으로 프로그래머가 정의한 헤더 파일을 포함하는 데 사용됩니다.

보다 완전한 설명은 검색 경로 에 대한 GCC 문서에서 볼 수 있습니다.

quest49

알 수 있는 유일한 방법은 구현 문서를 읽는 것입니다.

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

  (이전의 두 형식 중 하나와 일치하지 않음)이 허용됩니다. include 된 후의 전처리 토큰은 일반 텍스트와 동일하게 처리됩니다. (현재 매크로 이름으로 정의된 각 식별자는 전처리 토큰의 대체 목록으로 대체됩니다.) 모든 대체 후 생성되는 지시문은 이전 두 형식 중 하나와 일치해야 합니다. < 및 > 전처리 토큰 쌍 또는 " 문자 쌍 사이의 일련의 전처리 토큰이 단일 헤더 이름 전처리 토큰으로 결합되는 방법은 구현에 정의됩니다.

정의:

• h-char: 개행 문자 및 >

• q-char: 개행 문자 및 "

piCookie

< 및 > 사이의 문자 시퀀스는 반드시 파일일 필요는 없는 헤더를 고유하게 참조합니다. 구현은 원하는 대로 문자 시퀀스를 거의 자유롭게 사용할 수 있습니다. (그러나 대부분은 파일 이름으로 처리하고 다른 게시물 상태와 같이 포함 경로에서 검색을 수행합니다.)

#include "file" 형식을 사용하는 경우 구현은 지원되는 경우 먼저 지정된 이름의 파일을 찾습니다. 지원되지 않거나 검색이 실패하면 구현은 다른( #include <file> ) 형식이 사용된 것처럼 작동합니다.

또한 세 번째 형식이 존재하며 #include 지시문이 위의 형식과 일치하지 않을 때 사용됩니다. 이 형식에서 일부 기본 전처리(예: 매크로 확장)는 #include 지시문의 "피연산자"에 대해 수행되며 결과는 다른 두 형식 중 하나와 일치할 것으로 예상됩니다.

aib

여기에 있는 좋은 답변 중 일부는 C 표준을 참조하지만 POSIX 표준, 특히 c99(예: C 컴파일러) 명령의 특정 동작을 잊어버렸습니다.

Open Group Base Specification Issue 7 에 따르면,

-나는 디렉토리

이름이 절대 경로명이 아닌 헤더를 검색하는 알고리즘을 변경하여 일반적인 위치를 찾기 전에 디렉터리 경로 이름으로 명명된 디렉터리를 찾습니다. 따라서 이름이 큰따옴표( "" )로 묶인 헤더는 #include 행이 있는 파일의 디렉토리에서 먼저 검색한 다음 -I 옵션으로 명명된 디렉토리에서 검색하고 일반적인 위치에서 마지막으로 검색합니다. 이름이 꺾쇠 괄호( "<>" )로 묶인 헤더의 경우 헤더는 -I 옵션으로 명명된 디렉토리에서만 검색한 다음 일반적인 위치에서 검색합니다. -I 옵션에 이름이 지정된 디렉토리는 지정된 순서대로 검색됩니다. 구현은 단일 c99 명령 호출에서 이 옵션의 최소 10개 인스턴스를 지원해야 합니다.

따라서 POSIX 호환 환경에서 POSIX 호환 C 컴파일러를 사용하면 #include "file.h" ./file.h 먼저 검색할 가능성이 높습니다 . #include 문이 있는 파일이 있는 디렉토리이고 #include <file.h> /usr/include/file.h 먼저 검색할 가능성이 높습니다. 여기서 /usr/include 는 시스템에서 정의한 일반적인 위치 입니다. 헤더(POSIX에서 정의하지 않은 것 같습니다).

Yann Droneaud

GCC 문서 에는 둘의 차이점에 대해 다음과 같이 나와 있습니다.

사용자 및 시스템 헤더 파일은 모두 전처리 지시문 '#include' 사용하여 포함됩니다. 두 가지 변형이 있습니다.

#include <file>

이 변형은 시스템 헤더 파일에 사용됩니다. 시스템 디렉토리의 표준 목록에서 file이라는 파일을 검색합니다. -I 옵션을 사용하여 이 목록에 디렉토리를 추가할 수 있습니다 ( 호출 참조).

#include "file"

이 변형은 자체 프로그램의 헤더 파일에 사용됩니다. 현재 파일이 포함된 디렉토리에서 file이라는 이름의 파일을 먼저 검색한 다음 인용 디렉토리에서 검색한 다음 <file> 사용된 동일한 디렉토리에서 검색합니다. -iquote 옵션을 사용하여 인용 디렉토리 목록에 디렉토리를 추가할 수 있습니다. '#include' 인수는 따옴표로 구분하든 꺾쇠 괄호로 구분하든 주석이 인식되지 않고 매크로 이름이 확장되지 않는다는 점에서 문자열 상수처럼 작동합니다. 따라서 #include <x/*y> x/*y 라는 시스템 헤더 파일을 포함하도록 지정합니다.

그러나 파일 내에서 백슬래시가 발생하면 이스케이프 문자가 아닌 일반 텍스트 문자로 간주됩니다. C의 문자열 상수에 적합한 문자 이스케이프 시퀀스는 처리되지 않습니다. 따라서 #include "x\n\\y" 는 세 개의 백슬래시가 포함된 파일 이름을 지정합니다. (일부 시스템은 경로 구분 기호로 '\'해석한다.이 모든도 해석 '/' 와 동일한 방법. 단지 사용하는 대부분의 휴대용 '/' .)

파일명 뒤의 줄에 주석 이외의 것이 있으면 오류입니다.

Suraj Jain

전처리기의 정확한 동작은 컴파일러마다 다릅니다. 다음 답변은 GCC 및 기타 여러 컴파일러에 적용됩니다.

#include <file.h> 는 컴파일러가 "includes" 디렉토리에서 헤더를 검색하도록 지시합니다. 예를 들어 MinGW의 경우 컴파일러는 C:\MinGW\include\ 또는 컴파일러가 설치된 곳에서 file.h

#include "file" 은 컴파일러에게 file 에 대한 현재 디렉토리(즉, 소스 파일이 있는 디렉토리)를 검색하도록 지시 file .

-I 플래그를 사용하여 -I 뒤의 디렉토리에서 헤더도 검색해야 함을 알릴 수 있습니다. GCC는 플래그 뒤의 디렉토리를 includes 디렉토리인 것처럼 취급합니다.

예를 들어 자신의 디렉토리에 myheader.h 라는 파일이 있는 -I . GCC를 호출했다면 #include <myheader.h> (현재 디렉토리에서 포함을 검색해야 함을 나타냅니다.)

-I 플래그가 없으면 #include "myheader.h" 를 사용하여 파일을 포함하거나 myheader.h 를 include 디렉토리로 이동해야 합니다.

adrian

그렇습니다:

 "mypath/myfile" is short for ./mypath/myfile

와 . #include 가 포함된 파일의 디렉토리 및/또는 컴파일러의 현재 작업 디렉토리 및/또는 default_include_paths

그리고

 <mypath/myfile> is short for <defaultincludepaths>/mypath/myfile

./ 이 <default_include_paths> 에 있으면 차이가 없습니다.

mypath/myfile 이 다른 포함 디렉토리에 있으면 동작이 정의되지 않습니다.

Stefan Steiger

<file> -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> 나머지는 구현에서 정의합니다.

user3458

표준에 따라 - 예, 다릅니다.

• 형식의 전처리 지시문

   #include <h-char-sequence> new-line

  < 및 > 구분 기호 사이의 지정된 시퀀스에 의해 고유하게 식별되는 헤더에 대해 구현 정의 위치 시퀀스를 검색하고 헤더의 전체 내용으로 해당 지시문을 대체합니다. 장소가 지정되거나 식별된 헤더가 구현 정의되는 방법입니다.

• 형식의 전처리 지시문

   #include "q-char-sequence" new-line

  " 구분 기호 사이의 지정된 시퀀스로 식별되는 소스 파일의 전체 내용으로 해당 지시문을 대체합니다. 명명된 소스 파일은 구현 정의 방식으로 검색됩니다. 이 검색이 지원되지 않거나 검색이 실패한 경우 , 지시문은 읽은 것처럼 다시 처리됩니다.

   #include <h-char-sequence> new-line

  원래 지시문에서 동일한 포함된 시퀀스(있는 > 문자 포함)를 사용합니다.

• 형식의 전처리 지시문

   #include pp-tokens new-line

  (이전의 두 형식 중 하나와 일치하지 않음)이 허용됩니다. include 된 후의 전처리 토큰은 일반 텍스트와 동일하게 처리됩니다. (현재 매크로 이름으로 정의된 각 식별자는 전처리 토큰의 대체 목록으로 대체됩니다.) 모든 대체 후 생성되는 지시문은 이전 두 형식 중 하나와 일치해야 합니다. < 및 > 전처리 토큰 쌍 또는 " 문자 쌍 사이의 일련의 전처리 토큰이 단일 헤더 이름 전처리 토큰으로 결합되는 방법은 구현에 정의됩니다.

정의:

• h-char: 개행 문자 및 >

• q-char: 개행 문자 및 "

표준은 구현 정의 방식 간의 관계를 말하지 않습니다. 첫 번째 형식은 하나의 구현 정의 방식으로 검색하고 다른 하나는 (아마도 다른) 구현 정의 방식으로 검색합니다. 표준은 또한 특정 포함 파일이 있어야 한다고 지정합니다(예: <stdio.h> ).

공식적으로는 컴파일러 설명서를 읽어야 하지만 일반적으로 (전통적으로) #include "..." #include 가 먼저 발견된 파일의 디렉토리를 검색 #include <...> 양식 검색(포함 경로, 예: 시스템 헤더).

skyking

적어도 GCC 버전 <= 3.0의 경우 꺾쇠 괄호 형식은 포함된 파일과 포함된 파일 사이에 종속성을 생성하지 않습니다.

따라서 종속성 규칙을 생성하려면(예를 들어 GCC -M 옵션을 사용하여) 종속성 트리에 포함되어야 하는 파일에 대해 인용된 형식을 사용해야 합니다.

( http://gcc.gnu.org/onlinedocs/cpp/Invocation.html 참조 )

Denis Ros

훌륭한 답변에 감사드립니다. Adam Stelmaszczyk 및 piCookie 및 aib.

많은 프로그래머와 마찬가지로 나는 응용 프로그램 특정 파일에 대해 "myApp.hpp" 형식을 사용하고 라이브러리 및 컴파일러 시스템 파일, 즉 /I 및 INCLUDE 환경 변수에 <libHeader.hpp> 형식을 사용하는 비공식 규칙을 사용했습니다. , 몇 년 동안 그것이 표준이라고 생각했습니다.

그러나 C 표준에서는 검색 순서가 구현에 따라 다르므로 이식성을 복잡하게 만들 수 있다고 명시합니다. 설상가상으로 우리는 포함 파일의 위치를 자동으로 파악하는 jam을 사용합니다. 포함 파일에 대해 상대 또는 절대 경로를 사용할 수 있습니다. 즉

 #include "../../MyProgDir/SourceDir1/someFile.hpp"

이전 버전의 MSVS에는 이중 백슬래시(\\)가 필요했지만 이제는 필요하지 않습니다. 언제 바뀌었는지 모르겠네요. 'nix'와의 호환성을 위해 슬래시를 사용하기만 하면 됩니다(Windows에서 허용).

그것이 정말로 걱정된다면 "./myHeader.h" 를 사용하십시오(내 현재 매우 큰 프로젝트에는 일부 중복 포함 파일 이름이 흩어져 있습니다. 실제로 구성 관리 문제입니다. ).

편의를 위해 여기에 복사한 MSDN 설명이 있습니다.

인용된 양식

전처리기는 다음 순서로 포함 파일을 검색합니다.

1. #include 문이 포함된 파일과 동일한 디렉터리에 있습니다.
2. 현재 열려 있는 포함 파일의 디렉토리에서 역순으로
   그들은 열렸습니다. 검색은 상위 포함 파일의 디렉토리에서 시작되고
   모든 조부모 포함 파일의 디렉토리를 통해 위쪽으로 계속됩니다.
3. /I 컴파일러 옵션에 의해 지정된 경로를 따라.
4. INCLUDE 환경 변수에 의해 지정된 경로를 따라.

꺾쇠 괄호 형식

전처리기는 다음 순서로 포함 파일을 검색합니다.

1. /I 컴파일러 옵션에 의해 지정된 경로를 따라.
2. INCLUDE 환경 변수로 지정된 경로를 따라 명령줄에서 컴파일이 발생합니다.

riderBill

#include "" 경우 컴파일러는 일반적으로 해당 포함을 포함하는 파일의 폴더를 검색한 다음 다른 폴더를 검색합니다. #include <> 경우 컴파일러는 현재 파일의 폴더를 검색하지 않습니다.

Maxim Egorushkin

꺾쇠 괄호가 있는 #include는 포함할 파일에 대해 "구현 종속 위치 목록"("시스템 헤더"를 말하는 매우 복잡한 방법)을 검색합니다.

따옴표가 있는 #include는 파일을 검색합니다("구현 종속 방식으로", bleh). 즉, 일반 영어에서는 사용자가 던진 경로/파일 이름을 적용하려고 시도하고 시스템 경로를 앞에 추가하거나 변경하지 않습니다.

또한 #include ""가 실패하면 표준에 따라 #include <>로 다시 읽습니다.

gcc 문서 에는 (컴파일러별) 설명이 있습니다. 이 설명은 표준이 아니라 gcc에만 해당되지만 ISO 표준에 대한 변호사 스타일의 이야기보다 훨씬 이해하기 쉽습니다.

Damon

#include <filename>을 사용하면 전처리기가 C\C++ 헤더 파일(stdio.h\cstdio, string, vector 등)의 디렉토리에서 파일을 찾습니다. 그러나 #include "filename":을 사용하면 먼저 전처리기가 현재 디렉토리에서 파일을 찾고, 여기에 없으면 C\C++ 헤더 파일의 디렉토리에서 파일을 찾습니다.

Chayim Friedman

여기에 있는 많은 답변은 파일을 찾기 위해 컴파일러가 검색할 경로에 중점을 둡니다. 이것이 대부분의 컴파일러가 하는 일이지만 준수 컴파일러는 표준 헤더의 효과로 사전 프로그래밍되고 #include <list> 를 스위치로 취급할 수 있으며 파일로 존재할 필요가 전혀 없습니다.

이것은 순전히 가설이 아닙니다. 그런 식으로 작동하는 컴파일러가 하나 이상 있습니다. 표준 헤더에만 #include <xxx> 사용하는 것이 좋습니다.

sp2danny

• #include <> 는 미리 정의된 헤더 파일용입니다.

헤더 파일이 사전 정의된 경우 헤더 파일 이름을 꺾쇠 괄호로 묶으면 다음과 같이 표시됩니다(미리 정의된 헤더 파일 이름 iostream이 있다고 가정).

 #include <iostream>

• #include " " 는 프로그래머가 정의하는 헤더 파일용입니다.

당신(프로그래머)이 자신의 헤더 파일을 작성했다면 헤더 파일 이름을 따옴표로 묶을 것입니다. myfile.h 라는 헤더 파일을 작성했다고 가정하면 다음은 해당 파일을 포함하기 위해 include 지시문을 사용하는 방법의 예입니다.

 #include "myfile.h"

AndroidDev

#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"

Barbara

#include <abc.h>

표준 라이브러리 파일을 포함하는 데 사용됩니다. 따라서 컴파일러는 표준 라이브러리 헤더가 있는 위치를 확인합니다.

 #include "xyz.h"

컴파일러에 사용자 정의 헤더 파일을 포함하도록 지시합니다. -I 정의된 폴더에서 이러한 헤더 파일을 확인합니다.

Christy Wald

C++에서는 다음 두 가지 방법으로 파일을 포함합니다.

첫 번째는 사전 처리기에서 미리 정의된 기본 위치에서 파일을 찾도록 지시하는 #include입니다. 이 위치는 파일을 포함할 경로를 나타내는 INCLUDE 환경 변수인 경우가 많습니다.

그리고 두 번째 유형은 #include "filename"으로 전처리기에게 먼저 현재 디렉토리에서 파일을 찾은 다음 사용자가 설정한 미리 정의된 위치에서 파일을 찾도록 지시합니다.

virat

#include <filename> 은 시스템 파일을 참조할 때 사용됩니다. /usr/include 또는 /usr/local/include 와 같은 시스템 기본 위치에서 찾을 수 있는 헤더 파일입니다. 다른 프로그램에 포함되어야 하는 자체 파일의 경우 #include "filename" 구문을 사용해야 합니다.

srsci

간단한 일반 규칙은 꺾쇠 괄호를 사용하여 컴파일러와 함께 제공되는 헤더 파일을 포함하는 것입니다. 다른 헤더 파일을 포함하려면 큰따옴표를 사용하십시오. 대부분의 컴파일러는 이렇게 합니다.

1.9 — 헤더 파일 은 전처리기 지시문에 대해 자세히 설명합니다. 당신이 초보 프로그래머라면 그 페이지가 모든 것을 이해하는 데 도움이 될 것입니다. 여기에서 배웠고 직장에서 그것을 따르고 있습니다.

Eakan Gopalakrishnan

" < filename > "은 표준 C 라이브러리 위치에서 검색합니다.

반면 "filename"은 현재 디렉토리에서도 검색합니다.

이상적으로는 표준 C 라이브러리에 대해 <...>를 사용하고 현재 디렉토리에 있는 작성하고 있는 라이브러리에 "..."를 사용합니다.

jigar karangiya

#include <filename>

• 전처리기는 구현에 따라 검색합니다. 시스템 헤더 파일이 있는 디렉토리를 검색하도록 컴파일러에 지시합니다.
• 이 방법은 일반적으로 표준 헤더 파일을 찾는 데 사용합니다.

#include "filename"

• 이것은 컴파일러에게 프로그램이 실행 중인 헤더 파일을 검색하도록 지시합니다. 실패한 경우 #include <filename> 과 같이 동작하고 시스템 헤더 파일이 저장된 위치에서 해당 헤더 파일을 검색합니다.
• 이 방법은 일반적으로 사용자 정의 헤더 파일(사용자가 생성한 헤더 파일)을 식별하는 데 사용됩니다. #include <filename> 보다 컴파일 시간이 더 오래 걸리기 때문에 표준 라이브러리를 호출하려는 경우에는 이것을 사용하지 마십시오.

Kalana

양식 1 - #포함 < xxx >

먼저 지시문이 호출되는 현재 디렉토리에 헤더 파일이 있는지 찾습니다. 찾을 수 없으면 표준 시스템 디렉토리의 미리 구성된 목록에서 검색합니다.

양식 2 - # "xxx" 포함

이것은 지시문이 호출되는 현재 디렉토리에서 헤더 파일의 존재를 찾습니다.

---

정확한 검색 디렉토리 목록은 대상 시스템, GCC 구성 방법 및 설치 위치에 따라 다릅니다. -v 옵션과 함께 실행하여 GCC 컴파일러의 검색 디렉토리 목록을 찾을 수 있습니다.

- I dir 을 사용하여 검색 경로에 추가 디렉토리를 추가할 수 있습니다. 이렇게 하면 dir이 현재 디렉토리 뒤(지시어의 따옴표 형식)와 표준 시스템 디렉토리 앞에서 검색됩니다.

---

기본적으로 "xxx" 형식은 현재 디렉토리에서 검색하는 것뿐입니다. 양식을 찾지 못한 경우

Darshan L

#include <filename>

C/C++ 시스템이나 컴파일러 라이브러리의 헤더 파일을 사용하고자 할 때 사용합니다. 이러한 라이브러리는 stdio.h, string.h, math.h 등이 될 수 있습니다.

#include "path-to-file/filename"

프로젝트 폴더 또는 다른 위치에 있는 사용자 정의 헤더 파일을 사용하려는 경우에 사용됩니다.

전처리기 및 헤더에 대한 자세한 내용은 C-전처리기 읽기.

Hafiz Shehbaz Ali

현재 구성을 기반으로 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 InstalledDir: Library/Developer/CommandLineTools/usr/bin
"/라이브러리/개발자/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-value-names -main-file-name 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 -fmessage-length 80 -stack-protector 1 -fblocks -fencode-extended-block-signature -fobjc-runtime=macosx-10.14.0 -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -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/usrignoring/local/include" 디렉토리 "/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/Library/Frameworks"
#include "..." 검색은 여기에서 시작됩니다.
#include <...> 검색은 여기에서 시작됩니다.
/usr/로컬/포함
/라이브러리/개발자/CommandLineTools/usr/lib/clang/10.0.0/include
/라이브러리/개발자/CommandLineTools/usr/include
/라이브러리/개발자/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks (프레임워크 디렉토리)
검색 목록 끝.

Hogstrom

일반적으로 차이점은 전처리기가 헤더 파일을 검색하는 위치입니다.

#include는 헤더 파일을 포함하는 전처리기 지시문입니다. #include는 모두 프로그램에 헤더 파일을 추가하거나 포함하는 데 사용되지만 먼저 시스템 헤더 파일을 포함하고 나중에 사용자 정의 헤더 파일에 대해 하나를 포함합니다.

1. #include <filename> 은 프로그램에 시스템 라이브러리 헤더 파일을 포함하는 데 사용되며, 이는 C/C++ 전처리기가 C 라이브러리 파일이 저장되거나 미리 정의된 시스템 헤더 파일이 저장된 파일 이름을 검색한다는 것을 의미합니다.
2. #include "filename" 은 프로그램에 사용자 정의 헤더 파일을 포함하는 데 사용됩니다. 즉, C/C++ 전처리기가 프로그램이 있는 현재 디렉토리에서 파일 이름을 검색한 다음 #include <filename>에 사용되는 검색 경로를 따릅니다.

gcc 문서 gcc 포함 파일 확인

Saptarshi das

"" 는 ./ 먼저 검색합니다. 그런 다음 기본 포함 경로를 검색합니다. 다음과 같은 명령을 사용하여 기본 포함 경로를 인쇄할 수 있습니다.

 gcc -v -oa ac

다음은 좀 더 명확하게 하기 위한 몇 가지 예입니다. 코드 ac가 작동합니다.

 // ac #include "stdio.h" int main() { int a = 3; printf("a = %d\n", a); return 0; }

bc의 코드도 작동합니다

 // bc #include <stdio.h> int main() { int a = 3; printf("a = %d\n", a); return 0; }

하지만 현재 디렉토리에 stdio.h 라는 새 파일을 만들 때

 // stdio.h inline int foo() { return 10; }

ac 는 컴파일 오류를 생성하지만 bc 여전히 작동합니다.

및 "", <>는 동일한 파일 이름으로 함께 사용할 수 있습니다. 검색 경로 우선 순위가 다르기 때문입니다. 그래서 dc 도 작동합니다

 // dc #include <stdio.h> #include "stdio.h" int main() { int a = 0; a = foo(); printf("a=%d\n", a); return 0; }

Paul Yang

#include <file>

기본 포함 디렉토리가 있는 파일을 포함합니다.

 #include "file"

파일이 컴파일된 현재 디렉토리에 파일을 포함합니다.

IAmAUser

컴파일러에 의해 생성된 구현 정의 경고는 시스템 라이브러리를 프로그램 라이브러리와 다르게 취급할 수 있습니다.

그래서

#include <myFilename>

-- 실제로 myFilename이 시스템 라이브러리 위치에 있음을 선언하는 -- 다음을 사용할 때 표시되는 데드 코드 및 사용되지 않은 변수 경고 등을 숨길 수 있습니다.

#include "myFilename"

david

출처 : http:www.stackoverflow.com/questions/21593/what-is-the-difference-between-include-filename-and-include-filename