Статья: Как ускорить компиляцию с помощью предкомпилированных заголовков в С Builder

#endif

Полный текст моей версии этого файла приведен в конце статьи. На h-файлы, входящие в предкомпилированный образ, накладывается ограничение - в них не должно быть инициализированных данных, например, в math.hpp есть строки:

static const Extended NaN = 0.0 / 0.0;

static const Extended Infinity = 1.0 / 0.0;

Из-за наличия этих констант включить math.hpp в файл pch.h нельзя.

Кстати, С++ Builder при добавлении новых модулей в проект реализует описанную стратегию управления предкомпилированными заголовками. Например, при создании нового приложения, файл Unit1.cpp будет таким:

#include <vcl.h>

#pragma hdrstop

#include "Unit1.h"

....

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

Управлять составом включаемых в vcl.h заголовков можно с помощью специальных символов (INC_VCLDB_HEADERS, INC_VCLEXT_HEADERS и др.). В моей версии pch.h эти символы определяются с помощью #define до включения vcl.h, что приводит к увеличению числа включаемых файлов.

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

Даже в большом проекте перейти к использованию предкомпилированных заголовков достаточно просто.

В свойствах проекта нужно включить кэширование предкомпилированных заголовков и рекомендуется указать "персональный" файл, в котором будет храниться образ предкомпилированных заголовков: Project - Options - закладка Compiler, группа "Pre-compiled headers". Тут должно быть выбрано "Cache pre-compiled headers", а в поле "File Name" нужно ввести "pch.csm". При такой настройке образ с предкомпилированными заголовками будет находится в папке с проектом, в файле pch.csm.

После этого в начало каждого cpp-модуля необходимо вставить 2 строки:

#include "pch.h"

#pragma hdrstop

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

#include "pch.h" // включает vcl.h, string и т.д.

#pragma hdrstop

#include <vcl.h>

#include <string>

...

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

В принципе, при использовании pch.h, техническая потребность во включении стандартных заголовков исчезает. Однако, полезно все же указывать все необходимые для каждого конкретного модуля заголовки ниже директивы #pragma hdrstop. Во-первых, это в некоторой степени документирует модуль - по включаемым файлам можно судить, какими возможностями пользуется этот модуль. Во-вторых, это облегчает повторное использование модуля в других проектах, в которых либо не используется pch.h, либо его содержимое может быть другим.

Теоретически можно еще больше повысить эффективность компиляции, если включить в pch.h не только стандартные, но и все пользовательские заголовочные файлы. Практически, так как пользовательские заголовки меняются достаточно часто, это может повлечь за собой частую перекомпиляцию pch.h, что негативно скажется на времени компиляции. Кроме того, пользовательские заголовки обычно не бывают очень большими и компилируются очень быстро. Поэтому включать их pch.h не целесообразно.

Как проверить, что предкомпилированные заголовки используются эффективно

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

- визуальное наблюдение за процессом компиляции. Обычно, число строк компилируемых в одном файле не должно превышать 10000-15000 строк