Параметр Visual C++ «Принудительно включить»

Я бы не рекомендовал использовать /FI (MSDN говорит, что он называется /FI . Не уверен, что я смотрел на правильную страницу), просто потому, что люди или вы, читающие файлы, не замечают, что заголовок все равно волшебным образом включен.

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

Я бы сказал противоположное litb выше, если вы используете предварительно скомпилированные заголовки. Если вы используете «stdafx.h» в качестве предварительно скомпилированного заголовка и имеете такой код:

#include "afile.h"
#include "stdafx.h"

тогда вы потратите целую вечность, пытаясь понять, почему «afile.h» не включен. При использовании предварительно скомпилированных заголовков все включения и #define игнорируются вплоть до «stdafx.h». Итак, если вы принудительно включите «stdafx.h», то вышеперечисленное никогда не произойдет, и вы получите проект, который эффективно использует предварительно скомпилированную опцию.

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

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

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

Я бы поддержал litb: не делайте принудительное включение. Наличие явного кода облегчает понимание того, что происходит для нового пользователя. Это также упрощает понимание того, что происходит, если вам когда-нибудь понадобится перенести код на новую платформу.

Обратите внимание, что если в коде используются шаблоны, Visual Studio обычно не может правильно отследить определения. Возможно, 2010 год будет лучше, но даже в VS 2008 есть проблемы в этом плане.

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

Я бы не использовал его так часто, но он имеет свое применение. Я использовал его, чтобы добавить заголовок, который подавлял некоторые предупреждения для всех файлов cpp, чтобы я мог включить /W4 или /Wall для проекта и не нужно было редактировать все файлы cpp, чтобы сначала включить заголовок подавления предупреждений. Как только все заработало, я вернулся и отредактировал все файлы cpp, но для проверки концепции / FI был полезен.

Точно так же вы можете использовать его для принудительного включения предварительно скомпилированного заголовка в файлы cpp в некоторых конфигурациях сборки, но не во всех (в случае, если вы хотите иметь конфигурацию сборки, которая НЕ использует предварительно скомпилированные заголовки и гарантирует, что каждый cpp включает только то, что ему нужно) ). Однако использование #pragma hdrstop, ИМХО, лучший способ добиться этого.

Я говорил обо всем этом в своем блоге здесь: http://www.lenholgate.com/blog/2004/07/fi-stlport-precompiled-headers-warning-level-4-and-pragma-hdrstop.html немного подробнее.