Original Post
🔒 Locked
Precompiled headers
Advertisement
For large projects, the compiler can spend a lot of time on header files.
It must open up every file that has been #include-ed and process it. It goes into the files that those files included, until it has processed all of them. When it starts the next .cpp file, it starts over, reprocessing all the same header files.
When a project gets really large, it can take a half hour or more for the compiler to go through all the headers for every file. It is extremely wasteful for the compiler to re-process every .h file for every .cpp file.
Precompiled headers work by the consolidating all the stuff you frequently compile, and dumping the preprocessed stuff into a huge intermediate file. Since this bundle is only processed once, you can cut your compile times by half or more.
Automatically generated precompiled headers make this easy, allowing the programmers to spend their time on important things rather than focusing on making the compiler run faster. There is no need to create a custom header file for it, assuming you set your options properly.
For large projects it can make sense for the build manager (that's their full-time job) to manually put together those files and not let the compiler do it. In that case, you generally include everything that is frequently used and everything with complex dependencies in their declarations.
For small projects I wouldn't bother with it. If your compile time is under a minute than it probably isn't worth it yet. In this case you should just include the files directly.
It must open up every file that has been #include-ed and process it. It goes into the files that those files included, until it has processed all of them. When it starts the next .cpp file, it starts over, reprocessing all the same header files.
When a project gets really large, it can take a half hour or more for the compiler to go through all the headers for every file. It is extremely wasteful for the compiler to re-process every .h file for every .cpp file.
Precompiled headers work by the consolidating all the stuff you frequently compile, and dumping the preprocessed stuff into a huge intermediate file. Since this bundle is only processed once, you can cut your compile times by half or more.
Automatically generated precompiled headers make this easy, allowing the programmers to spend their time on important things rather than focusing on making the compiler run faster. There is no need to create a custom header file for it, assuming you set your options properly.
For large projects it can make sense for the build manager (that's their full-time job) to manually put together those files and not let the compiler do it. In that case, you generally include everything that is frequently used and everything with complex dependencies in their declarations.
For small projects I wouldn't bother with it. If your compile time is under a minute than it probably isn't worth it yet. In this case you should just include the files directly.
Quote:
Original post by Swarmer
Okay thanks!
Hm...
What does STDAFX stand for? Standard something. Dunno.
Wiki knows. "The AFX in stdafx.h stands for Application Framework eXtensions. AFX was the original abbreviation for the Microsoft Foundation Classes (MFC). Optionally, Visual Studio projects may avoid pre-compiled headers, as well as they may specify an alternative name (though stdafx.h is used by default)."
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement