I have a Visual Studio C++ based program that uses pre-compiled headers (stdafx.h
). Now we are porting the application to Linux using gcc 4.x.
The question is how to handle pre-compiled header in both environments. I've googled but can not come to a conclusion.
Obviously I want leave stdafx.h
in Visual Studio since the code base is pretty big and pre-compiled headers boost compilation time.
But the question is what to do in Linux. This is what I found:
- Leave the
stdafx.h
as is. gcc compiles code considerable faster than VC++ (or it is just my Linux machine is stronger ... :) ), so I maybe happy with this option. Use approach from here - make
stdafx.h
look like (setUSE_PRECOMPILED_HEADER
for VS only):#ifdef USE_PRECOMPILED_HEADER ... my stuff #endif
Use the approach from here - compile VC++ with
/FI
to implicitly includestdafx.h
in each cpp file. Therefore in VS your code can be switched easily to be compiled without pre-compiled headers and no code will have to be changed.
I personally dislike dependencies and the messstdafx.h
is pushing a big code base towards. Therefore the option is appealing to me - on Linux you don't havestdafx.h
, while still being able to turn on pre-compiled headers on VS by/FI
only.- On Linux compile
stdafx.h
only as a precompiled header (mimic Visual Studio)
Your opinion? Are there other approaches to treat the issue?
I would only use option 1 in a big team of developers. Options 2, 3, and 4 will often halt the productivity of other members of your team, so you can save a few minutes a day in compile time.
Here's why:
Let's assume that half of your developers use VS and half use gcc. Every now and then some VS developer will forget to include a header in a .cpp file. He won't notice, because the stdafx.h implicitly includes it. So, he pushes his changes in the version control, and then a few other members of the gcc team will get compiler errors. So, for every 5 minutes-a-day you gain by using precompiled headers, 5 other people waste by fixing your missing headers.
If you don't share the same code across all of your compilers, you will run into problems like that every day. If you force your VS developers to check for compilation on gcc before pushing changes, then you will throw away all your productivity gains from using precompiled headers.
Option 4 sounds appealing, but what if you want to use another compiler at some point in time ? Option 4 only works if you only use VS and gcc.
Notice that option 1 may make gcc compilation suffer a few seconds. Although it may not be noticeable.
It's simple, really:
Project->Project Settings (Alt + F7)
Project-Settings-Dialog:
C++ -> Category: Precompiled Headers -> Precompiled Headers radio buttons --> disable
I have a situation where #2 in particular didn't work for me (There are numerous VS build configs where a
#ifdef
around#include "stdafx.h"
does not work). Other solutions were suboptimal because the files themselves were cross-project as well as being cross-platform. I did not want to force preprocessor macros to be set or force linux or even windows builds to use (or not use) pch, so...What I did, given a file named
notificationEngine.cpp
, for example, was removed the#include stdafx.h
line entirely, created a new file in the same directory calledpchNotificationEngine.cpp
with the following contents:Any given project can just include the correct version of the file. This admittedly is probably not the best option for cpp files that are only used by a single project.
You're best off using precompiled headers still for fastest compilation.
You can use precompiled headers in gcc as well. See here.
The compiled precompiled header will have an extension appended as
.gch
instead of.pch
.So for example if you precompile stdafx.h you will have a precompiled header that will be automatically searched for called
stdafx.h.gch
anytime you includestdafx.h
Example:
stdafx.h:
a.cpp:
Then compile as:
Your compilation will work even if you remove stdafx.h after step 1.
If you are using CMake in your project, then there are modules which automate it for you, very convenient, for example see cmake-precompiled-header here. To use it just include the module and call:
Another module called Cotire creates the header file to be precompiled (no need to manually write StdAfx.h) and speeds up builds in other ways - see here.
I've done both option 2 (#ifdef) and option 4 (PCH for gcc) for cross platform code with no issues.
I find gcc compiles much faster than VS so the precompiled headers are generally not that important, unless you are referencing some huge header file.