Опция «Включает в себя» в Visual C ++

Question

Я только что наткнулся на опцию Visual C ++, которая позволяет принудительно включать файл (ы) - это произошло, когда я просматривал какой-то код, в котором отсутствовал #include "StdAfx.h" в каждом файле .cpp, но был фактически делает это с помощью этой опции.

Параметр можно найти на странице Расширенные свойства конфигурации C / C ++ и соответствует параметру компилятора / FI .

Эта опция может оказаться очень полезной, но прежде чем я брослюсь и начну ее использовать, я подумала спросить, есть ли какие-нибудь ошибки?

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

Force include также полезен для автоматически генерируемых исходных файлов. Наша система использует инструмент, который генерирует много исходных файлов, но они не включают в себя наш предварительно скомпилированный заголовочный файл. Компиляция этих файлов теперь выполняется с помощью «force includes».

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

Answer 4

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

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

Answer 5

Я бы не использовал его так часто, но он имеет свои применения. Я использовал его, чтобы добавить заголовок, который подавлял некоторые предупреждения для всех файлов cpp, чтобы я мог включить / W4 или / Wall для проекта и не нужно было редактировать все файлы cpp, чтобы сначала включить заголовок подавления предупреждений. Как только все заработало, я ДЕЙСТВИТЕЛЬНО вернулся и отредактировал все файлы cpp, но для проверки концепции / FI был полезен.

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

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

Answer 6

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