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

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

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

#include "stdafx.h"

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

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

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

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

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

14
c++ stdafx.h visual-c++

5 ответов

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

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

15

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

6

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

поскольку каждый проект имеет свой собственный предварительно скомпилированный файл заголовка, поэтому я бы просто поместил туда common-to-all-includes. Скажем, если проект использует некоторые заголовки boost, они хорошо подойдут, поскольку они будут использоваться всем проектом, и вы их не меняете. Следовательно, редко / никогда не меняйте заголовки в предварительно скомпилированных заголовках, таких как system или third партии материалов.

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

1

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

1

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

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

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

0