Re: Projects for beginners

[James Dennett <jdennett at acm dot org>]

Richard Kenner wrote:
> 
>     NO!!!  I remember well the days of unguarded headers.  They are not
>     completely dead yet, but I still hope for their final demise.  I do
>     not ever want to _have_ to know that header a can be included only
>     after header b.  Programming is complicated enough without just that
>     much more clutter.  NO, NO and NO AGAIN!
> 
> If the structure of the headers is so complicated, it needs to be
> simplified. The perceived need to put in "guards" is merely a symptom
> that things have gotten too complicated.  They should be made simpler,
> not patched over by adding the clutter of guards.

I've been trying to resist, but I'll join in.

Richard's comments are, IMO, wrong.  The reason is that we should
be able to include any header "x.h" without having to know about
which headers it needs; for any header "x.h" the following should
be a legal translation unit:

/* xtest.c -- Test that "x.h" is self-contained */
#include "x.h"
/* EOF */

Now, if two headers y.h and z.h both require x.h then they must both
include it.  And when code comes along which wishes to use both y.h
and z.h, x.h will be included twice.  Note that neither y.h nor z.h
should be aware of the other, so they cannot avoid this problem.  The
user of them should not have to be aware of these details, so it
cannot avoid the problem.  The only way to avoid the problem is to
make header file inclusion idempotent.

Lakos is a good reference for this, IIRC, and real experience backs
up most of his points.  (External include guards are mercifully
redundant with gcc, but maybe that's because someone somewhere
read Lakos and decided to write the code to make them so.)

It's not a subject worth starting a holy war on.  Concensus has
won already; internal include guards are widely accepted practice,
and there's no chance of this changing (nor should it, I think.)

-- James Dennett <jdennett@acm.org>