Handling stdafx.h in cross-platform code

Viewed 37140

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:

  1. 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.
  2. Use approach from here - make stdafx.h look like (set USE_PRECOMPILED_HEADER for VS only):

    #ifdef USE_PRECOMPILED_HEADER
    ... my stuff
    #endif 
    
  3. Use the approach from here - compile VC++ with /FI to implicitly include stdafx.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 mess stdafx.h is pushing a big code base towards. Therefore the option is appealing to me - on Linux you don't have stdafx.h, while still being able to turn on pre-compiled headers on VS by /FI only.

  4. On Linux compile stdafx.h only as a precompiled header (mimic Visual Studio)

Your opinion? Are there other approaches to treat the issue?

10 Answers

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 include stdafx.h

Example:

stdafx.h:

#include <string>
#include <stdio.h>

a.cpp:

#include "stdafx.h"
int main(int argc, char**argv)
{
  std::string s = "Hi";
  return 0;
}

Then compile as:

> g++ -c stdafx.h -o stdafx.h.gch
> g++ a.cpp
> ./a.out

Your compilation will work even if you remove stdafx.h after step 1.

I used option 3 last time I needed to do this same thing. My project was pretty small but this worked wonderfully.

I'd either go for option 4 or option 2. I've experimented with precompiled headers on both various VS versions and GCC on Linux (blog posts about this here and here). In my experience, VS is a lot more sensitive to the length of the include paths, number of directories in the include path and the number of include files than G++ is. When I measured build times properly arranged precompiled headers would make a massive difference to the compile time under VS whereas G++ was pretty much unimpressed by this.

Actually, based on the above what I did the last time I worked on a project where this was necessary to rein in the compile time was to precompile the equivalent of stdafx.h under Windows where it made sense and simply used it as a regular file under Linux.

It's simple, really:

Project->Project Settings (Alt + F7)

Project-Settings-Dialog:
C++ -> Category: Precompiled Headers -> Precompiled Headers radio buttons --> disable

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.

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 called pchNotificationEngine.cpp with the following contents:

#include "stdafx.h"
#include "notificationEngine.cpp"

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.

Related