0

When using Microsoft's Optimised Compilation design -stdafx.h - is the idea that all includes should only ever occur in this file only. Or is it just compilation intensive components?

If sticking to the all 'rule' will I achieve a faster more efficient compilation design?

stdafx.h:

... Standard C++ includes

#include "Base.h"
#include "Super.h"

Where both Base and Super header and cpp files includes only the stdafx.h header

sazr
  • 24,984
  • 66
  • 194
  • 362
  • IMHO, the `stdafx.h` causes more problems than it solves. Precompiled headers should be in *huge* builds where it actually makes a difference. – Thomas Matthews Jan 04 '16 at 23:05
  • I would believe that you would want to have the most popular includes precompiled. But that is my opinion. I don't see how a huge precompiled header will speed up a compilation when only a few of the definitions are inside it. – Thomas Matthews Jan 04 '16 at 23:07
  • You also measure build performance. Storage devices are faster and so are the PCs. Measure 10 rebuilds with precompiled headers and 10 without. Calculate the average build times. Is the time savings significant? Do the same again, only recompiling one file. Is the time savings still significant? – Thomas Matthews Jan 04 '16 at 23:10
  • ***is the idea that all includes should only ever occur in this file only*** No. I say only put headers for external libraries in this file or at least headers that will not normally change. – drescherjm Jan 04 '16 at 23:27

1 Answers1

0

When using Microsoft's Fast Compilation design -stdafx.h - is the idea that all includes should only ever occur in this file only.

Not all headers should be placed in stdafx.h, as @drescherjm commented.

Moreover, even if a header appears in stdafx.h, it does not automatically mean that it should disappear from cpp files. At least, according to 4 Ways Precompiled Headers Cripple Your Code (although not about Microsoft, but the same principle, emphasis mine):

Apple’s iOS project templates start you off with Prefix.pch including Foundation and UIKit. From a compilation speed point of view, this makes a lot of sense. The problem is that people noticed and said, “Those files are already implicitly included. So I don’t need to include them again.” Upon discovering this side-effect, some programmers start dumping more headers into Prefix.pch. Because hey, then you don’t have to #import it ever again.

The purpose shifted from “make this project compile as fast as possible” to “save myself some typing.” A Stack Overflow question reflects this, asking, “Why have both?” Even the Wikipedia entry for prefix header reflects this incorrect conclusion: “As a result, it is unnecessary to explicitly include any of the above files.” This misunderstanding is widespread.

And it’s flat-out wrong.

....

The problem is that to successfully compile a file, it’s no longer enough to have the paired header (.h) and the implementation (.m). You also need Prefix.pch — not because they’re precompiled, but because they’re implicitly included.

And they give several points, basically elaborating on the idea that it breaks the concept of dependency.

Community
  • 1
  • 1
AlexD
  • 32,156
  • 3
  • 71
  • 65
  • you'll need to explain `Precompiled headers are not supposed to minimize **number** of includes.` The question isn't about how many times to include a header? Its about *where* (stdafx.h or elsewhere) to include that header in order to achieve the goal of optimised compilation – sazr Jan 04 '16 at 23:04
  • @JakeM Updated. To answer your "_stdafx.h or elsewhere_" question: according to the given recommendation, it sounds that files `.h` should be placed normally, as it would be no precompiled headers, and, in addition, **some** should be placed to `stdafx.h` for compilation speed. – AlexD Jan 04 '16 at 23:34