Menu
As usual, when my brain's messing with something I can't figure out myself, I come to you guys for help :)
This time I've been wondering why stdafx.h works the way it does? To my understanding it does 2 things:
Now, these 2 things seems like two very different tasks to me, and I wonder why they didn't do two seperate steps to take care of them? To me it seems reasonable to have a #pragma-command do the bookmarking stuff and to optionally have a header-file a long the lines of windows.h to do the including of often-used headers... Which brings me to my next point: Why are we forced to include often-used headers through stdafx.h? Personally, I'm not aware of any often used headers I use that I'm not already doing my own includes for - but maybe these headers are necessary for .dll generation?
Thx in advance
595
“stdafx. h” comes in handy when we want to compile a program again and again. It must be included at the top of all header files and now the first time the program is compiled then the compiled version of all the header files present in the program would be saved in “stdafx. h” file.
h (named stdafx. h before Visual Studio 2017) is a file generated by the Microsoft Visual Studio IDE wizard, that describes both standard system and project specific include files that are used frequently but hardly ever change. The afx in stdafx. h stands for application framework extensions.
When you create a new project in Visual Studio, a precompiled header file named pch. h is added to the project. (In Visual Studio 2017 and earlier, the file was called stdafx. h .) The purpose of the file is to speed up the build process.
stdafx. h is not strictly necessary. Bad practice - you ought to always explicitly list the headers you need so you can check module dependencies. stdafx usually includes platform specific definitions common for all files.
stdafx.h is ONE way of having Visual studio do precompiled headers. It's a simple to use, easy to automatically generate, approach that works well for smaller apps but can cause problems for larger more complex apps where the fact that it encourages, effectively, the use of a single header file it can cause coupling across components that are otherwise independent. If used just for system headers it tends to be OK, but as a project grows in size and complexity it's tempting to throw other headers in there and then suddenly changing any header file results in the recompilation of everything in the project.
See here: Is there a way to use pre-compiled headers in VC++ without requiring stdafx.h? for details of an alternative approach.
196
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
