Visual Studio 2010, Intellisense и PCH: каковы альтернативы уродливому stdafx.h?

Question

Я недавно переключился на Visual Studio 2010, и для Intellisense не требуется полминуты для отображения при использовании библиотек boost, Предложение Microsoft , похоже, использует предварительно скомпилированные заголовки.

За исключениемчто я никогда не использовал их раньше (за исключением случаев, когда это было вызвано Ugly ATL Wizards (TM)), поэтому я искал, чтобы выяснить, как они работают.

В принципе, подход Big Centralized stdafx.h кажется совершенно неправильным.Я никогда не хочу включать (даже дешево) целую кучу заголовочных файлов во все мои источники.Поскольку я не использую библиотеки Windows (я делаю обертки C ++ / CLI более высокого уровня, а затем использую .NET для общения с внешним миром), у меня нет «целой грузы неизменяемых огромных заголовков».Просто boost и стандартные библиотечные заголовки разбросаны по всему.

Существует интересный подход к этой проблеме, но я не совсем понимаю, как заставить это работать.Кажется, что каждый исходный файл должен быть скомпилирован дважды (пожалуйста, исправьте меня, если я ошибаюсь): один раз с / Yc и один раз с / Yu.Это увеличивает нагрузку на разработчика, который должен вручную настроить систему сборки.

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

Какие у меня есть варианты использования скомпилированных заголовков для каждого исходного файла? Меня не волнует сборкараз (пока они не взлетят), я просто хочу, чтобы intellisense работал fast .

Answer 1

Для начала, вы неправильно прочитали статью.Каждый файл НЕ компилируется дважды.Файл stdafx.cpp компилируется один раз с помощью / Yc (c для создания), а затем все остальные файлы в вашем проекте компилируются один раз с помощью / Yu (u, для использования) и импортируют результат ранее созданного сохраненного состояния.from stdafx.cpp.

Во-вторых, этой статье 7 лет, и речь идет о VC ++ 6, поэтому вам следует начать не доверять ей.Но даже если предположить, что содержащаяся в нем информация по-прежнему относится к VC ++ 2008 или 2010, это кажется плохим советом.Подход, который он рекомендует использовать /pragma hdrstop, - это решение проблемы.Если у вас есть заголовки, которые содержат вещи, которые вам не нужны в каждом файле, то они просто не должны идти в ваш предварительно скомпилированный заголовок.

Answer 2

Ваша проблема в основном в том, что Intellisense работает медленно для Boost в VS2010?У меня нет прямого решения этой проблемы, но может ли Visual Assist X быть вариантом для вас?Я использовал его в различных версиях Visual Studio сейчас и с большим удовольствием.Не прямое решение, но оно может работать для вас.

Answer 3

Предварительно скомпилированные заголовки не так уж плохи, если вы их правильно используете .

Не используйте их вместо правильных и точных #include, но как способ ускорить процессвверх.Добейтесь этого, заставив предварительно скомпилированный заголовок ничего не делать в сборках релиза, только ускоряя процесс отладки.

Answer 4

Вы не правы, каждый файл компилируется только один раз.У вас есть один файл .cpp, который скомпилирован с / Yc, а остальные скомпилированы с / Yu.Файл с / Yc, который по умолчанию является stdafx.cpp, содержит одну строку, #include "myMainHeader.h" (изменил имя по умолчанию). Все остальные файлы .cpp должны начинаться с #include "myMainHeader.h"Файл / Yc компилируется, все внутреннее состояние компилятора сохраняется.Этот файл загружается при компиляции каждого из ваших других файлов.Вот почему вы должны начать с включения PCH, чтобы параметр / Yu не изменил результат компиляции, а только время.Xcode не предъявляет этого требования и будет использовать PCH независимо от того, начинается ли ваш файл .cpp с правильной директивы include.Я использовал библиотеки, которые полагались на это и не могли быть собраны без PCH.