Как на самом деле работают предварительно скомпилированные заголовки

У меня нет особых знаний о внутренностях VC ++. Однако при наличии некоторых знаний о конструкции и теории компилятора то, что представляют собой эти так называемые «предварительно скомпилированные заголовки», не может быть ничем иным, как просто результатом начального лексического анализа и этапов токенизации классической конструкции компилятора.

Рассмотрим простой файл заголовка, который содержит следующее:

#ifdef FOO
#define BAR 10
#else
#undef FOOBAR
class Foo {
public:
     void bar();
};
#include "foobar.h"
#endif

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

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

Единственное, что вы можете концептуально сделать, «предварительно скомпилировать» заголовочный файл, - это предварительно проанализировать его. Преобразуйте отдельные элементы языка, отдельные ключевые слова, такие как "#ifdef", "class" и все другие, в отдельные двоичные токены. Удалите все комментарии, пробелы и т. Д.

Первый этап компиляции традиционного языка включает в себя синтаксический анализ исходного текста на внутренние языковые элементы. Лексический анализ и этап токенизации. После анализа отдельных языковых элементов предпринимается попытка выяснить, как полученный проанализированный исходный код должен быть преобразован в объектный модуль. И здесь 99% работы компилятора. Фаза начального лексического анализа на самом деле невелика, но это почти все, что вы можете сделать, чтобы «предварительно скомпилировать» исходный код и сохранить внутреннее двоичное представление токенизированного источника, чтобы эту фазу можно было пропустить, когда реальный код использует "предварительно скомпилированный" исходный код.

Я предполагаю, что VC ++ практически не накладывает ограничений на содержимое предварительно скомпилированных заголовков. Однако, если есть некоторые ограничения - скажем, предварительно скомпилированные заголовки не могут иметь каких-либо условных директив препроцессора (ifdef / ifndef), за исключением классических защитных мер, - тогда можно было бы проделать больше работы для создания предварительно скомпилированных заголовков и сохранить немного больше работы здесь. Другие ограничения на содержимое предварительно скомпилированных заголовков также могут привести к смещению некоторых дополнительных функций в фазу предварительной компиляции.

Предварительно скомпилированный заголовочный файл, который компилируется с помощью stdafx.cpp, имеет вид stdafx.h. Разработчик помещал в этот заголовок редко изменяемые и часто необходимые файлы заголовков и символы. Такие как Windows.h, vector и некоторые глобальные макросы и символы. Под часто используемым я подразумеваю для всех файлов в данном проекте.

Какова цель и полезность такого файла (PCH)? Что ж, компилятор VC ++ будет компилировать весь stdafx.h файл рекурсивно, все заголовки включают все макросы и другие символы. В первый раз это займет много времени, и будет создан файл PCH (отсюда p перекомпилированный h читатель). В последующих сборках элементы, включенные через stdafx.h, не будут перекомпилированы (поскольку они уже находятся в некотором двоичном / предварительно скомпилированном формате). Это сокращает время сборки, и оно будет варьироваться в зависимости от того, сколько элементов (заголовков, символов и т. Д.) Помещается в stdafx.h файл.

Если у вас большая кодовая база и меньше элементов в stdafx, вы не получите преимущества (например, включая повсюду общие заголовки Windows и STL, везде есть externs и typedef). Лучше найти эти элементы, поместить их в stdafx.h и удалить их из файлов заголовков / CPP. Это значительно сократит общее время сборки.

Здесь вы можете изменить его:

Я думаю, что MSVC ищет <application_name>.pch для единственного предварительно скомпилированного заголовка для единицы перевода и использует его вместо включенного заголовка, включенного в #line 1 "c:\\application_name\\stdafx.h" в предварительно обработанном .i файле, если он доступен. Предварительно скомпилированный заголовок, вероятно, является сериализованным AST, то есть заголовок был преобразован в лексический формат и преобразован в представление AST. Тогда ему не нужно lex (или синтаксический анализ) этой области предварительно обработанного вывода и просто использует .pch, который содержит вывод lex + parse того, что записано в выводе препроцессора в stdafx.h. Препроцессор уже выполнил всю остальную работу с stafx.h, такую ​​как раскрытие макросов (которые не отображаются в выходных данных .i файла / препроцессора).