Off-list (presumably accidentally), Gary R. Van Sickle replied:
I tend to think that the include guards should wrap as much of the file as possible, idea being that the compiler then bypasses the most text
possible.
But then again, rumor has it that gcc (at least) recognizes such
constructs and
doesn't even rescan the file at all the second time, and scanning is
hardly the
bottleneck in gcc these days....
I don't think the extra copyright comments will have much of an effect on compilation speed. I like the layout I proposed, because it gives increased visual distinction between copyright boilerplate and file-specific interesting info.
I too like this aspect of the layout.
Additionally, recall that C / C++ compilers generally run in (at least) two parts: a pre-processor (cpp) that generates a single macro-expanded source files, and then the actual source->(object|assembly).
The smarts of the cpp program are what drive the overhead of repeated includes. A naive one will scan every include fully into memory, and the process through the #if's. A smarter one will calculate as it goes, and once it hits a #if start skipping code...
My point is that a dumb one will, if header FOO is included 3 times, have three complete copies of FOO in memory before it's #if resolution pass. A smart one that only keeps one copy of FOO, and 2 copies of the comments is already so much faster :}....
Rob