Visual Studio заставляет включать предварительно скомпилированный заголовочный файл во все блоки компиляции проекта?
Когда компилятор компилирует исходный код (например, *.cpp) файл, он создает объектный файл (например, *.o), так что позже он будет связан с другими .o а также .so (.lib файлы для Windows) и будут представлять собой исполняемый файл.
Теперь для аналогичной ситуации не компилировать заголовочные файлы каждый раз, когда он создает некоторые .файлы pch тогда он будет связан с компоновщиком.
Теперь, если в рамках проекта Visula Studio определен предварительно скомпилированный заголовок, то почему Visual Studio жалуется на ошибку (например, **fatal error C1010: unexpected end of file while looking for precompiled header. Did you forget to add '#include "stdafx.h"' to your source?**) что файл заголовка не включен в файл .cpp.
Подводя итог, вот мои вопросы:
- Почему в каждом файле .cpp предварительно скомпилированный заголовок проекта
необходимо? - Каким образом требование наличия предварительно скомпилированного заголовка в каждом модуле компиляции оптимизирует процесс компиляции? Другими словами, в чем выгода этого требования? (Пользователь может сам решить, где включить, а где нет!)
- Если предварительно скомпилированный заголовок включен в файл .cpp, который использует только 2% от того, что находится в файле .pch, то оставшиеся 98% будут добавлены в соответствующий файл .o в?
Решение
Почему в каждом файле .cpp нужен предварительно скомпилированный заголовок проекта?
Потому что ты просил об этом. Если вы не хотите использовать его, вам нужно изменить параметр для файла .cpp. Щелкните правой кнопкой мыши, Свойства, C / C ++, Предварительно скомпилированные заголовки, «Создать / использовать» = «Не использовать предварительно скомпилированные заголовки». Значением по умолчанию является «Использовать». Там мало смысла в этом.
Как предварительно скомпилированный заголовок в каждом модуле компиляции оптимизирует процесс компиляции?
Не анализируя #includes. Особенно полезно, когда вы #include <windows.h>, Экономия времени составляет порядка нескольких секунд, в больших проектах с сотнями файлов .cpp, что в сумме составляет несколько минут. На сегодняшний день это самый дешевый способ ускорить компилятор без потери качества сгенерированного кода.
тогда остальные 98% будут добавлены в соответствующий файл .o в?
Конечно, нет.
Другие решения
- На самом деле нет необходимости включать предварительно скомпилированный заголовок в каждый модуль компиляции. Вы можете установить параметр «не использовать предварительно скомпилированный заголовок» для одного файла в разделе свойств C / C ++ -> Precompiled Headers для этого файла. Это большая работа, и я никогда не знал, чтобы кто-нибудь делал это в рабочем коде.
- Оптимизация заключается в том, что предварительно скомпилированный заголовок создается только один раз, и весь shebang используется повторно для всех модулей компиляции без перекомпиляции / повторного включения (вроде). Если у вас есть набор файлов, который включается много раз, это может сэкономить много времени на компиляцию. Увидеть Уход и кормление предварительно скомпилированных заголовков тоже.
- Нет, вы не получаете лишнего содержимого файла, как при статическом линковании.
- Я предполагаю, что ваш вопрос означает «почему компилятор не может предположить, что этот заголовок всегда есть, если он обязателен». Причина в том, что VS не хочет так сильно отклоняться от стандарта. Если ваш файл .cpp использует что-то из заголовочного файла, он должен включить его. Таким образом, ваш файл будет скомпилирован точно так же, даже если вы отключите предварительно скомпилированные заголовки (только это займет больше времени).
- Как уже говорили другие, вы можете явно отключить скомпилированные заголовки для отдельных файлов, если хотите. Идея состоит в том, что вы должны включать в скомпилированный заголовок только те элементы, которые вы используете в большинстве, если не во всех ваших файлах.
- Нет, результирующий объектный код должен быть одинаковым независимо от того, какой заголовок предварительно скомпилирован или нет.