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

Question

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

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

#include "stdafx.h"

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

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

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

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

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

Answer 1

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

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

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

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