Cross-platform stdafx.h handling

Question

I have a Visual C ++ program that uses precompiled headers ( stdafx.h ). Now we port the application to Linux using gcc 4.x.

The question is how to handle the precompiled header in both environments. I googled, but cannot conclude.

Obviously, I want to leave stdafx.h in Visual Studio, since the code base is quite large, and pre-compiled headers increase compilation time.

But the question is what to do on Linux. Here is what I found:

• Leave stdafx.h as is. gcc compiles code much faster than VC ++ (or is it just my Linux machine is stronger ... :)), so I'm probably happy with this option.

• Use the approach here - make stdafx.h look like this (set USE_PRECOMPILED_HEADER only for VS):

   #ifdef USE_PRECOMPILED_HEADER ... my stuff #endif 

• Use the approach here - compile VC ++ with /FI to implicitly include stdafx.h in each cpp file. Therefore, in VS, your code can be easily switched to compile without precompiled headers, and the code should not be changed.
  I personally don't like dependencies, and the stdafx.h mess pushes a large code base. Therefore, the option is attractive to me - on Linux you do not have stdafx.h , but you can only include precompiled headers on VS only /FI .

• In Linux compilation, stdafx.h only as a precompiled header (mimic Visual Studio)

Your opinion? Are there other approaches to solving the problem?

Answer 1

It is best to use precompiled headers for quick compilation.

You can also use precompiled headers in gcc. See here .

A compiled precompiled header will have an extension added as .gch instead of .pch .

So, for example, if you precompile stdafx.h, you will have a precompiled header that will automatically look for called stdafx.h.gch anytime you turn on 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 delete stdafx.h after step 1.

Answer 2

I used option 3 last time I needed to do the same. My project was pretty small, but it worked wonderfully.

Answer 3

I will either go to option 4 or option 2. I experimented with precompiled headers both on different versions of VS and on GCC on Linux (blog posts about this here and here ). In my experience, VS is much more sensitive to the length of the included paths, the number of directories in the include path, and the number of include files than g ++. When I measured the build time of correctly ordered precompiled headers, this would significantly change the compilation time for VS, while g ++ was not very impressed with this.

Actually, based on the foregoing, what I did the last time I worked on the project, when it was necessary to curb compilation time, was to precompile the equivalent of stdafx.h under Windows, where it made sense and just used it as a regular file under Linux

Answer 4

A very simple solution. Add a dummy file entry for "stdafx.h" to the Linux environment.

Answer 5

It is simple, really:


Project-> Project Settings (Alt + F7)


Project-Dialog Options:
C ++ → Category: Precompiled headers → Precompiled headers with radio buttons → disable

Answer 6

Since stdafx.h defaults to all Windows related components, I put empty stdafx.h on another platform. This way, your source code remains the same if you effectively disconnect stdafx from Linux without having to remove all #include "stdafx.h" lines from your code.

Answer 7

I would only use option 1 in a large development team. Options 2, 3, and 4 often halt the performance of other members of your team, so you can save several minutes a day during compilation.

That's why:

Suppose half of your developers use VS and half use gcc. From time to time, some VS developer will forget to include the header in the .cpp file. It will not notice, because stdafx.h implicitly includes it. This way it pushes its changes to version control, and then several other members of the gcc team will get compiler errors. Thus, for every 5 minutes a day you get, using pre-compiled headers, 5 other people spend time correcting the missing headers.

If you do not use the same code for all your compilers, you will encounter such problems every day. If you force VS developers to check compilation on gcc before pushing changes, you will throw away all your benefits from using precompiled headers.

Option 4 sounds attractive, but what if you want to use a different compiler at some point? Option 4 only works if you use only VS and gcc.

Note that option 1 can make gcc compile for a few seconds. Although this may not be noticeable.

Answer 8

If you use CMake in your project, that is, modules that automate it for you are very convenient, for example, see cmake-precompiled-header here . To use it, simply turn on the module and call:

 include( cmake-precompiled-header/PrecompiledHeader.cmake ) add_precompiled_header( ${target} ${header} FORCEINCLUDE SOURCE_CXX ${source} ) 

Another module called Cotire creates a precompiled header file (there is no need to manually write StdAfx.h) and speeds up the assembly in other ways - see here .

Answer 9

I made both option 2 (#ifdef) and option 4 (PCH for gcc) for cross-platform code without any problems.

I find that gcc compiles much faster than VS, so precompiled headers are generally not that important unless you are referencing some huge header file.