Visual Studio неправильно отображает # ifdef отрывки в коде C / C ++

Question

Я работаю над большим унаследованным C ++ (на самом деле, в основном C) проектом, разработанным и поддерживаемым в Visual Studio 2008. Технически, с точки зрения Visual Studio, это «решение», состоящее из восьми «проектов», и в немКажется, это проблема.

Как я уверен, большинство из вас знает, Visual Studio выделяет код, который, как он считает, # ifdef'd out.Что я нахожу, однако, то, что это, кажется, не делает это правильно для различных проектов.Для простоты давайте назовем их Proj1, Proj2, ... Proj8.Когда я работаю над конфигурацией Win32 Debug в Proj5, я ожидаю, что макросы, определенные в конфигурации свойств препроцессора C / C ++ в Proj5, будут определять, что выделено серым (или, по крайней мере, существует какой-то простой способ сделать этотак).Вместо этого я, кажется, вижу представления, основанные на свойствах Proj1.То есть, если Proj1 определяет некоторые макросы препроцессора, которые исключают часть кода, я вижу, что эта часть недоступна, даже когда я работаю над Proj5.И макросы для Proj5 никак не влияют на то, что я вижу.

Да, я сделал полную очистку и сборку (на самом деле несколько, и даже сохранил все в SVN и начал на новом верхнем уровне).я уверен, что это не из-за некоторых рудиментарных файлов, созданных старой сборкой.И я вполне уверен, что в других отношениях Visual Sourcesafe «правильно» понимает контекст, потому что (1) меню «Сборка» содержит параметры, относящиеся к Proj5, а не к Proj1;(б) в нижней части меню «Проект» находится «Свойства Proj5 ...», а не «Свойства Proj1 ...»;и (c) нет никаких сомнений в том, что # ifdef работают в построенной программе: есть существенные различия в функциях, и они, как я и ожидал, будут.

---

ДОБАВЛЕНО 27Сентябрь 2010 У меня до сих пор нет ответа, поэтому позвольте мне попробовать это по-другому: если я уже выполнил успешные сборки (которые у меня есть), есть ли что-нибудь , кроме свойств препроцессора и конфигурациитекущий выбранный проект (и, как отмечено ниже, проекты отдельных файлов, но в данном случае это спорный вопрос), который должен влиять на то, какой код выделен серым цветом?

Answer 1

VS2010 должен помочь с этим. В VS2008 кэш просмотра без компиляции выполняется после предварительной обработки, поэтому он может содержать только один набор определений макросов.

Я не верю, что "Build Clean" или "Rebuild" будут удалять файлы .ncb, так как они вообще не являются частью процесса сборки. Я знаю, что удаление этих файлов вручную исправляет все виды странного поведения, но я боюсь, что в вашем случае это не будет долговременным решением (файлы .ncb все равно будут заполнены на основе одной конфигурации)

Answer 2

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

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

Answer 3

Сделайте проект Startup Project, удалите и повторно добавьте определение препроцессора, нарушившее работу

Подробнее: Я нашел процесс, который исправляет мои проекты MFC, когда это происходит (по крайней мере, временно). Сначала я установил проект, над которым я работаю, как проект запуска. Сделайте это, щелкнув правой кнопкой мыши проект в обозревателе решений и выбрав «Установить как стартовый проект». Затем я вхожу в определения препроцессора для проекта и удаляю тот, который не запускается, и нажимаю ОК. Через несколько секунд вы увидите маленький индикатор прогресса в правом нижнем углу. Как только он закончится, вернитесь к определениям препроцессора для проекта, добавьте его снова и нажмите OK. После того, как маленький индикатор выполнения завершится снова, вы должны снова увидеть правильный код.