Как компиляторы знают, где найти #include <stdio.h>?

Мне интересно, как компиляторы в Mac OS X, Windows и Linux знают, где найти файлы заголовков C.

В частности, мне интересно, как узнать, где найти #include с скобками <>.

#include "/Users/Brock/Desktop/Myfile.h"    // absolute reference
#include <stdio.h>                         // system relative reference?

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

Ответ 1

Когда компилятор построен, он знает о нескольких стандартных местоположениях для поиска файла заголовка. Некоторые из них не зависят от того, где установлен компилятор (например,/usr/include,/usr/local/include и т.д.), А некоторые из них основаны на том, где установлен компилятор (который для gcc контролируется --prefix при запуске configure).

Такие местоположения, как /usr/include, хорошо известны, а "знание" этого местоположения встроено в gcc. Такие местоположения, как /usr/local/include, не считаются полностью стандартными и могут быть установлены, когда gcc построен с опцией -with-local-prefix configure.

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

Ответ 2

ОС не знает, где искать эти файлы - компилятор делает (точнее, препроцессор). Он имеет набор путей поиска, где он знает, как искать заголовки, так же как и в вашей командной оболочке есть набор мест, где он будет искать программы для выполнения при вводе имени. Документация GCC объясняет, как это делает компилятор и как эти пути поиска могут быть изменены.

Ответ 3

Местоположение файла зависит от системы. Действительно, файл может быть precompiled, или он может даже не существовать — компилятор может иметь его как "встроенный". На моем macbook я вижу, что там такой файл в /usr/include/c++/4.2.1/iostream, но вы не должны полагаться на него, и это определенно плохая идея его редактировать.

Ответ 4

В Visual Studio это либо в настройках проекта, если вы используете среду IDE или в переменной среды %INCLUDE%, если используете командную строку.

Ответ 5

Если вы использовали g++, вы могли бы сделать что-то вроде этого, чтобы узнать, что искали пути поиска:

touch empty.cpp
g++ -v empty.cpp

Я не знаю, есть ли эквивалент для Xcode. Может быть, это сработает, поскольку Xcode основан на GCC?

Ответ 6

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

#include <boost/tokenizer.hpp>

Работает, потому что корневой каталог boost содержит папку с именем boost, и эта папка либо находится в вашем пути включения по умолчанию, либо вы сделали что-то вроде.

g++ -I$BOOST_ROOT {blah,  blah}

Стандарт C и С++, что разделитель UNIX "/" будет работать одинаково для всех систем, независимо от того, что система хоста использует для обозначения каталогов. Как упоминалось ранее, иногда #include фактически не содержит реального файла.