#include <> и #include ""

Ответ 1

В стандарте на языке C указывается, что <> должен использоваться для "заголовков" и "" должен использоваться для "исходных файлов". Теперь не поддавайтесь обману в "исходных файлах". Когда стандарт говорит "исходные файлы", это не значит, что вы думаете. Термин "исходные файлы", используемый в стандарте, охватывает то, что мы разговорно называем "заголовочные файлы" (в дополнение к тому, что мы обычно называем "исходными файлами" ).

Когда стандарт говорит о "заголовках", он вообще не говорит о файлах. Стандарт не требует, чтобы заголовки существовали как файлы. Они могут быть встроены в компилятор для всех стандартных забот.

Таким образом, реальная разница между <> и "" заключается в том, что <> используется для заголовков, а "" - для файлов. Если вы знаете, что источник, который вы будете включать, это файл, то вы должны использовать "".

На практике компиляторы используют разные алгоритмы поиска для <> по сравнению с "". Это разрешено стандартом, так как алгоритм поиска, который будет использоваться для любого из них, определяется реализацией. Но это не реальная разница, выраженная стандартом.

Ответ 2

Фундаментальное различие заключается в поиске путей.

Вы должны использовать форму угловой скобки для "системы", включая регулярные котировки для локального проекта.

Ответ 3

Дэн Фординг получил это правильно; хакер и Ник Бастин ошибались. К сожалению.

#include <...>

для заголовков, которые даже не являются файлами в файловой системе, но могут, например, быть внутренним для компилятора.

#include "..."

для файлов, и только если такой файл не найден, возвращается ли он по умолчанию к #include <...>.

Как и где эти заголовки и файлы ищутся и есть ли < > следует использовать для системных файлов, а для файлов проектов - это, по сути, общее соглашение, полностью зависит от компилятора и проекта.

В стандарте C (ISO/IEC 9899: 1999) говорится (основное внимание):

6.10.2 Включение исходного файла

Ограничения

Директива

A #includeдолжен идентифицировать заголовок или исходный файл которые могут быть обработаны реализация.

Семантика

Директива предварительной обработки формы

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

выполняет поиск последовательности места реализации для a заголовок, однозначно идентифицированный указанной последовательности между < и > разделителей и вызывает замену этой директивы всем содержимое заголовка. Как места указываются или заголовок идентифицирован определяется реализацией.

Директива предварительной обработки формы

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

вызывает замену этого директивы по всему содержанию исходный файл, идентифицированный указанная последовательность между " разделители. Именованный исходный файл поиск осуществляется с помощью > реализации. Если это поиск не поддерживается, или если поиск не выполняется, директива перерабатывается, как если бы он читал

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

с идентичными (включая > символы, если они есть) от оригинала директива.

Ответ 4

Котировки указывают на поиск сначала в текущем каталоге, затем в системных каталогах (любой путь жестко закодирован в компиляторе/препроцессоре или указан с помощью -I). Используя угловые скобки, вы сначала откажитесь от поиска в текущем каталоге.

Выход компилятора определенно не зависит от котировок, потому что он обрабатывается на этапе предварительной обработки. За исключением случая, когда из-за измененного поведения поиска включаются разные файлы.

Ответ 5

Для gcc-компилятора там есть разница между заголовками < > и "". Если заголовок < > включен из каталога, который был поставлен как -система для препроцессора, тогда предупреждения для выделенного заголовка не выдаются. С -Werror это имеет огромное значение в некоторых случаях.

У компилятора Intel также есть директива -системы, поэтому она может быть применима и к icc.

Не говоря уже о различиях в каталогах поиска, которые слишком очевидны.

Ответ 6

Предупреждение: это чистая спекуляция. Мне не хватает опыта с компилятором Intel, чтобы узнать, работает ли он таким образом, и я не знаю о компиляторе, который это делает.

Если компилятор реализует предварительно скомпилированные заголовки, он может использовать их для одной формы include, но не другой. Если предварительно скомпилированный заголовок не синхронизируется с фактическим заголовком, вы получите разные результаты в зависимости от того, что было включено.

Ответ 7

#include <somefile.h>

проверит систему, включающую пути (включая любой дополнительный путь, добавленный для проекта).

#include "somefile.h"

проверит рабочую папку приложений. (т.е. в той же папке, что и исходный файл, в котором есть оператор #include).

Ответ 8

В целом нет технической разницы, и все, кто расскажет вам об этом только в местном стиле, вероятно, повлиял на прошлые компиляторы - многие современные компиляторы реализуют первоначальный поиск точно так же (часто другие общие поведения доступны через командную строку опция). Стандарт оставляет поведение в руках исполнителя, не имея особого обоснования для поддержки обоих синтаксисов.

В соответствии с разделом 6.10.2 стандарта ISO C99 пути поиска для < > и "определены как определенные. Единственная разница между ними в глазах стандарта заключается в том, что использование" "отпадет на < > , если оно не может быть разрешено. (Не поддавайтесь стандарту, представляя собой различие между" заголовком "и" исходным файлом "- нет никакой разницы, фактически определенной стандартом, отличной от того, что некоторые имена зарезервированы -" stdio.h "и т.д.)