1

Let me start by defining what is usually called "external include-guards". Suppose you have a header file called someheader.h and a code file called source.cpp. You can have the traditional include-guards inside someheader.h:

//someheader.h
#ifndef _SOMEHEADER_H_
#define _SOMEHEADER_H_
// ...
#endif  // _SOMEHEADER_H_

In the past, I have heard and read multiple times that in really large projects, it would be better for the compiling performance to also have external include guards. which means:

//source.cpp
#ifndef _SOMEHEADER_H_
#include "someheader.h"
#endif
// ...

I guess the reason for such an advice is that with the checking for whether someheader.h had already been processed happening inside source.cpp, the compiler could entirely avoid having to search for someheader.h, open it and just then do the checking. That would be particularly useful in big projects with many levels of nested header inclusions.

Is such an optimization for compiling-times still relevant nowadays, with compilers gcc and visual studio being a lot more well developed?

Jorget Millani
  • 21
  • 2
  • I don't know if there is a definitive answer to this question. I would be surprised if someone could come up with hard numbers. I would expect that these "external include-guards" don't make a significant difference compared to the time it takes to actually compile source code, specially if you account for the time spent on optimization. – François Andrieux Jan 13 '18 at 19:38
  • In large projects one uses precompiled header. –  Jan 13 '18 at 19:42
  • You'd save a very small amount of time, but you'd have to build a _lot_ to make up for the time the developer spends adding those external include guards. (And if your compiler supports `#pragma once` the time saved would be minimal. – 1201ProgramAlarm Jan 13 '18 at 20:25

0 Answers0