Как правильно использовать stdafx.h?

Question

Как правильно использовать stdafx.h с точки зрения разделения зависимостей?

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

#include "stdafx.h"

с оговорками, которые:

1. Я больше не знаю, какие файлы зависят от каких заголовков.
2. Это уменьшает модульность, делая мой код менее пригодным для повторного использования.
3. Я больше не могу отделить C #include s из C++ (например, cstring против string.h без большой боли. (Говоря о том, имеет ли это значение?)

Если я ничего не добавлю туда, я могу все хорошо организовать, но тогда мои компиляции резко замедляются.

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

Есть ли известное / общепринятое решение этой проблемы?

Answer 1

Вы не должны помещать свои собственные файлы заголовков в stdafx.h так как ваш код может измениться и приведет к перекомпиляции всей вашей программы.

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

Answer 2

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

Answer 3

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

Answer 4

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

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

Что касается скорости компиляции, я бы предпочел как можно больше полагаться на предварительное объявление вещей, разделение на более мелкие библиотеки и попытаться выяснить, могут ли вещи быть организованы таким образом, чтобы изменчивый код не влиял на перекомпиляцию большого количества другого кода.

Answer 5

Условно включите PCH, затем определите что-то вроде "#define _PRE_COMPILE_". Таким образом, исходные заголовки все еще видны, а код является модульным, если вам так нужно. Примером этого может быть включение

#ifdef _PRE_COMPILE_
#include "stdafx.h"
#elif
#include <iostream>
#include <cstring>
#endif

Включите это в начале каждого исходного файла.