Re: [Groff] Strange error messages from Groff 1.22.3

[Jones, Larry]

Ralph Corderoy writes:
> 
> Gets my vote.  :-)  It's a Bell Labs style of programming seen widely in
> Plan 9.  Rob Pike has also written about it since the 1980s.  Header
> files should not be #include'd multiple times;  nor should they #include
> others.  They should state their needs and be #include'd once in the
> C(++) file, in an appropriate order.  Guards are verboten.
> 
> One example:
> 
>     The construction of a single C++ binary at Google can open and read
>     hundreds of individual header files tens of thousands of times.  In 2007,
>     build engineers at Google instrumented the compilation of a major Google
>     binary.  The file contained about two thousand files that, if simply
>     concatenated together, totaled 4.2 megabytes.  By the time the #includes
>     had been expanded, over 8 gigabytes were being delivered to the input of
>     the compiler, a blow-up of 2000 bytes for every C++ source byte.
>         -- Rob Pike, https://talks.golang.org/2012/splash.article#TOC_5.
>             (That dot is part of the anchor.)

That's a crock. Users shouldn't have to figure out the transitive closure of 
all the recursively required headers and then do a topological sort to get them 
in the right order, headers should just include the other headers that they 
require and let the compiler sort it out. It's not very difficult for a 
compiler/preprocessor to detect that a header is idempotent and not read it 
multiple times; GCC has been doing it for at least 10 years, if not 20. (See 
https://gcc.gnu.org/onlinedocs/cppinternals/Guard-Macros.html.)
        
-Larry Jones