[Still off-topic]

On 4/1/22 17:00, Ray Dillinger wrote:
> Okay, I agree with you... it ought to be easy ... I can't think of a
> specific reason why it shouldn't be ... but take a large project that
> has libraries included from lots of different directions and by lots of
> different paths, and instrument the compiler. See whether it's spending
> 90% of its time parsing header files.  And you'll see that this
> optimization is not happening.  I assume there's some esoteric
> language-standard reason why not.

The compiler can optimize the case of A.h, B,h, and C.h where both B.h and C.h
do #include <A.h>, and the main file incluydes both B.h and C.h.

However, it is harder for the compiler to optimize the case when A.h and B.h
mutually include each other. In that case, adding the guards "by hand"
around the #include statement can be beneficial.

However, spending "90% of its time parsing header files" can still happen
if using a large library with dozens or hundreds of header files: A typical
.c/.cpp file will often include transitively dozens of header files, dwarfing
the text of the .c/.cpp files.  That is why there are been so many attempts
at precompiled header files.

Careful coding can help.  To use a Qt example: Instead of:
     #include <QtGui/QMouseEvent>
use the forward reference:
     class QMouseEvent;
(except when you actually need the specifics of QMouseEvent of course).
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/