Что такое stdafx h

Для чего используется «stdafx.h» в Visual Studio?

Файл с именем stdafx.h генерируется автоматически, когда я запускаю проект в Visual Studio 2010. Мне нужно создать кроссплатформенную библиотеку C ++, поэтому я не могу / не могу использовать этот заголовочный файл.

Для чего stdafx.h используется? Это нормально, что я просто удалил этот заголовочный файл?

Это не уникально для Windows, но это старая проблема, с которой сталкиваются все компиляторы, которые должны компилироваться с большим API, таким как Windows.

Компилятор может значительно сэкономить время, если ему не нужно начинать компилировать каждый файл Cpp, а также десятки включений буквально с нуля каждый раз.

Хитрость заключается в назначении специального заголовочного файла в качестве отправной точки всех цепочек компиляции, так называемого файла «предварительно скомпилированного заголовка», который обычно является файлом с именем stdafx.h просто по историческим причинам.

Я не верю, что этот трюк уникален для компиляторов Microsoft, и при этом я не думаю, что это была оригинальная разработка.

В Visual Studio 2010 этот параметр управляется из графического интерфейса пользователя посредством щелчка правой кнопкой мыши по проекту CPP, выбора «Свойства» и перехода к «Свойства конфигурации \ C / C ++ \ Precompiled Headers». Для других версий Visual Studio расположение в графическом интерфейсе будет другим.

Обратите внимание: если вы отключите предварительно скомпилированные заголовки (или запустите свой проект с помощью инструмента, который их не поддерживает), это не сделает вашу программу незаконной; это просто означает, что ваш инструмент будет компилировать все с нуля каждый раз.

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

Источник

StdAfx.h for Novices

This article is meant for those programmers who are only getting started with the Visual Studio environment and trying to compile their C++ projects under it. Everything looks strange and complicated in an unfamiliar environment, and novices are especially irritated by the stdafx.h file that causes strange errors during compilation. Pretty often it all ends in them diligently turning off all precompiled headers in every project. We wrote this article to help Visual Studio newcomers to figure it all out.

The purpose of precompiled headers

Precompiled headers are intended to speed up project builds. When getting started with Visual C++, programmers usually try it on very small projects that cannot show the performance gain from using precompiled headers. Both with and without them, the program seems to take the same time to compile. This is just what confuses the user: he doesn’t see any use in this option and concludes that it is needed for some specific tasks and he will never need it. This delusion may last for years.

Precompiled headers are actually a very useful technology. You can notice the benefit even with a project of just a few dozens of files. Using such heavy libraries as boost makes the performance gain especially evident.

The amount of work the preprocessor has to do during project compilation can be greatly reduced. The idea is to preprocess a group of files in advance and then simply insert already prepared text fragments where necessary.

It actually includes a few more steps: instead of simple text you can store more highly processed information. I don’t know how exactly it all is implemented in Visual C++, but I know that, for instance, you can store text already split into lexemes. It will speed up the compilation process even more.

How precompiled headers work

A file containing precompiled headers has the «.pch» extension. The file name usually coincides with the project name, but you can naturally change this and any other used names in the settings. The *.pch file may be pretty large, which depends on how many headers are expanded in it. In PVS-Studio, for example, it occupies about 3 Mbytes.

The *.pch file is created as a result of the stdafx.cpp file’s compilation. This file is built with the «/Yc» switch that is used specifically to tell the compiler to create precompiled headers. The stdafx.cpp file can contain one line: #include «stdafx.h».

The most interesting stuff is stored in the «stdafx.h» file. All the header files to be precompiled should be included into it. For example, below is the stdafx.h file we use in PVS-Studio (the text is abridged for the article):

The «#pragma warning» directives are necessary to get rid of warnings generated on standard libraries.

Now the «stdafx.h» file should be included into all the *.c/*.cpp files. You should also remove from these files all the headers already included into «stdafx.h».

But what to do when different files use somewhat similar but still different sets of headers? For example:

Should you create individual precompiled headers? Well, you can do that but you don’t need to.

How to use precompiled headers

When starting a new project, Visual Studio’s Wizard creates two files: stdafx.h and stdafx.cpp. It is through them that the mechanism of precompiled headers is implemented.

These files can actually have any other names; it’s not the name that matters but the compilation parameters you specify in the project settings.

A *.c/*.cpp file can only use one precompiled header. However, one project may contain a few different precompiled headers. Suppose we have only one for now.

So if you have used the Wizard, the files stdafx.h and stdafx.cpp are already created for you, and all the necessary compilation switches are also defined.

If you didn’t use the precompiled headers option in your project, let’s find out how to enable it. I suggest the following algorithm:

Now we have enabled the precompiled headers option. If we run compilation now, the compiler will create the *.pch file. However, compilation will terminate just a bit later because of errors.

We have set all the *.c/*.cpp files to use precompiled headers, but it’s not enough. We need now to add #include «stdafx.h» into each file.

The «stdafx.h» header must be the very first one to be included into the *.c/*.cpp file. This is obligatory! Otherwise you are guaranteed to get compilation errors.

It really makes sense, if you come to think of it. When the «stdafx.h» file is included in the very beginning, you can substitute an already preprocessed text into the file. This text stays the same all the time and is not affected by anything.

And now imagine that we have included some other file prior to «stdafx.h» and that file contains the line #define bool char. It will make the situation undefined as we have changed the contents of all the files where «bool» is mentioned. Now you can’t just insert a preprocessed text, and the entire mechanism of «precompiled headers» gets broken. I believe this to be one of the reasons why «stdafx.h» must be included in the first place. Perhaps there are some other reasons too.

Life hack

Manually typing #include «stdafx.h» into all the *.c/*.cpp files is pretty tiresome and boring. Besides, you will get a new revision in the version control system with lots of files changed. It’s no good doing so.

Third-party libraries included into the project as source files cause some additional troubles. Changing these files won’t make sense. The best solution would be to disable precompiled headers for them, but it’s inconvenient when you use a number of small libraries. You will be constantly stumbling over precompiled headers.

But there is an easier way to handle precompiled headers. This method is not a universal one, but it did help me in many cases.

Instead of manually adding #include «stdafx.h» in all the files, you may use the «Forced Included File» option.

Go to the «Advanced» settings tab. Select all configurations. In the field «Forced Included File» write the following text:

From now on, «stdafx.h» will be automatically included in the beginning of ALL the files to be compiled. PROFIT!

What to include into stdafx.h

This is a very important question. Mindlessly including every single header into «stdafx.h» will slow down the compilation process instead of speeding it up.

All the files that include «stdafx.h» depend on its contents. Suppose «stdafx.h» includes the file «X.h». Changing «X.h» just a little bit may cause complete recompilation of the whole project.

Important rule. Make sure your «stdafx.h» file includes only those files that never or VERY rarely change. The best candidates are headers from system and third-party libraries.

If you include you own project files into «stdafx.h», be especially careful. Include only those files that change very, very rarely.

But don’t be too fanatical about non-changing files. Include only those headers that you use really often. Including won’t make sense if you need it in just a couple of files. Instead, simply include this file where needed.

Several precompiled headers

What for may we need several precompiled headers in one project? Well, it’s a pretty rare situation indeed. But here you are couple of examples.

You have to create two *.pch files. One of them is created after compiling the C-file (xx.c), the other after compiling the C++-file (yy.cpp). Accordingly, you should specify in the settings to use one precompiled header for C-files and another for C++-files.

Note. Don’t forget to set different names for these two *.pch files. Otherwise they will be replacing each other.

Here’s another situation. One part of the project uses one large library while the other part uses another large library.

Naturally, different parts of the project should not know about both libraries: there may be (unlucky) overlapping of entities’ names in different libraries.

It is logical to create two precompiled headers and use them in different parts of the program. As we have already mentioned, you may use any names you like for the files the *.pch files are generated from. Well, even the name of the *.pch file can be changed too. It all should be done very carefully of course, but there’s nothing especially difficult about using two precompiled headers.

Typical mistakes when using precompiled headers

Now that you have attentively read the text above, you will understand and eliminate any errors related to stdafx.h. But I suggest that we quickly review novice programmers’ typical mistakes once again and investigate the reasons behind them. Practice makes perfect.

Fatal error C1083: Cannot open precompiled header file: ‘Debug\project.pch’: No such file or directory

You are trying to compile a file that uses a precompiled header while the corresponding *.pch file is missing. Possible reasons are:

Fatal error C1010: unexpected end of file while looking for precompiled header. Did you forget to add ‘#include «stdafx.h»‘ to your source?

The error text says it all if you bother to read it. The file is compiled with the /Yu switch. It means that a precompiled header is to be used, but «stdafx.h» is missing from the file.

You need to add #include «stdafx.h» into the file.

If you can’t do it, do not use the precompiled header for this *.c/*.cpp file. Delete the /Yu switch.

Fatal error C1853: ‘project.pch’ precompiled header file is from a previous version of the compiler, or the precompiled header is C++ and you are using it from C (or vice versa)

The project contains both C (*.c) and C++ (*.cpp) files. You cannot use a shared precompiled header (*.pch file) for them.

The compiler misbehaves when using precompiled headers

You must have done something wrong. For example, the line #include «stdafx.h» is not the first one in the file.

Take a look at this example:

This code will fail to compile, the compiler generating a seemingly strange error message:

error C2065: ‘A’ : undeclared identifier

It thinks that all text before #include «stdafx.h» (including this line) is a precompiled header. When compiling the file, the compiler will substitute the text before #include «stdafx.h» with the text from the *.pch file. It will result in losing the line «int A = 10».

The correct code should look like this:

The contents of the file «my.h» won’t be used. As a result, you won’t be able to use the functions declared in this file. Such behavior does confuse programmers a lot. They try to «cure» it by completely disabling precompiled headers and then come up with stories about how buggy Visual C++ is. Remember one thing: a compiler is one of the least buggy tools. In 99.99% of all cases, it’s not the compiler you should be angry with, but mistakes in your own code (Proof).

To avoid such troubles, make sure you add #include «stdafx.h» in the very beginning of the file ALL THE TIME. Well, you can leave comments before #include «stdafx.h»; they don’t take part in compilation anyway.

Another way is to use Forced Included File. See the section «Life hack» above.

The entire project keeps completely recompiling when using precompiled headers

You have added into stdafx.h a file that you keep regularly editing. Or you could have included an auto-generated file by mistake.

Attentively examine the contents of the «stdafx.h» file: it must contain only headers that never or very rarely change. Keep in mind that while certain included files do not change themselves, they may contain references to other *.h files that do.

Something strange going on

You may sometimes come across an issue when an error doesn’t disappear even after fixing the code. The debugger reports something strange.

This issue may relate to the *.pch file. For some reason the compiler doesn’t notice that one of the header files has been changed, so it doesn’t recompile the *.pch file and keeps inserting previously generated text. It might have been caused by some faults related to the time of file modification.

This is an EXTREMELY rare situation. But it is possible and you should know about it. Personally I have faced this issue only 2 or 3 times during the many years of my career. It can be solved by complete full project recompilation.

A project using precompiled headers cannot be analyzed by PVS-Studio or CppCat

This is the most frequent trouble users report to our support service. For details, see the documentation: «PVS-Studio: Troubleshooting». Here I will only give a brief summary of the problem.

If a solution compiles well, it doesn’t mean that it is implemented correctly. One solution may often contain numbers of projects, each of them using their own precompiled headers (i.e. their own stdafx.h and stdafx.cpp files).

Troubles occur when programmers start using files from one project in another. It may be convenient and this method is quite popular indeed. But they also forget that the *.cpp file contains the line #include «stdafx.h».

The question is, which of the stdafx.h files will be taken up? If the program compiles well, it means the programmer is just lucky enough.

Unfortunately, it is very difficult for us to reproduce the behavior when using the *.pch file. You see, the «honest» preprocessor works quite differently.

You can check if your solution is implemented in a wrong way by temporarily disabling precompiled headers. You may then get lots of interesting errors that will make you sincerely wonder how your project could compile at all.

Again, refer to the documentation for details. If anything is still unclear, ask our support service.

Conclusion

As you can see, working with precompiled headers is pretty easy. Programmers that try to use them and constantly face «compiler’s numerous bugs» just don’t understand the working principles behind this mechanism. I hope this article has helped you to get rid of that misunderstanding.

Precompiled headers are a very useful option that allows you to significantly enhance project compilation speed.

Источник

Файлы предварительно скомпилированных заголовков

Параметры компилятора для предкомпилированных заголовков — /Y. На страницах свойств проекта параметры находятся в разделе Свойства конфигурации > Предкомпилированные заголовки C/C++. Можно не использовать предкомпилированные заголовки, а также указать имя файла заголовка и путь к выходному файлу.

Настраиваемый предварительно скомпилированный код

Для больших проектов, для которых требуется значительное время, может потребоваться создать настраиваемые предварительно скомпилированные файлы. Компиляторы Microsoft C и C++ содержат параметры для предварительной компиляции любого кода C или C++, включая встроенный код. Данная возможность позволяет скомпилировать стабильное тело кода, сохранять скомпилированное состояние кода в файле, а при последующих компиляциях объединять предварительно скомпилированный код с кодом, который еще находится в стадии разработки. Каждая последующая компиляция выполняется быстрее, так как стабильный код не нужно компилировать повторно.

Случаи использования предварительной компиляции исходного кода

Предварительно скомпилированный код полезен во время цикла разработки, чтобы сократить время компиляции, особенно если:

Всегда используется большой текст кода, в который редко вносятся изменения.

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

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

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

Хотя для каждого исходного файла можно использовать только один файл предкомпилированного заголовка (PCH), в проекте можно использовать несколько файлов PCH.

Два варианта предварительной компиляции кода

Можно предварительно скомпилировать любой код C или C++ — вы не ограничены предварительной компиляцией только файлов заголовков.

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

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

Параметры предкомпилированного заголовка см. в разделах /Yc (создание файла предкомпилированного заголовка) и /Yu (использование файла предкомпилированного заголовка). Для создания предкомпилированного заголовка используйте /Yc. При использовании с необязательной прагмой hdrstop параметр /Yc позволяет предварительно компилировать как файлы заголовков, так и исходный код. Выберите /Yu, чтобы использовать существующий предкомпилированный заголовок в существующей компиляции. Можно также использовать /Fp с параметрами /Yc и /Yu, чтобы предоставить альтернативное имя предкомпилированному заголовку.

В справочных разделах, посвященных параметрам компилятора /Yu и /Yc, обсуждаются способы доступа к этой функции в среде разработки.

Правила согласованности предкомпилированных заголовков

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

Правила целостности для пофайлового использования предкомпилированных заголовков

Параметр компилятора /Yu позволяет указать, какой файл PCH следует использовать.

При использовании файла PCH компилятор предполагает ту же среду компиляции, которая использует последовательные параметры компилятора, прагмы и т. д., которые действуют при создании файла PCH, если не указано иное. Если компилятор обнаруживает несогласованность, он выдает предупреждение и по возможности определяет несогласованность. Такие предупреждения не обязательно указывают на проблему с файлом PCH. Они просто предупреждают о возможных конфликтах. Требования к согласованности для файлов PCH описаны в следующих разделах.

Согласованность параметров компилятора

Следующие параметры компилятора могут вызвать предупреждение о несогласованности при использовании файла PCH:

Макросы, созданные с помощью параметра препроцессора (/D), должны быть одинаковыми в компиляциях, создавшими файл PCH, и текущей компиляцией. Состояние определенных констант не проверяется, но при их изменениях могут возникать непредсказуемые результаты.

Файлы PCH не работают с параметрами/E и /EP.

Файлы PCH должны быть созданы с помощью параметра создания сведений о просмотре (/FR) или исключения локальных переменных (/Fr), прежде чем последующие компиляции, использующие файл PCH, смогут использовать эти параметры.

C7 совместимо (/Z7)

Если при создании файла PCH этот параметр включен, последующие компиляции, использующие файл PCH, могут использовать отладочную информацию.

Если при создании файла PCH параметр «C7 совместимо (/Z7)» отключен, последующие компиляции, использующие файл PCH и/Z7, вызывают предупреждение. Отладочная информация помещается в текущий OBJ-файл, а локальные символы, определенные в файле PCH, недоступны отладчику.

Согласованность пути включаемых файлов

В файле PCH не содержатся сведения о пути включаемых файлов, который применялся при создании. При использовании файла PCH компилятор всегда использует путь включаемых файлов, указанный в текущей компиляции.

Согласованность исходного файла

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

Согласованность прагмы

Прагмы, обработанные во время создания файла PCH, обычно влияют на файл, с которым впоследствии используется файл PCH. Прагмы comment и message не влияют на оставшуюся часть компиляции.

Они влияют только на код в файле PCH; они не влияют на код, который впоследствии использует файл PCH:

Эти прагмы сохраняются как часть предкомпилированного заголовка и влияют на оставшуюся часть компиляции, использующую предкомпилированный заголовок:

alloc_text
auto_inline
check_stack
code_seg
data_seg

function
include_alias
init_seg
inline_depth

inline_recursion
intrinsic
optimize
pack

pointers_to_members
setlocale
vtordisp
warning

Правила целостности для параметров компилятора /Yc и /Yu

При использовании предкомпилированного заголовка, созданного с помощью параметра /Yc или/Yu, компилятор сравнивает текущую среду компиляции с той, которая существовала при создании файла PCH. Не забудьте указать среду, соответствующую предыдущей (с помощью параметров компилятора, прагм и т. д.) для текущей компиляции. Если компилятор обнаруживает несогласованность, он выдает предупреждение и по возможности определяет несогласованность. Такие предупреждения не обязательно указывают на проблему с файлом PCH. Они просто предупреждают о возможных конфликтах. В следующих разделах объясняются требования к согласованности для предкомпилированных заголовков.

Согласованность параметров компилятора

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

Средство предварительно откомпилированных заголовков предназначено для использования только в исходных файлах C и C++.

Использование предкомпилированных заголовков в проекте

В предыдущих разделах представлен обзор предкомпилированных заголовков: /Yc и /Yu, параметра /FP и прагмы hdrstop. В этом разделе описывается метод использования в проекте параметров заголовков, предкомпилированных вручную. В конце раздела приводится пример файла makefile и кода, который управляет им.

Чтобы ознакомиться с другим подходом к использованию в проекте параметров заголовков, предкомпилированных вручную, изучите один из файлов makefile, расположенных в каталоге MFC\SRC, который создается во время установки Visual Studio по умолчанию. Подход в этих файлах makefile аналогичен представленному в этом разделе, однако в них используются макросы служебной программы обслуживания Майкрософт (NMAKE) и обеспечивается больший контроль над процессом сборки.

PCH-файлы в процессе построения

База кода проекта программного обеспечения обычно содержится в нескольких исходных файлах C или C++, объектных файлах, библиотеках и файлах заголовков. Как правило, файл makefile координирует объединение этих элементов в исполняемый файл. На следующем рисунке показана структура файла makefile, использующего файл предкомпилированного заголовка. Имена макросов и имена файлов на рисунке соответствуют приведенным в примере кода в разделах Пример файла makefile для PCH и Пример кода для PCH.

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

Структура файла makefile, использующего файл предкомпилированного заголовка

Начиная с верхней части диаграммы, STABLEHDRS и BOUNDRY являются макросами NMAKE, в которых вы перечислите файлы, которые, скорее всего, не потребуют перекомпиляции. Эти файлы компилируются с помощью командной строки

CL /c /W3 /Yc$(BOUNDRY) applib.cpp myapp.cpp

только если файл предкомпилированного заголовка (STABLE.pch) не существует или если вы вносите изменения в файлы, перечисленные в двух макросах. В любом случае файл предкомпилированного заголовка будет содержать код только из файлов, перечисленных в макросе STABLEHDRS. Перечислите последний файл, который необходимо предварительно откомпилировать в макросе BOUNDRY.

Файлы, перечисленные в этих макросах, могут быть файлами заголовков или файлами исходного кода C или C++. (Один PCH-файл нельзя использовать одновременно с модулями C и C++.) Обратите внимание, что можно использовать макрос hdrstop для отмены предварительной компиляции в какой бы то ни было момент в файле. Дополнительные сведения см. в разделе hdrstop.

Далее APPLIB.obj на схеме представляет код поддержки, используемый в окончательном приложении. Он создается из APPLIB.cpp, файлов, перечисленных в макросе UNSTABLEHDRS, и предварительно скомпилированного кода из предкомпилированного заголовка.

MYAPP.obj представляет конечное приложение. Он создается из файла MYAPP.cpp, файлов, перечисленных в макросе UNSTABLEHDRS, и предварительно скомпилированного кода из предкомпилированного заголовка.

Наконец, создается исполняемый файл (MYAPP.EXE) путем связывания файлов, перечисленных в макросе OBJS (APPLIB.obj и MYAPP.obj).

Образец файла makefile для PCH

Помимо макросов STABLEHDRS, BOUNDRY и UNSTABLEHDRS, показанных на рисунке «Структура файла makefile, использующего файл предкомпилированного заголовка» в разделе PCH-файлы в процессе сборки, этот файл makefile предоставляет макрос CLFLAGS и макрос LINKFLAGS. Эти макросы необходимо использовать для перечисления параметров компилятора и компоновщика, которые применяются при сборке отладочной или финальной версии исполняемого файла приложения. Также имеется макрос LIBS, в котором перечислены библиотеки, необходимые для проекта.

Эта функция позволяет использовать один и тот же файл makefile во время разработки и для финальных версий программы — используйте DEBUG=0 для финальных версий. Следующие строки команды являются эквивалентными.

Дополнительные сведения о файлах makefile см. в разделе Справочник по NMAKE. См. также разделы Параметры компилятора MSVC и Параметры компоновщика MSVC.

Пример кода для PCH

Следующие исходные файлы используются в файле makefile, который описан в разделах PCH-файлы в процессе сборки и Образец файла makefile для PCH. Обратите внимание, что комментарии содержат важную информацию.

Источник