My dll project is generating, not only DLL and LIB files but, also a Precompiled file header file. What is the main purpose of a PFH file in my project? Can I get rid of it?
Yes you can get rid of it, but it makes compilation notably faster by allowing the compiler to not recompile a ton (there's really a lot of code in there) of Windows SDK headers. MSDN has more details.
It's simply a way of speeding up compilation, by creating a single file containing all declarations and definitions from multiple header files. Often this file is in a post-parsed format, so the compiler don't have to parse it again.
Related
This question already has answers here:
What is "stdafx.h" used for in Visual Studio?
(5 answers)
Closed 5 years ago.
What is the purpose of the file stdafx.h and what is meant by precompiled headers?
stdafx.h is a file, generated by
Microsoft Visual Studio IDE wizards,
that describes both standard system
and project specific include files
that are used frequently but hardly
ever change.
Compatible compilers (for example,
Visual C++ 6.0 and newer) will
pre-compile this file to reduce
overall compile times.
Visual C++ will
not compile anything before the
#include "stdafx.h" in the source file, unless the compile option
/Yu'stdafx.h' is unchecked (by
default); it assumes all code in the
source up to and including that line
is already compiled.
http://en.wikipedia.org/wiki/Precompiled_header
To expand on the other excellent answers:
stdafx.h is the file that includes all of the commonly used headers for a single project. This would include all of the Windows definitions, for example. Because this file includes so much stuff, the compiler gets a bit slow when processing it. By precompiling it, the compiler can skip much of the processing and reuse it over and over again; as long as none of the files included by it change, the precompiled result doesn't need to change either.
The name stdafx.h is just a convention. You could easily rename it to something else if you changed all your sources to include the new file instead.
To produce the actual precompiled header file, you need one source file in the project that has special compile flags to produce precompiled output. By convention this file is named stdafx.cpp, and if you inspect the settings for that source file you will see how it is different.
It's typically used for the name of precompiled headers. Although using that exact name is not required, just the default. I explain more about pre-compiled headers on VC++ and g++ here.
You use precompiled headers for faster compilation.
The idea is that you put any header file that will not change, and that you use in several source files inside your precompiled header. Then the compiler will not need to reprocess those headers for each compilation unit.
It's a precompiled header, to reduce compilation times.
When compiler compiles source (e.g. *.cpp) file, it creates object file (e.g. *.o), so that later it will be linked to other .o and .so (.lib files for Windows) files and will constitute the executable file.
Now for analogical situation for not compiling header files each time it creates some .pch files so that it will be linked it by the linker then.
Now if in the scope of a Visula Studio project it is defined a precompiled header, then why Visual Studio complains with an error (e.g. **fatal error C1010: unexpected end of file while looking for precompiled header. Did you forget to add '#include "stdafx.h"' to your source?**) that the header file is not included into the .cpp file.
By summarizing, here are my questions:
Why in each .cpp file the precompiled header of the project is
necessary?
How does the requirement of presence of precompiled header in each compilation unit optimizes the compilation process? In other words, what is the benefit of this requirement? (It could be up to the user to decide where to include, where not!)
If precompiled header is included into a .cpp file, which uses only 2% of what is in .pch file, then the remaining 98% will be added to corresponding .o file to?
Why in each .cpp file the precompiled header of the project is necessary?
Because you asked for it. If you don't want to use it then you need to change the option for the .cpp file. Right-click it, Properties, C/C++, Precompiled Headers, "Create/Use" = "Not using precompiled headers". The default setting is "Use". There's little point in doing this.
How does the precompiled header in each compilation unit optimizes the compilation process?
By not having to parse the #includes. Particularly useful when you #include <windows.h>. Time saved is in the order of seconds, on large projects with hundreds of .cpp files that adds up to many minutes. It is by far the cheapest way to speed up the compiler with no loss of quality on the generated code.
then the remaining 98% will be added to corresponding .o file to?
Of course not.
It's not actually necessary to include the precompiled header in every compilation unit. You can set the "not using precompiled header" setting for a single file in the C/C++->Precompiled Headers properties section for that file. This is a lot of work though, and I've never known anyone to do it in production code.
The optimization is that the precompiled header is built just once and the whole shebang is reused for all compilation units without recompiling / re-including (sort of). If you have a set of files that are included a lot of times this can save much compilation time. See The Care And Feeding of Precompiled Headers too.
No, you don't get superfluous file contents, just like you don't when static-linking.
I guess your question means "why can't the compiler assume that this header is always there if it is mandatory". The reason is that VS does not want to deviate from the standard so much. If your .cpp file is using something from a header file, it must include it. This way your file will compile exactly the same even if you turn off precompiled headers (only it will take longer).
As others have said, you can explicitly disable precompiled headers for individual files if you want. The idea is that you should only include in the precompiled header those elements that you are using in most, if not all of your files.
No, the resulting object code should be the same regardless of the header being precompiled or not.
In C/C++ project, mostly the file can be of either types .h or .c/.cpp. Apart from their naming difference such as header and implementation files; is there any functionality difference ?
In other words: if in a working C/C++ project what difference it makes if we change all files with .c or .cpp extension ?
[Note: We can also have #include guards for .c/.cpp files. We can skip their compilation if they are observed as headers.]
Edit:
Debate is not intended for this as I don't have any solid use case. Rather I wanted to know, that allowing to give .h,.hxx,.i extensions are just a facility or a rule. e.g. One functionality difference I see is that .cxx files can have their likable object files.
What difference does it make? The compiler is perfectly happy about it. To it, it's just files.
But to you? You makes a lot of difference:
you're no longer able to immediately figure out which one is the header and which one is the implementation;
you can no longer give header and implementation the same name;
If you are using gcc, and you try and compile a bunch of C++ files labled with a .c extension, it's going to try and compile your file as-if it were a C-language file, which is going to create a ton of errors.
There's also project sanity as well ... this is why many times you'll see projects actually label C++ headers as .hpp rather than just .h so that it's easier to create a distinction between C-language source-code and headers, and C++ source-code and headers.
Header files generally must not be compiled directly but instead #included in a file that is directly compiled. By giving these two groups of files their own extension it makes it a lot easier to determine which to compile.
Make and IDE's and other tools normally expect the conventions of .c/.cpp for source and h/hpp for header. Compiler normally goes a step further and defaults to C compilation for .c and c++ compilation for .cpp
Hence, a bad idea to give your headers the same extension as the the source files.
We are using Visual Studio 2003 (VC71) for compilation.
In order to reduce the compile time we changed the build script such that it generates the precompiled header (.pch) file for each CPP file.
The option used in makefile:
/Yc"StdAfx.h"
/Fp"StdAfx.pch"
With this the compile time for the target got reduced by 30%. But could anyone help me to understand how is it reducing the compiler time even when the pch file is getting generated every time for compilation of each CPP file.
Also, is it the right approach? Should we use Yc and Yu combination ?
I cannot use /Yu option as the pch file should be genrated at least once.
The problem
Let's say you have a list of headers you use that you know won't change. For example, the C headers, or the C++ headers, or Boost headers, etc..
Reading them for each CPP file compilation takes time, and this is not productive time as the compiler is reading the same headers, again and again, and producing the same compilation result for those same headers, again and again.
There should be some way to tell the compiler those headers are always the same, and cache their compiled result instead of recompiling them again and again, no?
The solution
The Pre-Compiled Headers takes that into account, so all you need is to:
Put all those common and unchanging includes in one header file (say, StdAfx.h)
Have one empty CPP file (say, StdAfx.cpp) including only this one header file
And now, what you need is tell the compiler that StdAfx.cpp is the empty source that includes the common and unchanging headers.
This is where the flags /Yc and /Yu are used:
Compile the StdAfx.cpp file with the /Yc flag
Compile all the others CPP files with the /Yu flag
And the compiler will generate (when needed) a pre-compiled header file from the StdAfx.cpp file, and then reuse this pre-compiled header file for all other files marked with /Yu.
Note
When you create a new project, old versions of Visual C++ (6 and 2003, if I remember correctly) would activate the precompiled headers by default. Recent ones offer the choice of activating them of not.
You should create a new VC++ project with the PCH activated to have a working version of PCH-enabled project, and study the compilation options.
For more information about PCH, you can visit the following URL:
http://msdn.microsoft.com/en-us/library/szfdksca.aspx
/Yc should only be used on one of your .cpp modules. This specifies to VS to create the precompiled header with that module.
For all others in your project, use /Yu. This specifies that they are to simply use the pch.
The MSDN entry for it is here: http://msdn.microsoft.com/en-us/library/szfdksca(v=VS.71).aspx
What are the best candidates for a precompiled header file? Can I put STL and Boost headers there, even though they have templates? And will that reduce compile times?
Also, what are the best IDE settings to reduce compile times?
The quick answer: the STL and Boost headers do indeed belong in the precompiled header file, even though these header files define template classes.
When generating a precompiled header file, a compiler parses the header text (a significant task!), and converts it into a binary format that is optimised for the compiler's benefit.
Even though the template classes will be instantiated when other .cpp files are compiled, they will be instantiated from information in the precompiled header, which is significantly faster for the compiler to read.
(later addition)
One thing that you should not include in a precompiled header are files that are part of your project and are changed frequently, even if every single .CPP file includes these files.
The reason is this - the generation of the precompiled header can take a long time, because the boost, stl and windows libraries are very large.
You might have a simple file (eg "StringDefs.h") that everything uses. If StringDefs.h is included in stdafx.h, and one developer touches StringDefs.h, then every developer has to wait until the entire precompiled header recompiles. It would be much faster if StringDefs.h was left out of the precompiled header, and parsed along with each .CPP file.
One addition to Andrew Shepherd's answer. Use the precompiled header for header files that are external to your project, for files that change infrequently. If you're changing the header files in the current project all the time, it's probably not worth precompiling them.
I've written an article on techniques that reduce the compilation time. Among these techniques a post on precompiled header and its application can be found here. It also has a section on best practices that you may find interesting. CMake scripts that handle it transparently are included.
Put anything in the precompiled header that most of the .cpp files in that project would include anyway. This goes for any header file, really. This allows the compiler to parse these files once, and then reuse that information in all .cpp files in the same project.