Re: [boost] Proposal for #pragma once support

Subject: Re: [boost] Proposal for #pragma once support
From: Stephen Nuchia (snuchia_at_[hidden])
Date: 2009-06-10 10:45:52

#pragma once is useful in Windows for the same reason they have the
pre-compiled header abomination: slow directory-level file system
operations and a really bad system header legacy.

On the point that some headers should not use this mechanism: in
addition to headers designed to instantiate something in-place, some
headers include optional components activated by a user-specified
define.  The idempotent and flag-independent portions can be enclosed in
a preprocessor include guard but the optional part should be left
outside the guard.

An example is the non-ANSI manifest constant set in <math.h> which
Microsoft chose to enable by defining a symbol before including the
header.  By leaving that conditional block of definitions out of the
include guard and *not* specifying pragma once for that file they
ensured that 

#include <something.innocuous.that.includes.math.h>
#define USE_MATH_DEFINES
#include <math.h>

works as expected.  Another example: 

#define BOOST_TEST_MAIN
#include "boost/test/unit_test.hpp"

This causes a boilerplate "main" to be instantiated in your source file.
If this were done outside the include guard then we could make
unit_test.hpp (without main) part of the pre-compiled header and then
re-include it in one compilation unit with the macro defined.  #pragma
once would make that impossible.

By the way, the Microsoft include "optimization" story gets even
goofier.  They also have a magic cookie comment that you can include as
the first line of a header that causes dependency analysis to ignore the
file that contains the cookie and any subordinate dependencies.  This
was hacked into their C/C++ compiler to make incremental builds
tolerable in the presence of the IDE-maintained headers defining
resource IDs and such.  Needless to say it causes all kinds of problems.
One of which is that other consumers of those files do not honor the
cookie in their dependency analysis.

There is also a "minimal rebuild" mechanism mentioned in the compiler
switch documentation that seems to have been intended to do a
syntax-aware intra-compilation-unit dependency analysis.  I have no idea
what it really does but its existence is just one more clue as to how
bad the performance of this compiler/file system/header suite
combination is.

-swn